NSF’s Move to the Research.gov DMSP Webform: What Changed

Since April 27, 2026, NSF proposers no longer upload a Data Management and Sharing Plan (DMSP) as a two-page PDF. Instead, Research.gov provides a structured DMSP webform built directly into the proposal preparation process. This guide explains what actually changed, why, and how to carry the content of an existing narrative plan into the new format.

What changed on April 27, 2026

NSF replaced the free-text, uploaded-PDF Data Management and Sharing Plan with a structured webform inside Research.gov. Rather than writing an open narrative and formatting it as a two-page document, proposers now complete a series of defined fields, organized per data or research product category, directly in the proposal system.

The change applies going forward from the release date, not retroactively: proposals submitted before April 27, 2026 used, and continue to be represented by, the PDF-upload format, and those documents remain accessible on the DMSP page for those proposals. Proposals submitted on or after April 27, 2026 must use the Research.gov webform, unless the proposer instead provides a justification that a detailed plan is not needed (see below). Because that date has now passed, this is a completed transition for any proposal in preparation today, not a future one to plan around.

The policy basis: PAPPG 24-1, Supplement 2

The underlying policy authority for this change is NSF’s PAPPG 24-1, Supplement 2 policy notice, published in January 2026. It’s worth separating two dates that get conflated in secondary summaries: the policy notice is effective for financial assistance actions dated on or after January 22, 2026, while the actual webform tool inside Research.gov went live later, on April 27, 2026. The policy basis and the tool’s release are two different milestones, roughly three months apart.

The 8 sections of the new webform

Where the old PDF was an unstructured narrative, the Research.gov DMSP tool asks the proposer to complete the same substance broken into eight defined sections, repeated for each data or research product category in the project:

1. Data/Research Product Category – select a predefined category title, or create a new one for a product type not already listed.
2. Access Policies and Limitations – a dropdown-based field describing any restrictions on access; select “Not Applicable” if none apply.
3. Data Standards and Metadata – the formatting and metadata standards that will be applied to the data or product.
4. Provenance – the source of the data or product, for example “New Data Collection” versus an existing dataset or resource being reused.
5. Public Archiving – where the data or product will be deposited or shared: a named repository or institutional resource.
6. Timeline for Public Accessibility – when the data or product becomes available, typically tied to associated publication.
7. Data Availability – how long the data will remain available. If availability is planned for less than two years after project completion, a justification is required.
8. Accountability – the named Senior Personnel on the proposal responsible for carrying out the plan.

Read across these eight fields and the substance is largely the same ground that a well-written narrative DMSP already covered – what data will be produced, how it will be described, where it will live, when it becomes accessible, how long it stays available, and who is accountable. What’s genuinely new is that NSF now collects that content as discrete, structured fields per product category rather than as continuous prose, which is what makes the plan easier for NSF’s systems to process consistently across proposals, even though it still isn’t a machine-actionable plan in the Research Data Alliance sense – see the note on that distinction below.

How to update your plan

If your DMSP is still in progress

If you’re preparing a new proposal, draft your plan content first – the same way you would have for the PDF format – then transfer it into the webform’s eight fields rather than trying to compose directly inside the tool for a complex, multi-product project. Working outside the tool first also gives your research administration office something concrete to review before proposal submission.

If you already have a PDF-based plan

A completed narrative DMSP from a prior proposal isn’t wasted; it maps onto the webform reasonably directly. As a structural starting point:

• The section of a narrative plan describing what data/products will be generated becomes one or more Data/Research Product Category entries – a narrative that lumped several product types into one paragraph should generally be split into separate categories in the webform, since each category gets its own set of the remaining seven fields.
• Language on access restrictions, embargoes, or sensitive data handling maps to Access Policies and Limitations.
• References to file formats, metadata schemas, or documentation standards map to Data Standards and Metadata.
• A description of how the data arises (new collection, reuse of an existing dataset, derived product) maps to Provenance.
• The named repository or archive commitment maps to Public Archiving.
• Any stated timeframe for release, often tied to publication, maps to Timeline for Public Accessibility.
• A stated retention period maps to Data Availability – check specifically whether your prior plan committed to at least two years post-completion; if not, you’ll now need to supply an explicit justification in that field.
• The responsible personnel named in the plan maps to Accountability, which now requires naming a specific Senior Personnel on the proposal rather than a general institutional office.

Treat this as a structural crosswalk, not a guarantee that every narrative plan translates cleanly – a plan written loosely enough to avoid ever specifying a retention period or a single accountable person will surface exactly those gaps once it’s forced into discrete fields, which is arguably the point of the redesign.

The justification route, if a detailed plan isn’t needed

Not every proposal produces data or research products that require a detailed plan. Where that’s genuinely the case – for example, no data or research products will result from the proposed work – NSF allows the proposer to submit a justification explaining why a detailed DMSP is not needed, in place of completing the full webform. This isn’t a way to avoid the new format for a project that does produce data; it’s an existing NSF allowance carried forward into the new tool for projects where a substantive plan was never going to apply.

Directorate-specific requirements

NSF directorates, offices, divisions, and programs can layer additional data management and sharing requirements on top of the baseline policy, and NSF publishes those unit-specific expectations on its website. Multiple research-administration offices have reported that the Research.gov webform itself is tailored to the primary Directorate selected for the proposal – check your program’s specific solicitation and directorate guidance before finalizing your entries, since the fields available or expected can vary by unit.

What hasn’t changed

• The underlying Data Management and Sharing Plan requirement itself is unchanged – this is a change to the submission format, not a new or removed obligation.
• NSF’s DMSP is still directorate- and program-specific in its detailed expectations, the same way it was under the PDF format; the webform doesn’t standardize substance across NSF, only the structure of how it’s collected.
• The plan is still evaluated as part of proposal review and remains binding once an award is made; moving to structured fields doesn’t loosen accountability for what’s committed.
• NSF’s requirements remain distinct from NIH’s. NIH separately moved its own Data Management and Sharing Plan to an abbreviated format in 2026, but the two changes are unrelated funder-specific decisions on different timelines – see our NIH vs. NSF Data Management Plans guide for how the two agencies’ requirements compare more broadly.

A structured form is not the same as a machine-actionable plan

It’s worth being precise about what this change is and isn’t. Structuring the DMSP into defined webform fields makes the plan easier for NSF to process consistently, but it does not make NSF’s DMSP a machine-actionable plan in the sense the Research Data Alliance uses the term – a plan conformant to the RDA DMP Common Standard, structured so that commitments like repository choice, licensing, and release timelines can be validated and reused by other systems without funder-specific parsing. The Research.gov webform is a funder-specific structured intake format, not an RDA-schema or JSON-LD-conformant document another system could ingest directly. Don’t conflate the two when describing NSF’s plans to a data steward or CRIS administrator.

Frequently asked questions

Do I need to resubmit a DMSP for an already-funded NSF award?

No. The webform requirement applies to proposals submitted on or after April 27, 2026. Documents from proposals submitted before that date remain on file in the PDF format and are still accessible on the award’s DMSP page; NSF has not indicated that existing awards need their plans retroactively converted.

What if my project has several very different types of data?

Create a separate Data/Research Product Category entry for each distinct type. Each category gets its own complete set of the eight fields (access, standards, provenance, archiving, timeline, availability, accountability), so lumping unrelated data types into one category will produce a plan that doesn’t accurately describe any of them.

Who should be named under Accountability?

A specific Senior Personnel listed on the proposal, not a general departmental or research-office contact. Confirm with that individual before naming them, since the webform ties responsibility for the plan’s execution to a named person rather than an office.

Does this change apply to every NSF directorate the same way?

The baseline eight-section structure applies proposal-wide, but individual directorates, offices, divisions, and programs can specify additional requirements, and the webform is reported to be tailored based on the proposal’s primary Directorate. Check your specific program’s current solicitation rather than assuming a plan written for one directorate’s expectations transfers unchanged to another.

Is the new webform a machine-actionable DMP?

No. It’s a structured, funder-specific intake form. A machine-actionable plan under the RDA DMP Common Standard is a distinct, schema-conformant format designed for cross-system reuse; NSF’s webform doesn’t meet that definition even though both involve moving away from free-text narrative.