A data management plan (DMP) template is not one universal form. It is a family of related question sets — some published by data-curation organizations, some by funder consortia, some embedded directly in a grant portal — that all converge on roughly the same underlying content, organized differently. This guide maps that shared structure: the sections nearly every DMP template asks for, what belongs in each one, and how the major template families (DCC/DMPTool-style checklists, the Science Europe common template, and funder-embedded formats) differ in how they group and order the same material. It does not walk through any single funder’s exact wording — for that, see the funder-specific guides linked throughout, which this page is designed to sit upstream of.
What “the DMP template” actually refers to
CASRAI’s DMP template entry defines a template as a reusable question set a researcher answers to produce a specific plan, as distinct from the DMP itself, which is the completed document. In practice, three kinds of template exist side by side:
- Institutional / tool-hosted templates — DMPTool and DMPonline host a library of templates (funder-specific and generic) that a researcher fills in through a web form; see CASRAI’s DMPTool vs. DMPonline comparison for how the two platforms differ.
- Funder-agnostic reference checklists — published by data-curation bodies as a generic starting point, not tied to any one funder’s submission system.
- Funder-embedded question sets — the exact fields a specific agency’s application system requires, which may be a full narrative template, a short structured webform, or an abbreviated yes/no format, and which increasingly diverge from one another in length and structure (see the funder-specific section below).
Nearly all of them, regardless of which category they fall into, ask about the same underlying set of concerns. The next section walks through those concerns as a single generic structure.
The core sections nearly every DMP template asks for
Strip away funder-specific wording and formatting, and a DMP template is almost always organized around some version of these seven areas.
1. Data description and types
What data the project will generate or reuse: file formats, approximate volume, whether it is observational, experimental, simulated, or derived from existing sources, and whether any of it is third-party data with its own reuse restrictions. This section sets the scope everything else in the plan responds to — storage and sharing decisions downstream only make sense in light of what the data actually is.
2. Metadata and documentation standards
Which metadata schema will describe the data so it remains interpretable to someone who was not on the original research team — discipline-specific schemas where one exists, or a general-purpose standard otherwise. This is also where naming conventions, version control practices, and any planned use of persistent identifiers for the dataset itself typically get documented.
3. Storage, backup and security during the project
Where data lives while the project is active: institutional storage, a lab server, a cloud platform, and what backup redundancy and access controls protect it against loss or unauthorized access before the project ever reaches the sharing stage. For anything containing sensitive or regulated information, this section also states what security tier the storage environment meets.
4. Ethical, legal and consent considerations
Whether the data involves human subjects, needs de-identification before it can be shared, is covered by a data use or data sharing agreement, or is otherwise restricted by law, contract, or funder confidentiality terms. Reviewers treat this section as a compliance check, not a formality — a plan that proposes open sharing of data that legally cannot be shared openly is a common rejection reason.
5. Roles and responsibilities
Who is accountable for each part of the plan — day-to-day data management, quality control, eventual deposit into a repository — named by role if not by individual, since personnel commonly change over a multi-year award. Larger or multi-institutional projects increasingly name a specific data steward or data manager here rather than leaving the responsibility implicit with the principal investigator.
6. Budget and resources
What data management actually costs: repository deposit fees, storage beyond institutional defaults, staff time for curation, and any specialized software or hardware the plan depends on. Not every template requires a dedicated budget section, but funders that allow data management costs to be charged to the award (directly or as part of indirect costs) generally expect this reasoning to be visible somewhere in the plan.
7. Sharing, preservation and repository choice after the project
Where the finished dataset will ultimately be deposited, under what license or access conditions, on what timeline relative to publication or award closeout, and for how long it will be preserved. This is usually the section reviewers scrutinize hardest, since it is the concrete, checkable commitment the rest of the plan exists to support — see the repository criteria discussed in CASRAI’s DMP review criteria guide.
How template structure varies by provider
The seven areas above show up in every major template family, but grouped and worded differently enough that the same plan can look structurally different depending on which template produced it.
DCC-style checklists (DMPonline, and the template libraries DMPTool draws from)
The Digital Curation Centre’s widely referenced Checklist for a Data Management Plan organizes DMP content into thematic sections covering administrative and descriptive information, data collection, documentation and metadata, ethical and legal compliance, storage and backup, selection and preservation, data sharing, and responsibilities and resources — close to a one-to-one match with the seven core areas above, split slightly differently. This is the structure underlying most templates hosted in DMPonline and much of what DMPTool offers as its generic or discipline templates, as opposed to the funder-specific templates both tools also host.
Science Europe’s common template
Science Europe publishes a shorter “Core Requirements for Data Management Plans” template intended as a common reference point across European funders, expressed as a small set of core questions covering data description, standards and metadata, storage and security, legal and ethical requirements, and data sharing and long-term preservation. It is deliberately more compact than the DCC checklist and is meant to be adapted or extended by individual funders rather than used unmodified — Horizon Europe’s own DMP requirements descend from this lineage; see CASRAI’s Horizon Europe FAIR Data Management Plan guide for the funder-specific version.
Funder-embedded formats — and why they’re diverging further from the generic structure
A funder’s own submission format is not obligated to preserve the generic seven-section shape at all, and recent changes show several major funders moving away from it. NIH’s Data Management and Sharing Plan and NSF’s directorate-level DMP requirements differ enough in required elements, length, and submission mechanics that CASRAI covers them in a dedicated comparison — see NIH vs. NSF Data Management Plans: What Actually Differs. Clinical trial data management plans add a further layer of protocol- and regulatory-driven structure on top of the generic template — see Data Management Plan for Clinical Trials. In every case, treat the generic structure in this guide as the map and the funder-specific guide as the terrain — write to the funder’s actual required fields, not to this page’s section headings.
Generic structure versus a filled-in plan
A template tells you which questions to answer; it does not answer them for you. Knowing that section three should cover storage and backup does not, by itself, tell a reviewer what a defensible answer to that question looks like for a specific project. CASRAI’s Data Management Plan Worked Examples guide picks up exactly where this page leaves off: two full, filled-in plans showing what completed answers actually read like, assuming the structural map this page provides.
What reviewers check against this structure
Funders and institutional reviewers do not simply confirm that every template section was filled in — they check whether the content in each section is specific, internally consistent, and actually achievable given the project’s budget and timeline. CASRAI’s DMP Review Criteria guide covers what reviewers actually look for section by section, independent of which specific template produced the plan.
Beyond the static template: machine-actionable DMPs
Every template described above ultimately produces a static document — a PDF, a webform submission, or prose in a grant application. A separate, related effort addresses a different problem: making the commitments inside a DMP (repository choice, license, timelines) structured enough that other systems can read and validate them without a human re-parsing prose. The RDA DMP Common Standard and its JSON-LD serialization are the leading effort in this direction. As of 2026, neither NIH’s nor NSF’s updated DMP formats are conformant with this standard — a structured webform is not the same thing as a machine-actionable plan — so template structure and machine-actionability remain two separate axes to track, not one.
Frequently asked questions
What are the standard sections of a DMP template?
Most templates cover some version of: data description and types, metadata and documentation standards, storage and security during the project, ethical and legal considerations, roles and responsibilities, budget, and sharing/preservation after the project. Exact section names and groupings vary by template provider.
Is there one universal DMP template every funder uses?
No. Reference checklists like the DCC’s and common templates like Science Europe’s provide a shared starting structure, but individual funders adapt, shorten, or replace that structure in their own application systems — see the funder-specific guides linked above for exact requirements.
What’s the difference between a DMP template and a completed DMP?
A template is the reusable question set; a completed DMP is a specific project’s answers to that question set. Two researchers using the identical template will produce differently structured-but-comparable plans once filled in.
Do I need to use a different template for every funder?
Usually yes, in the sense that you should answer the specific questions your funder’s application system asks rather than submitting a generic template unmodified — but the underlying content overlaps heavily enough that a plan drafted against the generic structure in this guide requires adaptation, not a rewrite, for most funders.
How long should a completed data management plan be?
Length is funder-defined and varies widely — from a two-page narrative to a short structured webform with word-capped fields — so there is no single correct length independent of the specific template being completed.
