NSF Data Management Plan 2026: Requirements & Writing Guide

Every NSF proposal must include a Data Management Plan. NSF made this mandatory in 2011, and every year since, the most common mistake investigators make is submitting a plan that technically complies but communicates nothing of substance.

A thoughtful plan shows that the investigator has worked out what data the project will produce and how it'll be shared. A boilerplate plan, usually an institutional template filled in minimally or a vague promise to follow "best practices," tells the panel very little. A plan that's thinner still can make reviewers wonder whether the team understands what the program expects.

A DMP is not primarily an administrative obligation. It is a statement of scientific values. Investigators who think carefully about data sharing and write a DMP that reflects that thinking come across as better scientists, not just better compliance officers. This guide covers what NSF requires, what changed in NSF's current DMSP guidance, how reviewers actually use the DMP, and what the best plans look like.

For the live opportunity path, use the Grantsights grant database to check NSF program pages before you draft. DMP expectations can vary by directorate, and a single program solicitation can add a repository, metadata, or privacy requirement that the general PAPPG page does not repeat.

Where official sources stop: NSF's PAPPG and public access pages tell you the rule, but they do not score whether a 2-page plan reads like a real operating plan. Grantsights adds the reviewer lens: data type, repository, access timing, license, owner, and budget have to line up in the same proposal package.

6-Point NSF DMP Review Checklist

Use this 6-point checklist before submission. According to NSF, the 2-page data management and sharing plan is required with a proposal and must describe how the project will manage, disseminate, and share research results. According to NSF's public data management page, the plan may cover data types, standards, access policies, reuse policies, and archiving. According to Research.gov reporting rules, awardees also report on data sharing and project outcomes after funding.

The strongest plans don't sound like legal language. They read like an operating plan. For example, a mixed-methods education proposal might produce survey data, interview transcripts, codebooks, and R scripts. A weak draft says the data will be "stored securely and shared after publication." A stronger version names ICPSR for de-identified survey data, describes restricted access for interview transcripts, commits R scripts to Zenodo with a DOI, and assigns the evaluation lead to create the codebook by Month 18. That revision answers four likely reviewer concerns in 4 sentences.

A second pattern fits engineering and computer science proposals. Picture a sensor project that will generate raw signal files, cleaned CSV files, calibration scripts, and final model outputs. A weak DMP treats all 4 data types the same. A better DMP splits them: raw files stay in institutional storage because of size, cleaned CSV files go to Zenodo within 6 months of publication, scripts go to GitHub with Zenodo archiving, and model outputs are tied to the paper they support. Reviewers could see what would be public, what would be preserved, what would be reusable, and what would be too large to share without a reason.

Use this as the practical test: if a reviewer covered the project title and read only the DMP, could they name your 3 most important data products, the repository for each one, the access timing, the license, and the person responsible? If not, the plan is still too generic.

Skip a generic template if your project includes human subjects data, sensitive location data, Indigenous data governance, export-controlled material, proprietary partner data, or software outputs. Those cases need a DMP that explains limits, not a boilerplate promise to make everything public.

For adjacent proposal pieces, connect this section to NSF broader impacts, NSF budget preparation, and grant data management and recordkeeping. Reviewers should see the same repository, staffing, and budget choices across all 3 pages of your proposal package.

June 2026 Source Check: What Changed Since Older DMP Templates

Older university templates still say "Data Management Plan" and PDF upload by default. NSF's current pages use "Data Management and Sharing Plan" and point applicants to both current PAPPG language and Policy Notice NSF 26-202.

What NSF Requires in the 2-Page Data Management Plan

The NSF PAPPG specifies that the DMP must address 5 questions. According to NSF, those questions cover data products, metadata standards, access and sharing policies, reuse and redistribution, and long-term archiving.

1. The types of data, samples, physical collections, software, curriculum materials, and other materials to be produced in the course of the project. This is the inventory question. What will you actually create? For a computational project: code, datasets, model outputs, software packages. For a field biology project: specimen collections, GPS coordinates, photos, sequence data, environmental measurements. Be specific. Reviewers need to understand what data you'll actually produce.

2. The standards to be used for data and metadata format and content (where existing standards are absent or deemed inadequate, this should be documented along with any proposed solutions or remedies). What format will your data be in? FASTQ for sequencing data. NetCDF for climate model outputs. CSV with a data dictionary for survey data. Metadata standards matter here too. Darwin Core for biodiversity data. Dublin Core for general digital objects. If no community standard exists, say so and explain how you will document your data.

3. Policies for access and sharing including provisions for appropriate protection of privacy, confidentiality, security, intellectual property, or other rights or requirements. Who can access the data, when, and under what conditions? For most basic research, the answer is: public access after publication. For human subjects data: IRB requirements, consent limitations, de-identification procedures. For proprietary data: clear statement about licensing terms and any embargo period before release.

4. Policies and provisions for re-use, re-distribution, and the production of derivatives. Under what license will data be released? Creative Commons CC-BY (attribution required) is standard for most research data. CC0 (no restrictions) is preferred for data in repositories like Zenodo. If you are generating software, what license? MIT, Apache, or GPL are common.

5. Plans for archiving data, samples, and other research products, and for preservation of access to them. Where will the data live after your project ends? University servers are often not sufficient because institutions don't guarantee indefinite access. A named external repository with stated long-term preservation commitments is expected.

NSF Public Access and DMSP Alignment: 3 Checks for 2026

NSF's current public access materials and DMSP guidance make the DMSP more than a short storage note. The key checks affecting 2026 proposals:

Publication and data plan alignment. Do not describe one repository in the DMSP and another route in your broader dissemination plan. Reviewers should see one coherent access path for publications, data, code, and other research products.

Data-product specificity. NSF's DMSP guidance lists data, samples, physical collections, software, curriculum materials, and other materials. A strong plan separates those products instead of treating all outputs as "data."

Research.gov readiness. NSF's SBE guidance says the Research.gov DMSP tool was released on April 27, 2026. If your directorate or solicitation points to that workflow, build the plan in the tool rather than assuming an older PDF-only process.

Budget link. Storage, curation, repository fees, transcription, de-identification, and staff time may need budget support when they are real project costs. If the DMSP promises work that nobody is funded to do, reviewers notice the gap.

What Reviewers Actually Score in 2 Minutes

NSF reviews use two criteria: Intellectual Merit and Broader Impacts. According to NSF's DMSP guidance (opens in a new tab), the plan is reviewed as an integral part of the proposal and considered under Intellectual Merit or Broader Impacts or both, as appropriate for the scientific community of relevance.

In a field where data reuse drives progress, a thoughtful plan supports the Intellectual Merit case; where dissemination and access are the point, it feeds Broader Impacts. Either way, a perfunctory DMP undermines the proposal.

What reviewers look for in a DMP:

Specificity. "Data will be archived in Zenodo under CC-BY license with DOIs assigned to each dataset" is better than "Data will be made available following best practices."

Feasibility. A plan that says you will deposit 50TB of high-resolution microscopy images in a public repository needs to address storage costs and bandwidth. A plan that is technically infeasible reads as naive.

Match between data types and repositories. Using GenBank for genomic sequence data, ICPSR for survey data, and Zenodo for mixed outputs signals domain knowledge. Proposing to deposit all data in a university's SharePoint folder signals the opposite.

Timing. When will data be deposited? At project completion? At publication? Quarterly? Stating a timeline demonstrates a real plan.

Writing a DMP That Stands Out in 5 Paragraphs

A DMP that scores well follows this structure in two pages:

Paragraph 1: Data inventory. List the types of data your project will produce. Be specific about formats, estimated volumes, and data collection timelines. Name the instruments, instruments or software used.

Paragraph 2: Standards and documentation. Explain what metadata standards apply. If you are creating a new instrument or dataset without established standards, describe how you will document it.

Paragraph 3: Access and sharing. State specifically who can access the data, under what conditions, and when. If there are IRB or consent constraints, describe them precisely. Note the license terms.

Paragraph 4: Repositories and preservation. Name the specific repositories you will use. Link to their preservation policies if possible. Explain how data will remain accessible after the grant period ends.

Paragraph 5: Resources and responsibility. Who on the team is responsible for data management? What resources (budget, storage, personnel) have been allocated? This paragraph matters more now that NSF's public access materials tie data sharing to post-award reporting.

The DMP should read as if you have already thought through the full data lifecycle of your project. A plan drafted in a rush the night before submission usually shows it. The ones that stand out are written by investigators who don't treat data sharing as an afterthought, but as part of the research plan itself.

Program-Specific DMP Requirements: 6 Common Variations

NSF programs vary in their DMP expectations. Some key variations:

Social and behavioral sciences. ICPSR is the preferred repository for many SBS datasets, especially survey data and longitudinal studies. DMPs should address participant confidentiality, de-identification procedures, and data use agreements.

Environmental and geosciences. Many programs expect data to be deposited in domain repositories like NCAR's Research Data Archive, the Interdisciplinary Earth Data Alliance (IEDA), or the BCO-DMO for ocean data. Using the correct domain repository is noticed.

Computer science and engineering. Code is data. NSF increasingly expects software outputs to be deposited in repositories like GitHub combined with Zenodo archiving (for persistent DOIs), or Software Heritage. A DMP that ignores software is incomplete.

Education research. IRB constraints are common. The DMP needs to address consent limitations, de-identification, and the specific conditions under which restricted data can be shared with qualified researchers.

Always read the program solicitation or Dear Colleague Letter for specific DMP guidance. Some solicitations have DMP requirements that go beyond the general PAPPG requirement.

What the NSF DMP Requirements Don't Tell You: 4 Reviewer Realities

NSF does not review DMPs before the award. The DMP is reviewed by panels as part of merit review, but NSF does not have a pre-award compliance review specifically for DMPs. The binding requirements kick in post-award: you are expected to implement the plan you described.

Data management plans are referenced in annual reporting. Your Research Performance Progress Report (RPPR) asks about data sharing activities. Investigators who described detailed plans in their DMP and then do nothing for three years are in a difficult position when they file their progress reports.

Changing your DMP mid-award is allowed. If you discover during the project that a different repository is more appropriate, or that the data types changed, talk to your program officer about how to document the change, and describe what you actually did in your annual project report.

The 2-page DMP limit is firm. If you need more room, NSF lets you put additional data management information in the 15-page Project Description, but says the DMSP can't be used to get around that page limit. A plan over 2 pages risks a compliance problem, so don't test it.

Related NSF Guides

• NSF Grants: The Complete Guide
• NSF Broader Impacts Guide
• NSF Grant Success Rates
• NSF Budget Preparation Guide
• How to Write a Data Management Plan for Grants
• Grant Data Management and Recordkeeping

Grantsights Trust Check: Apply or Skip This Path

Use this page as a decision screen before your team spends writing time. Apply the guidance when the applicant type, deadline, budget size, required evidence, and official submission path all match the source record. Skip or pause when the fit is only thematic, the applicant cannot document eligibility, the deadline leaves no time for review, or the official source points to a different route.

Sources

• NSF Data Management and Sharing Plan guidance: nsf.gov/funding/data-management-plan (opens in a new tab)
• NSF SBE Data Management and Sharing Plan guidance: nsf.gov/sbe/data-management (opens in a new tab)
• NSF Proposal and Award Policies and Procedures Guide: nsf.gov/policies/pappg (opens in a new tab)
• NSF Public Access: nsf.gov/public-access (opens in a new tab)
• Research.gov Project Reports: research.gov/research-web/content/AboutProjectReports (opens in a new tab)
• NSF Report Your Progress and Outcomes: nsf.gov/awards/report-your-outcomes (opens in a new tab)
• Zenodo (multidisciplinary open repository): zenodo.org (opens in a new tab)
• ICPSR (social science data archive): www.icpsr.umich.edu (opens in a new tab)