The Horizon Europe data management plan template has six sections — Data Summary, FAIR Data (split into four parts), Allocation of Resources, Data Security, Ethical Aspects and Other Issues — and beneficiaries must submit a completed version as a project deliverable, typically by month six, then keep it updated throughout the grant.
A data management plan (DMP) is a structured, funder-required document describing what research data a project will collect or reuse and how that data will be made findable, accessible, interoperable and reusable (FAIR) during and after the project.
- What is the Horizon Europe DMP template, and is it mandatory?
- Section 1: Data Summary — what goes in this box?
- Section 2: FAIR Data — the four subsections explained
- Sections 3–6: resources, security, ethics and other issues
- When is the DMP due, and who should complete it?
- Common questions about the Horizon Europe DMP template
- What this means for pre-award teams
What is the Horizon Europe DMP template, and is it mandatory?
The European Commission publishes a recommended DMP template for Horizon Europe on the Funding & Tenders Portal, downloadable from the programme’s Reference Documents page. Its own cover note states it is “recommended but not mandatory” — beneficiaries may use an equivalent institutional tool, provided the resulting plan still satisfies the grant agreement’s research data management requirements.
That obligation flows from the Horizon Europe Model Grant Agreement’s open science provisions, which apply the principle “as open as possible, as closed as necessary.” The template builds on the core DMP requirements published by Science Europe, adapted with guidance from the Horizon Europe Programme Guide and Annotated Model Grant Agreement. Any project that generates or reuses research data — in practice, almost every funded action — must produce a DMP, even where some datasets end up closed for legal or commercial reasons.
Section 1: Data Summary — what goes in this box?
Data Summary is the scene-setter, asking what data the project will handle and why, before the plan moves into FAIR mechanics. Reviewers use it to check the rest of the DMP is consistent with the project’s actual work packages.
- Purpose of data collection/generation and its relation to the project’s objectives — link each dataset back to a specific work package or deliverable, not a generic statement.
- Types and formats of data the project will generate or reuse — for example, experimental measurements, survey responses, images, code, or administrative records, plus the file formats (CSV, FASTA, TIFF, etc.).
- Origin of the data — state clearly whether data is newly generated, reused from an existing source, or a mix, and name the source if reused.
- Expected size of the data — even an order-of-magnitude estimate (megabytes, gigabytes, terabytes) is acceptable at the first version.
- Data utility — who, beyond the consortium, might reuse this data, and for what purpose.
Pre-award staff completing this section for the first time should resist writing a literature-review-style paragraph. Reviewers want short, factual answers mapped to the bullet points above — the template rewards precision over prose.
Section 2: FAIR Data — the four subsections explained
FAIR Data is the substantive core of the template and the section most often under-completed. It is split into four numbered subsections that mirror the FAIR acronym itself — Findable, Accessible, Interoperable, Reusable — and each subsection has its own set of prompts.
| Subsection | What the template asks | Practical answer to give |
|---|---|---|
| 2.1 Making data findable | Will you assign persistent identifiers (PIDs) and rich, standardised metadata? | Name the PID scheme (e.g. a repository-issued DOI) and the metadata standard (e.g. Dublin Core, DDI, or a discipline-specific schema). |
| 2.2 Making data openly accessible | Where will data be deposited, and will access be open or restricted? | Name the trusted repository (Zenodo is OpenAIRE’s default recommendation where no discipline repository exists) and justify any closed-access exceptions. |
| 2.3 Making data interoperable | Which standards, formats and vocabularies allow the data to be combined with other datasets? | Cite the community-standard formats or ontologies used, and any mapping needed for project-specific vocabularies. |
| 2.4 Increase data re-use | Under what licence will data be released, and how long will it stay usable? | State the licence (CC BY is the common Horizon Europe default) and the quality checks applied before deposit. |
The European Open Science Cloud (EOSC) is directly relevant here: EOSC is the EU’s federated infrastructure for discovering, accessing and reusing research data and services across disciplines and borders, and Horizon Europe funds its continued development. Naming an EOSC-onboarded repository in subsections 2.1–2.2 strengthens the plan’s credibility, since it shows the data will sit inside infrastructure the Commission is actively co-funding rather than an ad hoc departmental server.
Sections 3–6: resources, security, ethics and other issues
The remaining four sections are shorter but frequently answered with a single vague sentence — exactly where reviewers focus scrutiny at the mid-term review.
| Section | What it requires | Common first-time-drafter mistake |
|---|---|---|
| 3. Allocation of resources | Costs of making data FAIR, who is responsible, and the long-term preservation plan | Leaving preservation open-ended instead of naming a retention period |
| 4. Data security | Storage, backup and access-control arrangements during and after the project | Describing generic IT policy rather than project-specific storage |
| 5. Ethical aspects | Ethical or legal issues affecting data sharing, including GDPR compliance and consent | Duplicating the ethics self-assessment instead of cross-referencing it |
| 6. Other issues | Any other national, funder or institutional procedures not already captured | Leaving the box empty instead of writing “None applicable” |
A DMP that answers Sections 3–6 with genuine project-specific detail — a named repository retention period, a named responsible role, an explicit GDPR legal basis — reads as materially stronger to reviewers than one that repeats institutional boilerplate across all four boxes.
When is the DMP due, and who should complete it?
The Horizon Europe Model Grant Agreement requires beneficiaries to establish an initial DMP by month six and keep it updated as a living document, with revised versions typically expected at the mid-term and final reporting points as the data landscape becomes clearer.
Completing the template well is rarely a solo task. Pre-award and grants staff typically draft Sections 1 and 3 from the proposal’s work-package descriptions, while a data steward, PI or research software engineer is usually needed to answer Section 2’s technical FAIR questions accurately — naming actual repositories, metadata standards and licences rather than generic placeholders.
Common questions about the Horizon Europe DMP template
Is the Horizon Europe DMP template mandatory?
The template itself is optional — the European Commission’s own guidance describes it as recommended, not mandatory. What is mandatory is the underlying Data Management Plan deliverable: any project generating or reusing research data must produce one satisfying the Model Grant Agreement’s open science requirements, whichever format is used.
When is the Horizon Europe Data Management Plan due?
Beneficiaries must establish an initial DMP by month six of the project as a formal deliverable. The plan is then a living document, expected to be revised as data-related decisions firm up, typically reviewed again at the project’s mid-term and final reporting stages.
What are the FAIR data requirements in Horizon Europe?
Horizon Europe requires data to be made Findable, Accessible, Interoperable and Reusable “as open as possible, as closed as necessary.” In practice this means assigning persistent identifiers, depositing in a trusted repository, using interoperable formats and standards, and releasing data under a clear reuse licence such as CC BY.
How does the DMP relate to the European Open Science Cloud?
The European Open Science Cloud (EOSC) is the EU’s federated infrastructure for finding, accessing and reusing research data across disciplines. Horizon Europe DMPs that deposit data in EOSC-connected repositories more directly demonstrate compliance with the FAIR Data section’s findability and accessibility requirements.
What this means for pre-award teams
Treat the DMP template as a compliance document with real reporting consequences, not a formality to file and forget. Reviewers assess DMP quality at the mid-term review, and a plan that still reads like a first draft — vague repository names, no named responsible role, empty “Other issues” boxes — signals weak project data governance more broadly.
The most efficient approach for institutions running multiple Horizon Europe applications is a short internal checklist mapped to the six sections above, with FAIR Data answers pre-populated using the institution’s standard repository, metadata standard and default licence — leaving only the project-specific fields (data types, sizes, ethics) to customise for each new proposal. This turns a document that stalls many first-time drafters into a largely fill-in-the-blank exercise, freeing research administration teams to focus review time on the genuinely project-specific risks: ethics, security and long-term preservation cost.