Tag: horizon europe dmp

  • What Is a Data Management Plan? UKRI, NIH and EU Essentials

    A data management plan (DMP) is a formal document that sets out how a research project will collect, document, store, secure, share, and preserve its data, from the first data point to long-term archiving. Most major funders — including UKRI, the US National Institutes of Health (NIH), and Horizon Europe — now require a DMP at application stage, and increasingly expect it to be aligned with the FAIR principles. This explainer defines a data management plan, sets out why funders mandate one, breaks down its core components, and maps each section onto FAIR.

    A data management plan is, in one sentence: a written commitment describing what data a project will generate, how that data will be organised and protected while the project runs, and how — or whether — it will be shared and preserved once the project ends.

    What is a data management plan?

    A data management plan is a structured, funder- or institution-facing document describing how a project will handle its data across the full research lifecycle. It is drafted at proposal stage, before data collection begins, and treated as a living document revisited as the project evolves.

    A DMP is not a policy statement bolted onto a grant application. Reviewers use it to check that an applicant has thought through data volumes, storage costs, ethical constraints, and sharing obligations before funding is committed. Institutions use it to assign responsibility for storage and eventual deposit; funders use it to enforce open-data commitments after the award is made.

    Why do funders require a data management plan?

    Funders require a DMP because public and charitable research funding carries an expectation that resulting data — not just the resulting publication — is managed responsibly and, where possible, made available for verification and reuse. A DMP is the mechanism funders use to check this before they pay for the research, and to hold grantees to it afterwards.

    The three funders named in this explainer take slightly different approaches to timing and enforcement:

    Funder Governing policy When the DMP is due How it is enforced
    UKRI UKRI Common Principles on Data Policy, implemented per council (e.g. MRC, NERC) At proposal stage Assessed during peer review; council-specific detail expected proportional to data volume
    NIH NIH Data Management and Sharing (DMS) Policy, effective 25 January 2023 At application stage, for all NIH grants that generate scientific data Formal element of merit review; compliance with the approved plan is a condition of the award
    Horizon Europe Horizon Europe Data Management Plan requirement under the Model Grant Agreement A summary at proposal stage; the full DMP is due by month six and updated through the project Grant-agreement condition, monitored through periodic and final reporting

    The NIH policy is a useful marker of where funder expectations are heading: before January 2023, only NIH grants that explicitly generated large datasets needed a plan. Since that date, a Data Management and Sharing Plan is required for essentially all NIH-funded research that produces scientific data, replacing the earlier, narrower DMP requirement. Horizon Europe applies the principle “as open as possible, as closed as necessary” — data defaults to open, and any restriction must be justified in the plan itself, typically via deposit in European Open Science Cloud (EOSC)-federated infrastructure.

    What are the core components of a data management plan?

    What is included in a data management plan varies slightly by funder template, but nearly every DMP — UK, US, or EU — covers the same five areas:

    • Data types and volume: what kinds of data the project will generate or reuse (numerical, image, text, biological samples, code), in what formats, and at roughly what scale.
    • Documentation and metadata: how the data will be described so a third party — or the researcher, eighteen months later — can understand and reuse it without asking the original team.
    • Storage and security: where data will live during the project, how it is backed up, and who has access, particularly for sensitive or identifiable data.
    • Sharing and preservation: which data will be shared, through which repository, on what timeline, and which data will not be shared, with a stated justification.
    • Ethics, consent, and legal compliance: how personal, sensitive, or Indigenous data will be handled under relevant data-protection law and participant consent terms, and how intellectual-property or commercial-sensitivity constraints are addressed.

    A sixth element, often folded into the above, is roles and responsibilities: naming who on the project team is accountable for each of these tasks, since a DMP with no named owner tends not to get implemented.

    How do FAIR principles map onto a data management plan?

    The FAIR principles — Findable, Accessible, Interoperable, Reusable, published in Scientific Data in 2016 — are now the reference framework funders use to judge whether a DMP’s sharing commitments are substantive rather than nominal. Each FAIR letter corresponds to a specific, checkable DMP section:

    FAIR principle DMP section it governs What a reviewer checks for
    Findable Documentation and metadata A persistent identifier (e.g. a DOI) and rich, indexed metadata assigned at deposit
    Accessible Storage and sharing A stated repository and access protocol, plus clear conditions where access is restricted
    Interoperable Data types and formats Use of standard, non-proprietary formats and controlled vocabularies rather than bespoke formats
    Reusable Preservation and licensing A clear usage licence, provenance information, and community data standards followed at deposit

    This mapping is why a DMP written purely as a compliance checklist tends to fail review: a plan can name a repository (satisfying Accessible) while leaving metadata and licensing (Findable and Reusable) unaddressed, and a funder assessor trained on FAIR criteria will flag the gap.

    Common questions about data management plans

    What is in a data management plan?

    A DMP typically sets out the types of data to be produced, the metadata standards used to describe them, the storage and backup arrangements during the project, the access and sharing policy, and the plan for long-term archiving so the data remains usable after the project ends.

    How do you write a data management plan?

    Start from the funder’s own template rather than a blank page, since UKRI, NIH, and Horizon Europe each specify required headings. Describe data types and volumes first, then storage, ethics, and sharing, and be explicit about what will not be shared and why — a stated exception is stronger than a silent gap.

    Do I need a data management plan?

    If the project is funded by a body with a research-data policy — which now includes most major UK, US, and EU funders — a DMP is mandatory at application stage, not optional. Institutions increasingly also require one for internally funded or unfunded projects that handle sensitive data, as a matter of good practice.

    What does a good data management plan look like?

    A strong DMP is specific rather than generic: it names an actual repository rather than “a suitable repository,” gives a realistic storage volume, and assigns a named person to each task. It is written to be checked against, not filed and forgotten — funders increasingly audit compliance with the plan they approved, not just its existence.

    What this means for researchers and institutions

    Why data management plans matter is shifting from a compliance formality to an operational one. NIH’s move to require a plan for essentially all data-generating awards, not just large-dataset ones, signals broadening rather than narrowing scrutiny. Horizon Europe’s mid-project update requirement means the document cannot be written once and ignored; it is checked against actual practice at reporting milestones.

    For institutions, this means DMP-writing guidance, repository access, and named data stewards are becoming a baseline service rather than a specialist offering — mirroring how research-administration functions increasingly treat authorship, funding acknowledgement, and data policy as connected obligations. For individual researchers, treating the DMP as a working document rather than a one-off application formality is now the defensible position across every major funder covered here.

    For funder-specific DMP templates and requirements, consult the relevant funder’s own guidance pages; for the broader compliance context these plans sit within, see CASRAI’s research administration resources and research-terminology dictionary.

  • Horizon Europe Data Management Plan Template: A Field-by-Field Guide

    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?

    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.