A data management plan (DMP) is a short, structured document that describes how you will collect, organise, store, protect, and share the data your research produces. Funders increasingly require one at the application stage, ethics committees expect it, and, more practically, it is the difference between a project whose data is analysis-ready at the end and one that spends its final weeks untangling inconsistent spreadsheets. This guide walks through what belongs in a plan, how to write each section, and the mistakes that most often send a DMP back for revision.
For years a DMP was good practice; today it is often mandatory. The United States National Institutes of Health Data Management and Sharing policy, in effect since 2023, requires a plan with almost every application. Major funders in the United Kingdom, the European Union, and Australia have parallel requirements, and most university ethics boards ask for one before approval. The reasoning is that publicly funded data should be reusable, and reuse is only possible when data is documented, standardised, and preserved. Writing the plan early also forces decisions, about formats, naming, and consent, that are painful to reverse once collection has started. A good plan is therefore not paperwork; it is the operating manual for the data side of your study.
Most funder templates ask for the same core sections, usually in one to three pages. A complete data management plan covers the data you will create, the standards and formats you will use, how you will store and secure it, how you will document and quality-check it, and how you will preserve and share it at the end. The sections below map to that structure. Treat each as a question your reviewer wants answered concretely, with specifics rather than aspirations.
Start by stating what data the project will generate. Give the data types (survey responses, clinical measurements, interview transcripts, sequencing reads, imaging), the approximate volume, and the format of each. Note whether data is collected first-hand or reused from an existing source, and flag anything sensitive such as personal or health information. This section anchors everything that follows, because the right storage, standards, and sharing choices all depend on what kind of data you are handling. Be concrete: "approximately 300 participant records with 60 variables each, captured as an eCRF export in CSV" tells a reviewer far more than "quantitative data."
Reviewers look for evidence that your data will be intelligible to someone who was not in the room when it was collected. Commit to open, non-proprietary file formats where possible (CSV over XLSX, plain text over vendor binaries) so the data outlives any single software licence. Adopt a documented file naming convention and version control. Most importantly, promise a data dictionary: a companion file that defines every variable, its units, its allowed values, and its coding. In clinical research this extends to recognised standards such as CDISC and controlled terminology, and to medical coding dictionaries like MedDRA and WHODrug. A plan that names its standards is far more convincing than one that gestures at "consistent formatting."
Step three: plan storage, security, and access
Explain where the data will live during the project and who can reach it. Cover the primary storage location, the backup strategy (the common rule is three copies, on two media, with one off-site), and the access controls that limit who can view or edit. For personal or health data, describe how you will meet the relevant regulation, such as GDPR or HIPAA, and how you will de-identify or pseudonymise records. Tie this back to your consent forms: you cannot promise to share data your participants never agreed to share. Reviewers reject plans that store sensitive data casually or that contradict the consent language, so keep the two documents aligned.
Step four: documentation, quality control, and validation
Data that is not documented is data that cannot be trusted or reused. Describe the metadata and documentation you will maintain alongside the raw data, and the quality-control steps that keep it clean: validation rules and edit checks at entry, double entry or source data verification where accuracy is critical, and a query log for resolving discrepancies. This is the operational heart of the plan and the part most applicants skimp on. Spelling out how errors are caught and corrected, rather than assuming they will not occur, is what separates a plan that survives contact with real data from one that does not.
Step five: preservation, sharing, and reuse
Finally, say what happens to the data after the project ends. Name the repository where you will deposit it (a disciplinary archive, an institutional repository, or a general one such as Zenodo or the Open Science Framework), the licence under which others may reuse it, and any embargo period. State how long you will retain the data, which funders and institutions often specify as a minimum of five to ten years. Where data genuinely cannot be shared, for ethical or legal reasons, say so explicitly and explain the restriction; a reasoned exception is accepted, silence is not.
The plans that come back for revision tend to repeat a few errors. They are vague where reviewers want specifics, promising "appropriate formats" instead of naming them. They ignore sensitive-data obligations or contradict the consent form. They treat sharing as an afterthought, with no named repository or licence. They omit a data dictionary, leaving variables undefined. And they describe an ideal that the team has no realistic capacity to deliver, which is worse than a modest plan honestly executed. A DMP is judged on being specific, feasible, and internally consistent, not on ambition.
You do not have to start from a blank page. DMPTool and DMPonline provide funder-specific templates that prompt you through each required section, and many institutions offer their own template and a research-data librarian who will review a draft. Use them: a template keeps you from omitting a section a reviewer expects. But a template only structures the plan; the substance, the actual formats, standards, and quality steps, still has to reflect what your study will really do.
A plan is only as good as its execution. The hardest part is not writing the DMP but running it: building the validated database, applying the edit checks, keeping the query log, coding the terms, and locking a clean dataset at the end. Teams that lack the in-house capacity for that work often write the plan themselves and bring in specialists to deliver it. That is exactly where our clinical data management support fits, turning a written plan into a validated database, a cleaned dataset, and a documented audit trail. If the plan is a funding-application requirement, our funder-facing methodology writing can prepare the DMP itself as part of the wider methodology.
Written well and followed consistently, a data management plan pays for itself many times over. It prevents the slow, expensive cleanup that otherwise waits at the end of a study, and it leaves you with data that a reviewer, a journal, and a future researcher can all trust.
