How to Write a Research Data Management Plan That Funders Actually Approve

If you've ever written a grant proposal, you know the feeling: you've spent weeks crafting your research plan, refining your budget, and polishing your specific aims. Then, the night before submission, you remember the data management plan. You throw together two pages of vague promises about "secure storage" and "timely sharing," and hope the reviewers don't look too closely.

You're not alone. Data management plans (DMPs) are one of the most consistently underdeveloped sections of grant proposals. But that's changing — and fast. Funders are reading DMPs more carefully than ever, and a weak plan can undermine an otherwise strong proposal. The good news: a well-written DMP isn't just a checkbox. It demonstrates methodological rigor and can actually strengthen your case for funding.

Why Funders Require Data Management Plans

The push for DMPs comes from a convergence of forces in modern science. The reproducibility crisis has made funders acutely aware that research data needs to be findable, accessible, and reusable long after a project ends. Taxpayers fund most academic research, and there's a growing expectation that the resulting data should be a public good — not locked away on a single researcher's hard drive.

The National Science Foundation (NSF) has required DMPs since 2011. The National Institutes of Health (NIH) strengthened its requirements significantly in 2023 with the new Data Management and Sharing Policy. The European Commission's Horizon Europe program mandates open access to research data by default. These aren't suggestions — they're requirements, and a weak or missing DMP can hurt an otherwise competitive proposal.

Beyond compliance, a strong DMP signals to reviewers that you've thought carefully about the full lifecycle of your data. It shows you understand that data collection is just the beginning — that storage, quality control, documentation, sharing, and preservation all require deliberate planning.

The Six Core Components of a Strong DMP

While every funder has slightly different requirements, most DMPs need to address six fundamental areas. Covering each one with specifics — not generalities — is what separates an approved plan from one that raises reviewer concerns.

1. Data Types and Formats

Describe what data you'll collect, generate, or reuse. Be specific about file formats, estimated data volumes, and how data types relate to your research objectives. Reviewers want to see that you understand your own data landscape.

Weak example: "We will collect field data and store it digitally."

Strong example: "Field surveys will generate approximately 5,000 observation records per season, capturing 12 variables per record (species ID, GPS coordinates, water temperature, depth, substrate type, etc.). Data will be entered into structured forms with defined field types and validation rules, ensuring consistency across all field teams. Exported datasets will use CSV format with UTF-8 encoding for maximum interoperability."

2. Metadata and Documentation Standards

Explain how you'll document your data so that others can understand and reuse it. Reference established metadata standards in your discipline (e.g., Dublin Core, EML for ecology, DDI for social science). Describe how field definitions, units, and collection protocols will be recorded.

This is where many DMPs fall short. Saying "metadata will be provided" tells reviewers nothing. Instead, specify that each data model will include field-level descriptions, units of measurement, acceptable value ranges, and collection methodology notes — and that this documentation will be maintained alongside the data throughout the project lifecycle.

3. Storage, Backup, and Security

Detail where data will be stored during the active research phase, how it will be backed up, and what security measures will protect it. Funders want to know your data won't be lost to a hard drive failure or a stolen laptop.

Address three layers: primary storage (the platform where data is actively managed), backup frequency and location (automated daily backups to geographically separate servers), and access security (encrypted connections, role-based access control, authentication requirements). If your data includes sensitive information (human subjects, endangered species locations), describe the additional protections in place.

4. Access Policies and Sharing

Describe who will have access to the data during the project and how you'll share data after publication. Be explicit about any restrictions and justify them. Funders understand that some data can't be fully open (patient records, endangered species locations, indigenous community data), but they expect you to share as much as possible, as early as possible.

Specify the repository where you'll deposit data (e.g., Dryad, Zenodo, GenBank, or a discipline-specific archive), the timeline for sharing (upon publication, or within a defined embargo period), and the license you'll apply (Creative Commons CC-BY is preferred by most funders).

5. Data Sharing Timeline

Provide a concrete timeline, not vague promises. "Data will be shared in a timely manner" is insufficient. Instead: "Processed datasets will be deposited in [repository] within 60 days of publication of associated manuscripts. Raw datasets will be made available within 12 months of collection, or upon project completion, whichever comes first."

NIH specifically requires that data be shared "no later than the time of an associated publication, or the end of the award period, whichever comes first." Make sure your timeline meets your funder's specific requirements.

6. Long-Term Preservation

Research data has value beyond the life of a single grant. Describe how your data will be preserved after the project ends. This means identifying a long-term repository, specifying how long data will be maintained (many funders expect a minimum of 10 years), and ensuring that file formats are suitable for long-term access (open, non-proprietary formats).

If you're using a structured data platform during the project, describe how data will be exported and migrated to an archival repository. The ability to export clean, well-documented datasets in standard formats is essential for long-term preservation.

Common Mistakes That Get DMPs Rejected

Certain patterns consistently weaken DMP sections of grant proposals. Avoiding these common mistakes puts you ahead of most applicants.

Vague language without specifics. "Data will be stored securely" tells reviewers nothing. How? Where? With what encryption? What access controls? Specificity demonstrates competence.

Ignoring metadata entirely. Many DMPs describe data collection and storage but say nothing about documentation. Without metadata, your data is useless to anyone who wasn't involved in collecting it — including your future self.

No plan for the post-grant period. Your DMP can't end when the funding ends. Reviewers want to see that you've thought about what happens to the data in year 10, not just year 3.

Copy-pasting a generic template. Funders can tell when a DMP has been recycled from another proposal without adaptation. Your DMP should reference specific data types, volumes, and workflows from your proposed research.

Listing tools without explaining workflows. Naming a tool (e.g., "we will use Platform X") isn't enough. Explain how the tool fits into your data workflow: how data enters the system, how quality is maintained, how access is controlled, and how data is exported for sharing and archival.

Underestimating data volumes. If you're collecting data across multiple sites, seasons, and years, do the math. A project that generates 50,000 records needs a different storage and management strategy than one generating 500. Show reviewers you've thought this through.

A Practical DMP Template

Use this section-by-section framework as a starting point, then customize it for your specific funder's requirements and your research context.

Section 1: Data Description — "This project will generate [type] data through [method]. We anticipate approximately [volume] records across [timeframe]. Each record will capture [number] variables including [list key fields]. Data will be collected using structured digital forms with defined field types, validation rules, and controlled vocabularies to ensure consistency across [number] collection sites/teams."

Section 2: Documentation and Metadata — "All data models will include field-level documentation specifying variable names, definitions, units of measurement, acceptable value ranges, and collection protocols. We will follow [metadata standard] conventions. Documentation will be maintained alongside the data and updated whenever collection protocols change."

Section 3: Storage and Security — "During the active research phase, data will be managed in [platform/system] with [encryption standard] encryption, role-based access control, and automated [frequency] backups to [backup location]. Access requires [authentication method]. Sensitive data elements ([specify]) will be [additional protections]."

Section 4: Access and Sharing — "Data will be shared via [repository] under a [license] license. Processed datasets will be deposited within [timeframe] of associated publications. [If restrictions apply]: Access to [specify restricted elements] will require [approval process] due to [justification]."

Section 5: Preservation — "Upon project completion, all datasets will be exported in [format] and deposited in [long-term repository] for a minimum of [years] years. File formats have been selected for long-term accessibility and interoperability."

DMP Requirements by Funder

While the core components overlap, each major funder has specific expectations worth noting.

NSF requires a supplementary document of no more than two pages. The DMP is reviewed as part of the broader impacts and intellectual merit criteria. NSF expects data to be shared "promptly" after collection, with "reasonable" timelines. Different NSF directorates may have additional requirements specific to their disciplines.

NIH updated its policy in January 2023, replacing the old Data Sharing Plan with a more comprehensive Data Management and Sharing Plan. NIH recommends plans be concise (typically around two pages). The policy applies to all NIH-funded research generating scientific data, and plans must address data preservation for a minimum of the grant period plus any required post-award retention. NIH also requires researchers to account for costs of data management in the budget.

EU Horizon Europe mandates open access to research data by default, with opt-outs requiring justification ("as open as possible, as closed as necessary"). Horizon Europe uses a DMP template that evolves throughout the project — an initial version is due within six months of the grant start, with updates at defined milestones. The FAIR principles (Findable, Accessible, Interoperable, Reusable) are explicitly referenced as guiding criteria.

Making Your DMP a Living Document

The best DMPs aren't written once and forgotten. They're living documents that evolve with your project. As you refine your data collection protocols, add new variables, or onboard new team members, your DMP should reflect those changes.

This is where the gap between planning and implementation matters most. A DMP that promises structured data collection, validation rules, and role-based access control only works if you actually have a system that delivers those capabilities. Too often, researchers write aspirational DMPs and then fall back to spreadsheets and shared drives because they don't have the infrastructure to follow through.

The key is choosing a data management platform that aligns with what you've promised in your DMP. This is exactly why we built Cnidarity — to give research teams the infrastructure to actually follow through on their data management plans, not just write them.

With Cnidarity, the core promises you make in a DMP become features you use every day:

• Structured data models — Define custom models that match the data types and formats described in your DMP. Each model enforces the fields, relationships, and structure your methodology requires.
• Built-in validation — Set validation rules at the field level so data quality is enforced at the point of entry, exactly as your DMP promises reviewers.
• Role-based access control — Assign collaborators specific roles with appropriate permissions, implementing the access policies you outlined in your plan.
• Field-level documentation — Attach descriptions, units, hints, and acceptable ranges directly to each field. Your metadata lives alongside your data, not in a separate document that gets out of date.
• Clean data export — Export your datasets to CSV at any time for analysis in R, Python, or Excel, and for deposit into long-term repositories when it's time to share and archive.

When your tooling matches your plan, the DMP stops being a bureaucratic exercise and becomes a genuine asset — a roadmap that guides your data management from the first day of collection through long-term preservation.

Getting Started

If you have a grant deadline approaching, start with the template above and customize it for your funder's specific requirements. Download the latest DMP guidelines from your funder's website — they update more frequently than most researchers realize.

If you're between proposals, use this time to audit your current data management practices. How close are they to what you'd promise in a DMP? The gaps you find are opportunities to strengthen both your practice and your next proposal. Setting up proper data infrastructure now means your next DMP writes itself — because you'll simply be describing what you're already doing.

If you're ready to put your data management plan into practice, try Cnidarity for free. Explore our sample project to see how custom data models, validation rules, and team collaboration work together — so the next time you write a DMP, you can describe a system you're already using.

A strong data management plan isn't just about satisfying a funder requirement. It's about building the foundation for research that's reproducible, collaborative, and impactful long after the grant period ends.