Data Management Plan (DMP) — practical template

Purpose (short)

Describe why the data will be created and how it supports the project goals. Link to the project summary or grant reference.

Prompt: What questions will the data help answer? Who are the intended users (internal researchers, collaborators, public, regulators)?

Example: "Sensor time-series and sample metadata collected to evaluate material corrosion under controlled humidity. Intended users: project team, corrosion modeling group, and future meta-analyses."

1. Project summary & data types

List each dataset or data product you will produce. For each, include brief descriptions of format, volume, expected file types, and generation method.

1. Dataset name / ID:

   Type (e.g., raw instrument output, processed tables, images, models):

   Formats (e.g., CSV, NetCDF, TIFF, HDF5, JSON, SQL dump):

   Estimated size and growth rate:

   Generation frequency (continuous, per-experiment, batch):

2. Derived data / code:

   Describe processing scripts, software, and expected derived outputs (include languages, major dependencies, versions).

2. Storage & backup plan

Describe where data will be stored during active work, how it will be backed up, and where long-term copies will be kept.

• Active storage: (local lab server, cloud project bucket, institutional NAS). Include capacity, access method, and encryption if required.
• Backups: (backup cadence, retention, off-site/cloud copy). Example: daily incremental + weekly full backup retained 90 days; monthly archival snapshot retained 7 years.)
• Version control: (use git/LFS for code, data-versioning tools or dated snapshots for large files.)
• Disaster recovery & checks: (periodic restore tests, checksum verification, use of checksums like SHA256.)

3. Metadata schema & identifiers

Specify metadata standards and persistent identifiers to make data findable and interoperable.

• Metadata standard: (choose one or more — DDI, Dublin Core, DataCite Metadata Schema, MIAME, MIxS, domain-specific ontologies).
• Core metadata fields to capture: title, creator(s), organisation, contact, date(s) collected, geographic or experimental context, methods summary, variable list, units, provenance, licensing, access rights.
• Identifiers: plan to mint DOIs (DataCite) for published datasets; use persistent internal IDs for records; consider ORCID for authors.
• File-level metadata: include README files, machine-readable sidecars (JSON-LD, schema.org), and checksums for each file.

4. Access controls & sharing arrangements

Define who can access data at each phase and how you will share or publish data.

• Access levels: (private to team, consortium access, embargoed public release, open public). Specify justification for restricted access (privacy, IP, security).
• Sharing workflow: (internal review -> embargo -> repository publication). Note any legal, ethical, or contractual restrictions.
• Licensing: choose a license for reuse (e.g., CC BY 4.0, CC0, or an appropriate data-use agreement). Document license decision here.
• Data request process: if data cannot be fully public, describe request and approval steps, contact point, and expected response timeframe.

5. Retention & archival plan

State how long datasets, code, and metadata will be preserved, where archival copies will live, and criteria for deletion.

• Retention periods: (example: raw data retained 10 years; processed data and code retained indefinitely in institutional repository.)
• Archival target: (institutional repository, domain repository, generalist repository such as Zenodo or Figshare)
• Format migration: plan for future-proofing (store in open, well-documented formats; schedule audits for format obsolescence.)

6. Roles & responsibilities

List team members responsible for data creation, curation, storage, metadata, access requests, and preservation.

• Data steward / manager: name, contact, responsibilities (metadata oversight, repository submissions).
• PI / project lead: policy decisions, budget sign-off.
• Technical support: IT or repository contacts for backups, access provisioning, and system configuration.
• Compliance officer: if applicable (human subjects, biosafety, export controls).

7. Cost estimates and compliance notes

Estimate storage, backup, repository fees, personnel time for curation, and any other costs. Note regulatory and funder compliance requirements.

• Estimated storage & backup costs: $ / GB / year and total for duration of project.
• Repository fees: (DOI minting, submission charges, embargo fees.)
• Curation time: hours per dataset for metadata, cleaning, and submission.
• Compliance: list applicable policies (funder DMP requirements, GDPR, HIPAA, institutional policies) and how they will be satisfied.

FAIR checklist (quick)

• Findable: metadata recorded and persistent identifiers planned.
• Accessible: clear access path and license or request process documented.
• Interoperable: use standard vocabularies and common formats where possible.
• Reusable: provenance and license are specified; sufficient metadata and README provided.

Practical appendices (attach when possible)

1. README template for dataset (include sample fields to populate)
2. Metadata template (machine-readable example, e.g., JSON-LD or DataCite XML)
3. Retention schedule table (dates, location, responsible person)
4. Storage architecture diagram or short description (buckets, folders, permissions)
5. Sample data license text and data-use agreement

Next steps & useful resources

Fill this template early (before data collection begins). Review with IT, legal/compliance, and your institutional data steward. Consider publishing the dataset's metadata record before final analysis to increase discoverability.

Suggested resources: DataCite metadata schema, FAIRsharing.org, re3data.org (repositories), ORCID, institutional library data services, domain-specific standards (MIAME, MIxS, etc.).

How this template helps your hunger

This template turns a short checklist into an actionable plan with concrete prompts, examples, and attachments you can reuse and adapt. It focuses on reproducibility, discoverability, and the practical steps needed to keep data usable over time.