This is a ready-to-use master schedule of retention periods by record type, the reference every other retention decision in the organization should point back to instead of being derived fresh. Without a central schedule, retention periods drift: one decommissioning project sets eleven years for laboratory raw data, the next sets ten, and neither can point to why. Replace every <<FILL: ...>> placeholder, keep one row per record type, and maintain it under change control. A worked filled specimen follows so you can see how a completed schedule reads. Verify each cited regulation against the current source before you rely on it, and treat this as general guidance to adapt rather than legal or regulatory advice.
Document control header
| Field | Entry |
|---|---|
| Document title | Records Retention and Disposition Schedule |
| Document number | <<FILL: LOG-ID, e.g. LOG-QA-RET-001>> |
| Version | <<FILL: version, e.g. 1.0>> |
| Effective date | <<FILL: effective date>> |
| Schedule owner | <<FILL: role, e.g. Records Management Lead, Quality>> |
| Approvers | <<FILL: e.g. Head of Quality, Legal / Regulatory Affairs>> |
| Applies to | <<FILL: sites / business units in scope>> |
| Review cadence | <<FILL: e.g. annually, or on any regulatory change>> |
How to use this schedule
- Set the document number, owner, and approvers in the header.
- Enter one row per record type, not per system; a record type (for example “batch production record”) may be held across several systems and archives, and this schedule sets the single period that applies wherever it lives.
- Cite a real regulatory or contractual basis for each period. Where more than one basis applies, use the longest and note all bases considered.
- Link each row to the system or archive currently holding the record type, referencing the GxP computerized system inventory register or the applicable archive record.
- Keep the schedule under change control. A new record type, a new product with different marketing application commitments, or a regulatory change triggers a review before the next scheduled one.
- Point every decommissioning plan, migration project, and archive design at this schedule for its retention periods rather than having each project set its own.
Field definitions
| Column | What goes in it | Allowed values / format |
|---|---|---|
| Record type ID | Unique internal identifier | Short code, e.g. RT-001 |
| Record type | The category of record, described generically enough to apply across systems | Text |
| Regulatory / contractual basis | The citation or commitment driving the period | Text, cite by number and title |
| Retention period | The period to apply, stated as a duration or a triggering event plus duration | e.g. “expiry + 1 year, minimum 10 years” |
| Basis for period chosen | Note if multiple bases were considered and why this one governs | Text |
| Owner | The accountable function for records of this type | Role |
| Current medium / system(s) | Where the record type currently lives | Text, may list more than one |
| Archive plan reference | The archive or decommissioning record for this type, once archived | Document number or “active, not yet archived” |
| Disposition trigger | What starts the countdown to eligibility for destruction | e.g. “batch expiry date,” “study database lock,” “device release date” |
| Legal hold status | Whether any portion of this record type is currently under hold | None / Hold reference |
| Last reviewed | Date this row was last confirmed current | Date |
Schedule (blank)
| Record type ID | Record type | Regulatory / contractual basis | Retention period | Owner | Current medium / system(s) |
|---|---|---|---|---|---|
<<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
<<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
<<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
| Record type ID | Archive plan reference | Disposition trigger | Legal hold status | Last reviewed |
|---|---|---|---|---|
<<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
<<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
<<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
Rules for keeping the schedule current
Triggers that require an update before the change takes effect
| Trigger | Action | Owner |
|---|---|---|
| A new record type enters GxP use | Add a row with a cited basis and period before the record type is generated in production | Process owner with schedule owner |
| A product’s marketing application commitments change, or a new market extends retention | Re-evaluate the period for record types tied to that product | Regulatory Affairs with schedule owner |
| A record type’s system or archive changes (migration, decommissioning) | Update the current medium and archive plan reference | System owner |
| A legal hold is placed or lifted | Update legal hold status immediately | Legal / Regulatory Affairs |
| A regulatory change affects the cited basis | Re-evaluate the period and document the basis for any change | Schedule owner with Legal |
Periodic reconciliation
On the cadence in the header, the schedule owner reconciles this register against the GxP system inventory and any decommissioning or archival records to confirm every record type still in use has a current row, and that archived record types show a valid archive plan reference. Discrepancies are logged and corrected under change control.
Acceptance criteria
- Every GxP record type generated by the organization has a row with a cited regulatory or contractual basis and a defined retention period.
- Where multiple bases could apply, the longest is used and the reasoning is documented.
- Every row is linked to its current medium or system, and to an archive plan reference once the record type is archived.
- Legal hold status is current and checked before any disposition decision references this schedule.
- The schedule is reviewed on the stated cadence and updated against the defined triggers before changes take effect.
References
21 CFR 211.180 and 211.194 (drug product records retention and availability). 21 CFR 211.166 (stability testing, retention tied to program duration). EU GMP, EudraLex Volume 4, Chapter 4 (Documentation), retention periods. ICH E6(R3) Good Clinical Practice (Step 4, January 2025), essential record retention tied to marketing application timelines. QMSR, 21 CFR Part 820 (final rule issued February 2024, effective 2 February 2026, incorporating ISO 13485:2016 by reference), records control for combination product device constituents. MHRA GxP Data Integrity Guidance and Definitions (March 2018). PIC/S PI 041, Good Practices for Data Management and Integrity.
Cite these by number and title only and confirm the current version before you rely on any of them; product-specific and jurisdiction-specific commitments may extend these baseline periods.
Retention
Retain this schedule and its superseded versions as a controlled record for not less than <<FILL: retention period per document control policy>>.
Filled specimen
The following shows representative rows for a small drug product estate, illustrating how record types (not systems) drive the period. Company and numbers are illustrative.
Schedule (specimen, part 1)
| Record type ID | Record type | Regulatory / contractual basis | Retention period | Owner | Current medium / system(s) |
|---|---|---|---|---|---|
| RT-001 | Batch production and control records | 21 CFR 211.180(a) | Expiry + 1 year, minimum 10 years per company policy | QA Operations | Electronic batch record system (active) |
| RT-002 | Laboratory raw data (chromatography) | 21 CFR 211.194; Part 11 | Expiry + 1 year, minimum 10 years | QC Lab Systems | Legacy CDS archive (retired system, archived) |
| RT-014 | Stability data | 21 CFR 211.166 | Life of stability program + 1 year | Stability | LIMS (active) |
| RT-022 | Validation records | Company policy | System life + retention of the data the system produced | Validation | Validated EDMS (active) |
| RT-031 | Legacy user account and role records | Attribution requirement supporting RT-002 | Matches RT-002, 10 years minimum | QC Lab Systems | Archived export, read-only |
Schedule (specimen, part 2)
| Record type ID | Archive plan reference | Disposition trigger | Legal hold status | Last reviewed |
|---|---|---|---|---|
| RT-001 | Active, not yet archived | Batch expiry date | None | 03 Feb 2026 |
| RT-002 | DEC-LAB-014-RPT (decommissioning report) | Batch expiry date (matches source batch) | None | 03 Feb 2026 |
| RT-014 | Active, not yet archived | Program closure | None | 03 Feb 2026 |
| RT-022 | Active, not yet archived | System retirement date | None | 03 Feb 2026 |
| RT-031 | DEC-LAB-014-RPT (decommissioning report) | Matches RT-002 | None | 03 Feb 2026 |
Rows RT-002 and RT-031 show why record type, not system, is the right unit for this schedule: both were generated by a chromatography data system retired years ago, but the schedule still governs them by what they are (laboratory raw data, attribution records) and ties them to the decommissioning report that shows where they now live. A schedule built per system would have gone quiet on both rows the day the system was switched off.
Common inspection findings this schedule prevents
- Two different projects state two different retention periods for the same record type, with neither able to explain the basis.
- A record type’s retention period was never re-evaluated after a product gained a new market with a longer commitment.
- An archived record type has no reference back to the archive or decommissioning record that shows where it now lives.
- A destruction decision is made without checking legal hold status because no central, current source for that status exists.
- Retention periods exist only inside individual system validation packages, so nobody can answer “what is our retention policy” as a single, coherent answer.
How to adapt this register
- Set your document number, owner, and approvers; decide whether the controlled master lives in a spreadsheet or a validated tool.
- Build the schedule by record type first, pulling from your quality manual, existing SOPs, and marketing application commitments, not by copying periods out of individual system validation packages.
- Cite the real, current regulatory basis for each row and confirm it before issue.
- Wire your decommissioning, migration, and archival procedures to pull periods from this schedule rather than restating them.
- Set the review cadence and reconcile against the system inventory and archive records on that cadence.