At a glance
- The data management plan (DMP) is the document that makes a trial’s data lifecycle traceable and auditable. Think of it as the contract for how data will be collected, cleaned, and locked.
- It is not the clinical data management discipline as a whole, and not the protocol. The DMP is the specific plan that commits your study to a defined, defensible data process.
- Each section makes a commitment and prevents a failure: undefined edit checks lead to uncontrolled queries at lock; an unmanaged change process breaks the audit trail.
- For a small team, some sections are non-negotiable (integrity, validation, lock) and others scale down. The plan should still be a living, versioned document, not a one-time deliverable.
- GCP expects the DMP to govern data collection and flow; Part 11 governs the electronic-records and signature controls the DMP must commit to.
Most pages on the DMP define it and list its activities in the abstract, but few ship a section structure you can actually lift, and many treat the DMP as a static checklist rather than the version-controlled, amendment-driven document it should be. They also conflate the DMP with the broader clinical data management discipline. This guide is the anatomy: it walks the DMP section by section, states the commitment each section must make and the failure it prevents, gives you a copy-usable outline, and flags what a small team can scale down without losing GCP defensibility. The CDM discipline itself, the TMF, and EDC selection each have their own guides; this is the DMP document.
What a Data Management Plan is (and what it is not)
The DMP is the document that defines, in advance, how a trial’s data will be handled so the result is traceable and auditable. GCP points to it directly: the sponsor should pre-specify the data to be collected and the method of its collection, and where necessary additional detail, including a data flow diagram, should be contained in a protocol-related document such as a data management plan (ICH E6(R3) §3.16.1). It is one of the execution plans GCP expects alongside the protocol, named explicitly with the statistical analysis plan and monitoring plan (ICH E6(R3) §II, principle 8).
DMP vs the broader clinical data management discipline
The DMP is not the same as clinical data management. CDM is the discipline, the people and processes that do the work. The DMP is the specific document that governs how that work is done for this trial. A second distinction worth keeping: the DMP is not the same as a standalone data validation plan or data review plan, though it may incorporate or reference them. The DMP is the parent that commits the study to a coherent data process.
When it’s authored, who owns it, and how it ties to the protocol
The DMP is authored during start-up, before data flows, and owned by data management. It derives from the protocol: the protocol says what data the trial needs, and the DMP says how those data will be collected, validated, cleaned, and locked. GCP frames the protocol and its execution plans as a set that should be clear, concise, and operationally feasible (ICH E6(R3) §II, principle 8), so the DMP must align with the protocol, not contradict it.
The DMP section by section (the anatomy)
For each section: the commitment it makes and the failure it prevents.
Scope, roles and responsibilities, and systems inventory
Commitment: who does what, on which systems. Failure prevented: orphaned tasks and unaccountable changes. GCP requires that those who use computerised systems be identified with defined roles and access, and that user access permissions be maintained and visible (ICH E6(R3) §3.16.1), which is why the DMP names roles and the systems they act in.
CRF/eCRF specification and database design
Commitment: the exact data to be collected and how the database is structured. Failure prevented: collecting the wrong data, or data you cannot analyze. This section operationalizes GCP’s requirement to pre-specify the data and method of collection (ICH E6(R3) §3.16.1).
Data collection, entry, and data flow
Commitment: how data moves from source to database, ideally with a data flow diagram. Failure prevented: untraceable data of unknown provenance. GCP explicitly contemplates a data flow diagram in the DMP (ICH E6(R3) §3.16.1), and requires the full data life cycle to be covered by procedures (ICH E6(R3) §4.2).
Validation: edit checks and the data validation plan
Commitment: the edit checks and how the system is validated. Failure prevented: uncontrolled queries at lock from undefined or unvalidated checks. GCP requires that validation be risk-based and cover both standard functionality and protocol-specific configurations, including automated data-entry checks and calculations (ICH E6(R3) §4.3.4).
Query / discrepancy management and data review
Commitment: how discrepancies are raised, tracked, and resolved. Failure prevented: a query backlog that stalls database lock. This section is where the audit-trail requirement bites: changes must document who, when, and why, without obscuring the original (ICH E6(R3) §4.2.2; 21 CFR 11.10(e)).
Medical coding and external data reconciliation
Commitment: how verbatim terms are coded (to dictionaries such as MedDRA and WHODrug, named industry standards) and how external data (labs, serious adverse events) are reconciled. Failure prevented: inconsistent coding and mismatched external data that surface only at analysis.
Data privacy, retention, and database lock
Commitment: how personal data is protected, how long records are kept, and how the database is locked. Failure prevented: privacy breaches and an undefensible lock. GCP requires integrity and confidentiality of data (ICH E6(R3) §3.16.1) and full data-life-cycle procedures through finalisation and retention (ICH E6(R3) §4.2); Part 11 requires records be protected for ready retrieval throughout retention and access limited to authorized individuals (21 CFR 11.10).
DMP vs the Data Validation Plan and data review plan
A frequent point of confusion is how the DMP relates to the Data Validation Plan (DVP) and the data review plan. They are not competitors; they are parent and children. The DMP is the umbrella that commits the study to a coherent data process end to end. The DVP is a more specific artifact that details the edit checks and validation logic, the rules that flag discrepancies as data arrives. The data review plan describes how humans review the data (medical review, listings, reconciliation) beyond the automated checks.
On a small team, these are often folded into the DMP itself rather than maintained as separate documents, which is fine. What matters is that the validation commitments are actually made somewhere and are traceable. GCP requires validation of computerised systems to be risk-based and to cover both standard functionality and protocol-specific configurations, including the automated data-entry checks and calculations (ICH E6(R3) §4.3.4), which is precisely the content a DVP captures. So whether you write one document or three, the DMP must either contain or explicitly reference the validation and review approach. The failure mode is leaving edit checks undefined and unvalidated: that is where a query backlog accumulates and surfaces, all at once, at database lock. The DMP’s job is to make sure that commitment is written down before any data is collected, not discovered to be missing afterward.
The DMP as an audit-traceable contract (GCP lens)
The reason to treat the DMP as a contract is that each section maps to a data-integrity expectation you must be able to demonstrate. Source records must be attributable, legible, contemporaneous, original, accurate, and complete, with changes traceable via an audit trail (ICH E6(R3) §2.12.2). Where the trial uses electronic signatures, those signatures must show the signer, date and time, and meaning, and be linked to their records (21 CFR 11.50, 11.70). The DMP is where you commit, in writing, that your process satisfies these, which is exactly what makes the data defensible at inspection.
Keeping the DMP alive: versioning and amendments
A DMP that goes stale at database lock has failed at its job. GCP treats the data life cycle as something governed by procedures throughout (ICH E6(R3) §4.2), and the broader principle is that plans supporting the protocol stay current as the trial evolves. Version the DMP, date each revision, and amend it when the protocol changes, the systems change, or the data process changes. An out-of-date DMP that no longer matches what the team actually does is worse than none, because it misrepresents the process to a reviewer.
A minimal DMP for small and single-site teams
A lean team does not need a fifty-page DMP, but it cannot drop the non-negotiables. Keep, at minimum: scope and roles, CRF/database specification, edit checks and validation, query management, data privacy and retention, and the database-lock process. Scale down the elaborate governance sections, but never the integrity controls (audit trail, validation, access control), because those are exactly what GCP and Part 11 require regardless of trial size (ICH E6(R3) §4.2.2, §4.3.4; 21 CFR 11.10).
DMP template / outline you can copy
1. Purpose and scope
2. Roles and responsibilities; systems inventory and access
3. CRF/eCRF specification and database design
4. Data collection, entry, and data flow (with data flow diagram)
5. Data validation: edit checks and the data validation plan
6. Query / discrepancy management and data review
7. Medical coding (MedDRA/WHODrug) and external data reconciliation
8. Data privacy, security, and retention
9. Database lock and archival
10. Version control and amendment historyA note on boundaries: TrialTrack handles clinical project management, not data management or EDC. It does not author or hold the DMP-governed data; it tracks the operational tasks around the study. The approved DMP itself is filed in the trial master file.
The bottom line
The data management plan is the auditable contract for your trial’s data: each section commits to a process and prevents a specific failure, and together they make the data lifecycle traceable. Build it from the protocol, keep CDM-the-discipline and the DMP-the-document distinct, scale the governance down for a small team but never the integrity controls, and keep it versioned and alive. Write it that way and the DMP stops being a shelf document and becomes the thing that lets your data survive an audit.
Sources
Dejan Murko
Dejan is the co-founder of Mayet, building software for biotech and pharma teams.