NSF Data Management Plan Example and Writing Guide

An NSF data management plan explains how a proposed project will manage, document, preserve, and share research data and related outputs. For a startup applicant, the plan should connect data practices to the actual R&D work, confidentiality constraints, partner roles, and credible access or sharing choices.

The NSF data management plan is short, but it can expose whether the team understands the evidence it will generate. A weak plan says data will be stored securely and shared as appropriate. A stronger plan names the expected data types, who owns them, how quality will be controlled, what can be shared, what cannot be shared, and how the plan fits the project and award rules.

For a company applicant, the plan is also a credibility signal. A reviewer may not expect a startup to operate like a university data repository, but they will expect the team to understand its own data. If the project depends on sensor logs, assay files, simulation outputs, manufacturing measurements, or customer-site observations, the plan should show that those records will be controlled well enough to support the research claims.

This article is NSF-first. NIH has its own data management and sharing policy, so use NIH sources when preparing NIH applications. For other NSF proposal artifacts, see the NSF biosketch guide, grant proposal anatomy, and NSF Seed Fund guide.

Quick answer: what an NSF data management plan does

An NSF data management plan tells the funder what project data will exist, how it will be organized, where it will be stored, how it will be protected, whether and how it will be shared, and who is responsible. It is not a generic cybersecurity policy. It is a project-specific plan for the research outputs created by the funded work.

What NSF expects from the plan

NSF expects the plan to be appropriate for the project. That means a software-heavy project, a wet-lab project, a hardware prototype, and a field deployment should not all have identical plans. The same boilerplate about secure storage and eventual sharing may be inadequate if the project generates specialized data, proprietary design files, biological samples, or partner-controlled data.

Appropriate does not always mean complicated. A small feasibility project may need a compact plan with clear ownership, file naming, version control, access rules, and a realistic sharing statement. A multi-partner project may need stronger controls around repositories, permissions, privacy, and handoffs. The plan should scale with the data risk and the work being proposed.

The strongest NSF data management plans are realistic. They do not promise open sharing of data that cannot legally or commercially be shared. They also do not hide behind confidentiality when some level of documentation, metadata, aggregated results, code, or publication output could be shared responsibly. The plan should show that the applicant has thought through the tension.

• Name the data. Reviewers should not have to infer whether the project creates measurements, software, datasets, protocols, models, or design files.
• Name the controls. Storage, access, backup, versioning, and quality-control choices should match the data risk.
• Name the sharing logic. Say what will be shared, when, where, and under what limits.
• Name the owner. A plan without responsible people is a policy wish, not an operating plan.

NSF data management plan example structure

A useful NSF data management plan example can be built around six short sections: data types, standards and documentation, storage and security, access and sharing, preservation, and responsibilities. The final plan should follow the current solicitation, but this structure helps a startup avoid generic language.

Do not copy this structure blindly if the solicitation asks for something more specific. Use it as a thinking tool. The final plan should use the funder's terminology, fit within page limits, and match the project data.

NSF data management plan vs NIH data management and sharing plan

NSF and NIH both care about data, but the policies and terminology are not interchangeable. NIH has a specific Data Management and Sharing policy with its own elements and guidance. NSF data management plans are tied to NSF proposal requirements and directorate or solicitation expectations. A startup applying to both agencies should not paste the same plan into both applications.

How startups should handle sensitive or proprietary data

Startup applicants often generate data tied to intellectual property, customers, regulated workflows, security-sensitive systems, or partner agreements. That does not mean the data management plan should simply say nothing can be shared. It should explain what data exists, what restrictions apply, and what responsible sharing or documentation remains possible.

• Be specific about restrictions. Intellectual property, privacy, export control, and partner contracts are different constraints.
• Offer what is realistic. Metadata, protocols, code snippets, aggregated results, or publications may be shareable even when raw data is not.
• Do not overpromise openness. If sharing would violate obligations, say so and explain the alternative.
• Do not under-document. Restricted data still needs internal documentation, quality control, and retention.

Template logic: what to adapt, not copy

Templates are useful because they show the questions a plan should answer. They are risky because they make unrelated projects sound identical. A startup data management plan should not read like a university lab template unless the project truly has the same data, storage, sharing, and preservation model.

Use a template to prompt decisions, then rewrite around the actual project. If the project creates firmware logs, microscopy images, assay results, CAD files, or field deployment records, name those outputs. If data will be shared through a repository, publication, controlled access process, or partner mechanism, say so. If data cannot be shared, explain the boundary and the alternative evidence the team can provide.

Common NSF data management plan mistakes

DMP mistakes usually come from generic language. A reviewer may not penalize a plan just because it is short, but a vague plan can weaken confidence in the team's operating discipline. The plan should feel like it belongs to the proposed work.

• Using boilerplate storage language. Secure storage matters, but the plan also needs data types, documentation, sharing, and roles.
• Ignoring proprietary constraints. If data is sensitive, explain the constraint and the responsible alternative.
• Promising to share everything. Openness that conflicts with IP, privacy, or agreements can be unrealistic.
• Forgetting metadata. Data without documentation may be impossible to interpret later.
• Separating the plan from the work plan. Data collection and quality control should match the experiments, tests, and milestones.

Pre-submission checklist

Before submission, read the data management plan next to the project description, budget, collaborators, and reporting plan. The same data should appear consistently across those sections. If the work plan says the project will run field tests, the DMP should explain field data. If the budget includes data infrastructure, the DMP should make that need understandable.

The plan should also match partner reality. If a university collaborator owns a lab instrument, the plan should explain how data moves from that lab to the company or award records. If a customer site generates field observations, the plan should explain access limits. If a subcontractor runs tests, the plan should define what files, metadata, and reports come back to the award team.

A final pass should remove vague promises. Phrases like secure system, appropriate sharing, and standard procedures are not wrong, but they are incomplete unless the reader can tell what system, what sharing decision, and what procedures apply. Replace vague nouns with project-specific choices wherever the page limit allows.

If the plan still feels thin, trace one expected dataset from creation to closeout. Who creates it, what format is it in, how is quality checked, where is it stored, who can access it, what part can be shared, and how long is it retained? That walk-through usually exposes the missing sentence.

FAQ