A Data Management Plan (DMP) is the general concept: a document describing how research data will be handled across a project’s lifecycle. NIH and NSF both require one, but their specific rules — what to call it, how long it can be, where it goes in the application, and what template to use — differ, and both agencies changed those specifics in 2026. This guide covers the concrete mechanics for each funder, then covers something neither funder’s own guidance addresses: how to make the resulting plan machine-actionable rather than a static document that has to be re-read by hand every time someone downstream needs to know what it says.
NIH: the Data Management and Sharing (DMS) Plan
NIH’s Policy for Data Management and Sharing took effect for competing grant applications, contract proposals, and intramural projects with due dates on or after 25 January 2023 (NOT-OD-21-013). Since then, a DMS Plan has been required for essentially all NIH-funded research that generates scientific data, regardless of budget size — this replaced the older, narrower Data Sharing Plan requirement that applied only to applications over $500,000/year.
The policy defines six elements a DMS Plan must address:
- Data type
- Related tools, software, and/or code
- Standards (metadata, data identification, etc.)
- Data preservation, access, and associated timelines
- Access, distribution, or reuse considerations
- Oversight of data management and sharing
Mechanically: the plan is uploaded as a separate PDF attachment under the “Other Plans” attachment section of the application — not the Resource Sharing Plan section, which is a different, older requirement. NIH recommends a DMS Plan be two pages or less, though this is guidance rather than a hard system-enforced limit. If the project has associated costs for data management or sharing, those get itemized separately in the budget justification under a subheading titled “Data Management and Sharing Justification.”
NIH updated the required format again for 2026: per NOT-OD-26-046, applications with due dates on or after 25 May 2026 must use a new, abbreviated DMS Plan format rather than free-form narrative. Instead of prose addressing all six elements, the new format is a structured questionnaire: several yes/no/not-applicable questions covering sharing commitments and timelines, a 300-word-maximum justification field for any planned restrictions on sharing, a 100-word data-type-and-repository table, and (where the Genomic Data Sharing Policy applies) two additional yes/no items. The underlying policy expectations from 2023 are unchanged — this is a change to how compliance is expressed on the form, not a change to what’s required.
NSF: the Data Management and Sharing Plan (DMSP)
NSF’s requirement has gone through its own 2026 changes, including a name change: what was historically called the “Data Management Plan” in the Proposal & Award Policies & Procedures Guide (PAPPG) is now the Data Management and Sharing Plan (DMSP), per PAPPG 24-1, Supplement 2, applicable to financial assistance awarded on or after 22 January 2026. Anyone still searching for “NSF data management plan” (the older term) and “NSF data management and sharing plan” (the current one) is looking for the same requirement.
Like NIH, NSF’s page limit is explicit: the DMSP is a supplementary document of no more than two pages, and it is separate from — and must not be used to extend — the 15-page Project Description. Every proposal needs one; collaborative proposals need a single combined DMSP covering the whole project, not one per institution.
Where NSF differs meaningfully from NIH is that several NSF directorates layer their own supplemental guidance on top of the PAPPG baseline — Engineering (ENG), Mathematical and Physical Sciences (MPS), and Social, Behavioral and Economic Sciences (SBE) all publish directorate-specific expectations. Always check the specific solicitation — directorate or program-level instructions take precedence over the general PAPPG guidance, including on page limits in some cases.
Submission mechanics are also changing in 2026. Through 26 April 2026, the DMSP is submitted as a PDF uploaded under “Data Management and Sharing Plan” in Research.gov’s supplementary-documentation section, same as it has been for years. From 27 April 2026 onward, NSF replaces that PDF upload with a structured webform built directly into Research.gov — a set of questions (roughly seven, varying by directorate) with drop-downs and free-text fields, generated per category of data the project involves, rather than a single freeform document.
NIH vs. NSF: the concrete differences
| NIH DMS Plan | NSF DMSP | |
|---|---|---|
| Current name | Data Management and Sharing (DMS) Plan | Data Management and Sharing Plan (DMSP) — renamed from “Data Management Plan,” effective 22 Jan 2026 |
| Policy effective date | 25 Jan 2023 | PAPPG 24-1, Supplement 2: 22 Jan 2026 |
| Page limit | Recommended 2 pages or less (not system-enforced) | Hard limit: 2 pages, separate from the 15-page Project Description |
| Where it is submitted | “Other Plans” attachment | Supplementary documentation section (PDF until 26 Apr 2026); Research.gov webform from 27 Apr 2026 |
| 2026 format change | Abbreviated Q&A + table format mandatory for due dates on or after 25 May 2026 (NOT-OD-26-046) | Structured Research.gov webform mandatory from 27 Apr 2026 |
| Directorate/IC-level variation | Minimal — one policy applies NIH-wide | Significant — ENG, MPS, SBE and others publish supplemental guidance; solicitations can override the baseline |
Beyond the document: machine-actionable DMPs and the RDA Common Standard
Everything above describes how to produce a document (or, increasingly, a structured form response) that satisfies a funder’s compliance check. It is worth being explicit about what that does and does not solve. Even NSF’s new webform and NIH’s new abbreviated format are still, fundamentally, funder-intake formats — a repository, an institutional CRIS, or a second funder has no standard way to read what either agency’s form produced. Every downstream reader still has to re-extract the same facts (what data, what repository, what license, what timeline) by hand from a PDF or a portal export.
This is the gap the Research Data Alliance’s DMP Common Standard addresses. It is a metadata application profile — JSON Schema, aligned with the W3C Data Catalog Vocabulary (DCAT) — that expresses a DMP’s actual content (project, datasets, distributions, hosts, contacts, costs, licenses) as structured, linked data rather than prose. The current release is v1.2 (November 2025); the working group’s outputs and schema are maintained on GitHub. A DMP expressed this way is what CASRAI’s dictionary calls a machine-actionable DMP (maDMP): a living, queryable artefact rather than a static file, carrying persistent identifiers — ORCID for people, ROR for organizations, DOIs for datasets — that let systems act on it automatically instead of a human re-reading it.
In practice, this matters most at the tool layer. DMPTool (US, hosted by the California Digital Library) and DMPonline (UK, hosted by the Digital Curation Centre) are both built on the open-source DMPRoadmap platform and have both implemented RDA-Common-Standard-compliant export: DMPTool’s API returns DMP metadata in the common-standard format, capturing contributor identifiers (ORCID, ROR, and CRediT roles), repository identifiers via re3data, metadata-standard references, and SPDX license identifiers as structured fields rather than free text (see DMPTool’s own account of this work). That is the practical payoff: a DMP drafted in one of these tools can, in principle, populate a repository deposit form, feed an institutional CRIS/RIM record, or let a funder verify compliance programmatically — without anyone re-typing the plan’s contents into a second system. This is also why the CASRAI Dictionary treats DMP content as something that should cross-walk cleanly with the identifier vocabulary covered in CASRAI’s persistent-identifiers cluster and the contributor-role vocabulary in CRediT — the same ORCID iDs, ROR IDs, and CRediT roles that populate a maDMP are the identifiers a CRIS needs to reconcile that project against everything else it tracks.
One caution: do not conflate “structured form” with “machine-actionable.” NSF’s new Research.gov webform and NIH’s new abbreviated Q&A format are steps toward machine-readability at the point of submission to that one funder, but neither is, by itself, an RDA-Common-Standard-conformant maDMP that other systems can consume — they are funder-specific intake formats. A genuinely machine-actionable plan is one exported (or authored) in the RDA schema, independent of any single funder’s form.
Reviewed and revised plans
Both funders also expect a DMS Plan/DMSP to be a living reference during the award, not a one-time submission. NIH’s policy allows revisions to be submitted through the Just-in-Time process before award, and program staff can request updates; NSF similarly expects the plan to be followed and updated as the project’s data landscape becomes clearer. See CASRAI’s DMP review dictionary entry for the general concept of an ongoing plan-review process, independent of which funder’s form the plan originated in.
For the separate question of what to write once data has actually been generated and a paper is being submitted, see CASRAI’s guide on writing a data availability statement — a DMP is a prospective plan filed with the funder before the work starts; a data availability statement is a retrospective disclosure filed with the journal once the work is published. Institutions and researchers that keep the two in sync (the DAS should not promise anything the DMP did not already commit to) avoid the most common compliance gap reviewers flag.
Frequently asked questions
Is there an official NSF data management plan template?
NSF does not mandate a single government-wide template PDF — the PAPPG describes required content, and directorates (ENG, MPS, SBE, etc.) may publish their own guidance or worksheets. From 27 April 2026, the effective “template” is the structured Research.gov webform itself, which replaces the freeform PDF for new submissions. DMPTool also maintains an NSF-aligned template that pre-drafts content against the PAPPG’s required elements.
Where do I find an NIH DMS Plan template?
NIH publishes the current DMS Plan format directly on the Grants & Funding “Writing a DMS Plan” page as a downloadable format page (.docx); this is the version to use for applications due on or after 25 May 2026. DMPTool also maintains a corresponding NIH template kept in sync with the current required format.
What is the page limit for an NIH Data Management and Sharing Plan?
NIH recommends two pages or less. This is guidance, not a hard system-enforced cap the way NSF’s two-page DMSP limit is — but reviewers and program staff expect brevity, and the 2026 abbreviated Q&A format makes a longer document harder to justify in any case.
Where do I upload the NIH DMS Plan in my application?
Under the “Other Plans” attachment section of the application, separate from the Resource Sharing Plan attachment. Always confirm against the specific Funding Opportunity Announcement, which can add its own instructions.
Is data management and sharing the same requirement at NIH and NSF?
Conceptually yes — both require a prospective plan describing how project data will be managed and shared — but the specifics (naming, page limits, submission mechanism, format, and level of directorate/IC-specific variation) differ enough that a plan written for one funder should not be resubmitted unmodified to the other. See the comparison table above for the concrete differences.
