NIH Data Management and Sharing Plan 2026: What the New Format Actually Requires

What Changed on May 25, 2026 and Why NIH Did It

NIH's 2023 Data Management and Sharing Policy was, by most accounts, well-intentioned but burdensome in practice. The six-element structure required researchers to address data types, related tools and software, standards, preservation timelines, access controls, and oversight mechanisms — all in a two-page attachment that most applicants had never written before the policy launched. Feedback from the extramural community was consistent: the format prompted repetitive, hedged language that satisfied the letter of the requirement without meaningfully advancing data sharing in practice.

NOT-OD-26-046, published in spring 2026, announced a pilot simplification. Starting with applications due on or after May 25, 2026, the DMS Plan format page is restructured around three core yes/no questions about sharing commitments, with narrative space for explaining how you'll carry them out. NIH framed this explicitly as a pilot and said it will evaluate whether additional changes are needed over the following year. That last point matters: the format will likely evolve again, which means another transition is probable before the policy fully matures.

If your next application has a due date before May 25, 2026, you can use either the old or new format — NIH accepted both during the transition window. If you're submitting after that date, you're on the new format. This guide covers the new one, and what you actually need to decide before you write it.

The 2023 Policy vs. the 2026 Format: What Stayed, What Shifted

The most important thing to understand about the 2026 change is what did not change. The underlying 2023 DMS Policy is still fully in effect. All researchers submitting applications for projects that generate scientific data are still required to plan for sharing that data. The policy's definition of "scientific data" covers processed data that supports published findings, not every raw file you produce in the lab. If you qualified as exempt from the policy before May 2026 because your project won't generate shareable data, you still qualify as exempt. The new format doesn't expand the scope of who needs to comply.

What shifted is the structure of the document itself. The old format asked you to describe six elements in narrative form, and most researchers spent considerable space restating obvious facts — yes, we will use validated standard formats when they exist. The new format is organized around commitments you can affirm or note exceptions to. This is a fundamentally different framing: instead of describing your practices, you're making attestations, and the narrative space is reserved for explaining how you'll meet each commitment or why a specific exception applies.

In practical terms, a well-executed 2026 DMS plan can be shorter and more direct than its 2023 predecessor. But "shorter" does not mean "generic." Plans that attract program officer questions are still the ones that read as copy-paste boilerplate — vague repository choices, unspecified timelines, or missing justification for a controlled-access approach. The new format reduces the amount of required language; it doesn't reduce the need to think through your actual sharing approach before you write.

The New Format: Three Questions and What They're Actually Asking

The 2026 pilot format centers on three yes/no questions. Each one sounds simple and is not.

After the three questions, the format includes a narrative section where you describe how you'll carry out the commitments — repository name, data format, estimated timing, any access controls, and how data sharing costs are budgeted. Think of this as the "show your work" section. A plan that answers all three questions "yes" but leaves the narrative blank is incomplete and will likely generate a Just-In-Time request or a pre-award negotiation.

Choosing a Data Repository: The Decision That Shapes Everything Else

Repository selection is the most consequential decision in your DMS plan, and many researchers treat it as an afterthought. The repository you choose determines your retention timeline (answering question 3), your access structure (relevant to question 1), and your likely data curation burden once the project is funded. Getting it wrong doesn't disqualify your application, but it can create compliance headaches during the award.

NIH maintains a list of NIH-supported repositories and a separate list of generalist repositories. For most basic science applications, the right starting point is a domain-specific NIH-supported repository: dbGaP for human genomics data, GEO for gene expression, SRA for sequencing data, and so on. These repositories are pre-approved as meeting NIH's standards, their retention policies satisfy question 3 by default, and reviewers recognize them immediately. If your data type doesn't fit a domain-specific repository, generalist repositories like Zenodo, Dryad, or Figshare are acceptable as long as you confirm they meet the retention requirement.

Two situations warrant more careful thought. First, if any of your data involves human subjects, your repository choice intersects with your IRB protocol and informed consent language. If your consent form doesn't explicitly cover data sharing in a public or controlled-access repository, you may need to either use a controlled-access repository like dbGaP's controlled tier, or plan a consent amendment before depositing data. Worth resolving before submission, not after. Second, if you're generating data in collaboration with industry partners, check whether your agreement restricts data sharing — and if so, document that restriction clearly in question 1 and the narrative. Silence on this point is a compliance risk that surfaces at the worst time.

Budgeting for Data Sharing Without Overcomplicating the Justification

Data sharing costs are allowable as direct costs under the 2023 DMS Policy and remain so under the 2026 format. NIH has been consistent on this point since the policy launched: you can budget for data curation, format conversion, metadata documentation, repository submission fees, and related personnel time. You don't have to hide these costs in a miscellaneous line or absorb them from other budget categories.

That said, the justification needs to be specific to survive budget review. "Data sharing costs: $5,000/year" without further explanation is exactly the kind of line that gets flagged during pre-award review. A more defensible approach is to identify the specific activity — for example, a research coordinator spending approximately five percent effort in years three and four on data curation and submission — and connect it to the timing commitment you described in question 2. If your plan says data will be deposited with each publication, reviewers can follow the logic and the cost is proportionate.

For modular budget applications, you don't need to justify individual line items in the same detail, but the budget narrative should mention that data sharing costs are included. Leaving the DMS plan silent on resources while budgeting for them creates a mismatch that a careful reviewer will note. The fix is easy: one sentence in the budget narrative and one sentence in the DMS plan narrative pointing to each other.

What Reviewers and Program Officers Actually Notice

DMS plans are not scored using a dedicated review criterion. They're assessed as part of the Resource Sharing Plan requirement and marked as acceptable or not acceptable. "Not acceptable" can delay your award, but an acceptable DMS plan doesn't boost your impact score. This asymmetry shapes how most reviewers read these plans: they're looking for red flags, not for opportunities to reward good data stewardship.

The red flags that come up most often are a plan that names a repository as TBD, a plan with no mention of timing, a plan that checks yes on question 1 but proposes only controlled-access sharing without justification, and a plan where the budget section and the DMS plan are inconsistent with each other. That last one is surprisingly common in multi-PI applications where the budget is written by one person and the DMS plan by another.

Frequently Asked Questions