DMP Worked Examples: Two Filled-In Plans

A DMP template tells you which questions to answer. It does not show you what a strong answer looks like — most templates are a list of section headers and prompting sentences, not filled-in text. This guide fills that gap directly: two complete, fully-written example Data Management Plans, one built around NSF’s Data Management and Sharing Plan (DMSP) elements and one built around NIH’s Data Management and Sharing (DMS) Plan elements, so you can see what specific, funder-ready language actually reads like in each section.

If you need to understand how NIH’s and NSF’s requirements differ structurally — page limits, submission mechanics, which elements each funder requires — see NIH vs. NSF Data Management Plans: What Actually Differs. This guide assumes you already know which funder’s structure applies to you and skips straight to what a completed answer looks like inside it.

These are illustrative examples, not real studies. The two plans below describe fictional, composite research projects invented specifically for this guide. No institution, investigator, grant number, dataset, or IRB protocol referenced is real, and neither plan should be copied into an actual application — a program officer can generally tell when a DMP has been adapted word-for-word from a public example rather than written for the specific project. Their purpose is narrower and more useful than a copy-paste source: to show the level of specificity a real answer needs, in contrast to the placeholder language a blank template invites. For real plans shared by real funded projects, see the note on DMPTool’s public plan library near the end of this guide.

Why a worked example beats another template

CASRAI’s DMP template entry defines a template as “a structured set of questions and guidance used to elicit the content of a Data Management Plan” — it organizes what to cover, not what to say. Reviewers and program officers reject DMPs for the same handful of reasons, and nearly all of them come down to vagueness: “data will be shared upon reasonable request,” “appropriate metadata standards will be used,” “the PI will ensure compliance.” Each of those phrases answers the letter of a template prompt while giving a reviewer nothing to actually evaluate.

The two examples below are written the way a completed plan should read: naming an actual repository instead of “an appropriate repository,” stating an exact retention period instead of “as long as required,” and naming a responsible role instead of “the PI will ensure compliance.” Read them section by section against whatever template or draft you’re currently working from, not as something to copy wholesale.

Example 1: A social-science survey study (NSF DMSP format)

Illustrative study snapshot (fictional): A two-wave online and telephone survey of approximately 1,200 adult respondents examining household financial decision-making after a regional economic shock, with a nested sub-study of roughly 60 semi-structured follow-up interviews with a purposive subsample. Proposed to an NSF SBE-directorate program. Under NSF’s current Data Management and Sharing Plan requirements, the plan is a two-page supplementary document covering five elements: data types; standards for data and metadata; policies for access and sharing; policies for reuse and redistribution; and plans for archiving and preservation.

Types of data

Filled-in version: “This project will produce three data types: (1) closed- and open-ended survey response data from ~1,200 respondents across two waves, collected via Qualtrics and exported as CSV and SPSS (.sav) files; (2) derived demographic and financial-behavior index variables computed from the raw responses, documented in an accompanying codebook; and (3) de-identified audio recordings and verbatim transcripts from ~60 semi-structured interviews. Raw audio files will not be shared publicly; transcripts will be shared after de-identification per the access policy below.”

What a template prompt alone invites: “Survey and interview data will be collected and managed appropriately.” (Says nothing about volume, format, or which parts are shareable — the difference the example above demonstrates.)

Standards for data and metadata format and content

Filled-in version: “Survey data will be documented using the Data Documentation Initiative (DDI) codebook standard, generated directly from the Qualtrics survey instrument and variable labels. Derived variables will carry the same DDI-conformant metadata plus a construction note describing the source items and any recoding logic. Interview transcripts will follow a plain-text format with structured header metadata (participant ID, wave, interview date, interviewer ID) compliant with the deposit requirements of the target repository (below).”

Policies for access and sharing, including privacy and confidentiality protections

Filled-in version: “Survey and interview data include indirect identifiers (ZIP code, employer sector, household composition) collected under an IRB-approved protocol with a written informed consent process describing planned de-identified secondary use. Prior to deposit, the project data steward (the project coordinator role, not the PI) will remove direct identifiers and generalize indirect identifiers with re-identification risk above the project’s documented threshold, following the disclosure-review process the target repository requires for deposit. De-identified survey data will be deposited within 6 months of each wave’s data-collection close; de-identified interview transcripts will be deposited within 12 months of the interview sub-study’s completion, reflecting the additional time required for transcription and disclosure review. Data will be shared at the embargo end date via the repository’s standard access-request workflow, not held under indefinite ‘available upon request’ terms.”

Policies and provisions for re-use, redistribution, and production of derivatives

Filled-in version: “De-identified survey data will be deposited to openICPSR under a data use agreement restricting re-identification attempts and requiring citation of the original dataset DOI in any derivative publication, consistent with ICPSR’s standard terms for restricted-use social science data. No commercial redistribution restrictions apply beyond the re-identification prohibition. Derived index variables and the codebook will be released under the same terms as the underlying survey data so secondary users can reproduce the derivation.”

Plans for archiving data and preserving access

Filled-in version: “Final de-identified survey and interview datasets will be archived at ICPSR (the Inter-university Consortium for Political and Social Research, University of Michigan) via its openICPSR self-deposit service, selected because it is the domain-standard repository for social-science survey data and provides DOI assignment, DDI-conformant metadata hosting, and a minimum 10-year preservation commitment under its standard deposit terms. Raw (non-de-identified) data and consent records will be retained on institutionally-managed encrypted storage for 5 years post-award closeout per the institution’s research-data retention policy, then destroyed.”

Example 2: A genomics study (NIH DMS Plan format)

Illustrative study snapshot (fictional): A whole-exome sequencing study of approximately 400 participants and family members investigating the genetic basis of a hypothetical rare pediatric condition, proposed to an NIH institute. Because this project generates large-scale human genomic data, it falls under both the general NIH Data Management and Sharing Policy (effective 25 January 2023, covering essentially all NIH-funded research that generates scientific data) and the NIH Genomic Data Sharing (GDS) Policy (effective 25 January 2015, covering large-scale human and non-human genomic data specifically). The DMS Plan below is written to NIH’s six required elements and explicitly addresses the GDS Policy’s overlay requirements — a step a generic DMS template prompt does not force a genomics applicant to notice.

Data type

Filled-in version: “This project will generate whole-exome sequencing (WES) FASTQ and aligned BAM files from ~400 participants and available family members, plus derived VCF variant-call files and de-identified clinical phenotype data (age of onset, symptom severity scores, family pedigree structure) linked to each genomic sample via a study-assigned coded ID. Because participants and families are potentially re-identifiable from genomic data even after removal of direct identifiers, all sequence-level data will be treated as controlled-access under the NIH GDS Policy, not shared as open/unrestricted data.”

Related tools, software, and/or code

Filled-in version: “Sequencing reads will be aligned using BWA-MEM (GRCh38 reference) and variant calls generated with GATK’s germline short-variant pipeline, both open-source and freely available; specific pipeline version numbers and configuration files will be deposited alongside the sequence data so re-analysis is reproducible without contacting the study team. No custom or proprietary analysis software is required to use the deposited data.”

Standards to be used for data and metadata

Filled-in version: “Sequence data will be deposited in standard FASTQ/BAM/VCF formats. Phenotype metadata will be structured using the Human Phenotype Ontology (HPO) for symptom coding, and sample/subject metadata will follow the data dictionary structure required for dbGaP submission, including pedigree relationships encoded per standard PED file format.”

Data preservation, access, and associated timelines

Filled-in version: “Consistent with the GDS Policy, this study will register with and submit controlled-access genomic and phenotype data to dbGaP (the database of Genotypes and Phenotypes), NIH’s designated repository for human genomic data, no later than the earlier of first publication or the end of the award period. Data will remain available in dbGaP indefinitely, subject to NIH’s ongoing repository-maintenance commitments. No embargo beyond the standard pre-publication period is requested.”

Access, distribution, or reuse considerations

Filled-in version: “Because participants were consented under a protocol permitting only research-use secondary access (not unrestricted public release), sequence and linked phenotype data will be deposited as controlled-access. Secondary users must submit a Data Access Request to the relevant NIH Data Access Committee (DAC), which reviews requests against the consent terms on file, and must execute a data use agreement before receiving access. This two-tiered structure — open access to de-identified summary statistics, controlled access to individual-level genomic data — follows the GDS Policy’s standard access model rather than a study-specific arrangement.”

Oversight of data management and sharing

Filled-in version: “The PI is responsible for overall DMS Plan compliance; a designated study coordinator manages day-to-day data collection, de-identification, and dbGaP submission logistics. Compliance will be reviewed at each annual progress report, and the IRB-approved protocol (renewed annually) will be checked against the DMS Plan’s access terms at each renewal to confirm no drift between what participants consented to and what the plan describes.”

What separates a real answer from a placeholder

Both examples above follow the same underlying discipline, regardless of funder:

Name the actual repository — “openICPSR” or “dbGaP,” not “an appropriate repository.”
State an exact retention period — “5 years post-award closeout,” not “as long as required.”
Name the responsible role — “the project data steward” or “the study coordinator,” not “the PI will ensure compliance” with no mechanism attached.
Cite the specific metadata standard — “DDI codebook” or “Human Phenotype Ontology,” not “appropriate standards will be applied.”
Anchor every timeline to a real milestone — award closeout, embargo end date, IRB renewal date, first publication — not an unanchored phrase like “in a timely manner.”
Say what does not apply, explicitly — the survey example states there are no commercial-redistribution restrictions beyond re-identification; the genomics example states no embargo beyond the standard pre-publication period is requested. A reviewer reads an explicit “none” as more complete than a section that simply omits the question.

What still needs funder- and program-specific verification

Neither example above is a complete substitute for reading your actual funding opportunity announcement. Both NIH and NSF have changed DMP mechanics recently, and program- or directorate-level guidance can add requirements beyond the funder-wide baseline:

NIH introduced a newer, abbreviated Q&A-style DMS Plan format for applications with due dates on or after 25 May 2026 (NOT-OD-26-046); the narrative structure shown in the genomics example above reflects the traditional format and may need reshaping for that newer format depending on your due date.
NSF directorates (Engineering, Mathematical and Physical Sciences, Social, Behavioral and Economic Sciences among them) layer their own supplemental DMSP guidance on top of the funder-wide five elements shown in the survey example above — always check your specific directorate’s page.
If your study involves genomic data but doesn’t meet the GDS Policy’s “large-scale” threshold, or involves non-human genomic data, the controlled-access mechanics in the genomics example may not apply in the same way — confirm applicability with your program officer.

For the structural comparison — page limits, submission locations, and the full six-vs-five element breakdown — see NIH vs. NSF Data Management Plans.

Where to find real, publicly shared DMPs

If you want to see plans from actual funded projects rather than illustrative composites, DMPTool maintains a public plan library of DMPs that researchers have chosen to share openly, searchable by funder, institution, and subject area. DMPTool is explicit that these plans are not vetted for quality or funder-compliance — use them the same way you should use the two examples on this page: as a reference for register and specificity, not as a template to copy.

Frequently asked questions

Are these real DMPs from funded studies?

No. Both example plans above describe fictional, composite research projects invented for this guide, as stated in the disclosure near the top of the page. No institution, investigator, or grant is real.

Can I copy one of these plans into my own application?

No — and reviewers can usually tell when a plan has been lifted from a public example rather than written for the specific project. Use these examples to see what a specific, complete answer looks like in each section, then write your own answers to match that level of specificity for your actual data, repository choice, and institutional policies.

Do NIH and NSF expect the same DMP sections?

No. NIH’s DMS Plan has six required elements (data type; related tools, software, and/or code; standards; data preservation, access, and timelines; access, distribution, or reuse considerations; oversight); NSF’s DMSP has five (types of data; standards; access and sharing policies; reuse and redistribution provisions; archiving and preservation plans). See NIH vs. NSF Data Management Plans for the full structural comparison.

What if my study doesn’t look like either example?

Adapt the structure, not the content. The underlying discipline — name the actual repository, state an exact retention period, name a responsible role, cite a specific metadata standard, anchor every timeline to a real milestone — applies regardless of discipline. DMPTool’s own funder-specific templates (built on the DMP template pattern) are a reasonable starting structure if neither worked example matches your project type.

Does a machine-actionable DMP replace this kind of narrative plan?

Not currently, for most funders — NIH and NSF both still require the narrative document shown above. A machine-actionable DMP (maDMP), built to the RDA DMP Common Standard, is a structured, queryable representation of the same commitments — useful for CRIS/RIM interoperability and progress tracking — but it supplements rather than replaces the funder-required narrative plan in current practice.

Where do the specific repository and retention choices in these examples come from?

They reflect real domain conventions — ICPSR/openICPSR as the standard social-science survey data repository, dbGaP as NIH’s designated repository for controlled-access human genomic data under the GDS Policy — chosen to make the examples realistic, even though the underlying studies are fictional. Your actual repository choice should match your data type and any funder or program requirements; see How to Choose an Open Data Repository.

Data Management Plan Worked Examples: Two Full, Filled-In Plans