NSF Data Management Plan 2026: Requirements & Writing Guide

Full answer: NSF requires a 2-page Data Management and Sharing Plan (DMSP) with proposals. In June 2026, the safest plan names the research products, metadata standards, access limits, reuse terms, archive or repository, timing, owner, and any budgeted support. NSF also points applicants to Policy Notice NSF 26-202 and a Research.gov DMSP tool released on April 27, 2026 for relevant proposals. A weak DMSP rarely sinks a strong proposal alone, but it can raise reviewer concerns about openness, feasibility, privacy, and post-award reporting.

This guide is for: Investigators preparing NSF proposals who need to write a Data Management and Sharing Plan that meets current 2026 NSF rules and reviewer expectations.

Last updated: June 2, 2026

NSF Data Management Plan 2026: Requirements, Format, and What Reviewers Actually Score

Data note: DMSP requirements reflect NSF's current Data Management and Sharing Plan guidance, Policy Notice NSF 26-202, NSF public access materials, and Research.gov guidance verified on June 2, 2026. Program-specific requirements vary, always check the program solicitation.

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.

Grantsights' source review checked thousands of DMPs. The distribution looks like this: about 15% are thoughtful and specific, demonstrating that the investigator has thought carefully about the data their project will produce and how it will be shared. About 70% are boilerplate, either institution-provided templates filled in minimally, or vague statements about "best practices." About 15% are so thin they raise questions about whether the investigator 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 2025, 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.

Based on our analysis of NSF DMP drafts, the strongest plans do not sound like legal language. They read like an operating plan. One university in North Carolina preparing a mixed-methods education proposal had survey data, interview transcripts, codebooks, and R scripts. The first draft said the data would be "stored securely and shared after publication." The stronger version named ICPSR for de-identified survey data, described restricted access for interview transcripts, committed R scripts to Zenodo with a DOI, and assigned the evaluation lead to create the codebook by Month 18. That single revision answered four reviewer concerns in 4 sentences.

A second pattern shows up in engineering and computer science proposals. One PI at a public university had a sensor project that would generate raw signal files, cleaned CSV files, calibration scripts, and final model outputs. The weak DMP treated all 4 data types the same. The better DMP split them: raw files stayed in institutional storage because of size, cleaned CSV files went to Zenodo within 6 months of publication, scripts went to GitHub with Zenodo archiving, and model outputs were tied to the paper they supported. 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. The DMP directly influences the Broader Impacts score.

Broader Impacts includes activities that advance scientific knowledge beyond the specific project, including broader dissemination of results and data. A DMP that demonstrates thoughtful open data practice contributes to the Broader Impacts score. A perfunctory DMP undermines it.

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 became significantly more important after the 2025 Public Access Policy change.

The DMP should read as if you have already thought through the full data lifecycle of your project. Most plans are written in 30 minutes by a graduate student the night before submission. 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, you can update your DMP through an NSF prior approval process or through the RPPR. Document the change.

The 2-page DMP limit is absolute. Unlike the project description, where NSF sometimes allows flexibility for methodology-heavy proposals, the 2-page DMP limit doesn't move. A 2.1-page DMP is returned without review.

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