SOP: GxP Records Retention, Archival, and Retrieval Verification

This is a ready-to-use SOP for the retention and archival side of the data lifecycle: how a retention period is set, how an archive is built and protected so records stay legible for that whole period, and how the organization proves, on a recurring schedule, that an archived record can actually be found and read rather than merely assumed to still exist. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, and route it through your normal document control, review, and approval. A worked filled specimen follows the template so you can see how a completed version reads. This SOP governs retention and archival across the estate, including systems still in active use; the one-time technical work of retiring a specific system is covered separately by a decommissioning plan, which this procedure feeds retention periods into. 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

1. Purpose

This procedure defines how <<FILL: COMPANY NAME>> sets retention periods for GxP records, builds and protects archives so records remain legible and retrievable for the full retention period, and periodically verifies that archived records can actually be located, opened, and read. The objective is to make sure a record kept is a record that can still be produced, not a record that merely still exists somewhere.

2. Scope

This procedure applies to all GxP records at the sites listed in the header, in whatever medium they exist: paper, native application data, exported files, and long-term archive storage, whether hosted on company infrastructure or by a third party. It applies to records in systems still in active use and to records already moved to an archive. It does not govern the one-time technical steps of retiring a specific computerized system, which are addressed by <<FILL: system decommissioning SOP-ID / plan template>>; this procedure supplies the retention periods and the retrieval-testing expectations that a decommissioning project draws on. It does not govern system backups taken for disaster recovery, which are addressed by <<FILL: backup and restore SOP-ID>>; a backup restores a system to a recent working state, while an archive under this procedure preserves specific records for years, independent of whether the system that created them still runs.

3. Responsibilities

4. Definitions

• Retention period: the length of time a record must be kept, set from the applicable regulation, guidance, marketing application commitment, or company policy, whichever is longest.
• Archive: a controlled, long-term store for records no longer in active day-to-day use, protected from unauthorized change, indexed so records can be located, and maintained so the records stay legible for the full retention period.
• Static archive: an archive holding records in a fixed, viewable form (for example a validated export plus the underlying raw data) where the original generating application may no longer be available.
• Dynamic record in archive: a record that still needs its original processing function to be meaningful (for example a chromatogram that may need reprocessing), which must retain that function in the archive or be paired with a system that provides it.
• Retrieval test: a scheduled, timed exercise that locates a real archived record, opens it, and confirms it is complete, legible, and carries its metadata and audit trail.
• Legal hold: a directive that suspends the routine retention schedule for specific records because of an open inspection, investigation, litigation, or recall, until the hold is lifted.

5. Procedure

5.1 Set the retention period

1. For each record type, identify the applicable regulatory basis (for example batch production records, laboratory raw data, stability data, complaint records, or clinical essential documents each carry their own basis).
2. Where more than one regulation, guidance, or marketing application commitment applies, adopt the longest period.
3. Record the retention period, its basis, the accountable owner, and the record’s medium in the records retention and disposition schedule; see the companion records retention and disposition schedule.
4. Approve new or changed retention periods through Quality Assurance before they take effect.

5.2 Design the archive

1. For each record type reaching the archive, determine whether it is static or dynamic per the definitions above.
2. For dynamic records, confirm the archive preserves the processing function, either by retaining a working copy of the generating application in a controlled environment or by migrating to a system that provides equivalent function. A flat export of a dynamic record is not an adequate archive on its own.
3. Select the archive location and medium (on-premises, cloud or hosted, or a mix), and document the protection applied: read-only status, access control, backup, and integrity checking.
4. Build or confirm an index that lets the archivist locate a record by the identifiers a requester would realistically have (batch or lot number, subject or sample ID, date range, system of origin), not only by an internal file path.
5. Confirm the archive preserves metadata and the audit trail alongside the record content; an archived result without its audit trail is an incomplete record.
6. Set a media and format review interval appropriate to the technology in use, so obsolescence is caught by a scheduled check rather than discovered at the moment a record is needed.

5.3 Protect the archive

1. Restrict write and delete access to the archive to the named archivist role; ordinary users have read access only, and only to the records their access rights cover.
2. Back up the archive per <<FILL: backup SOP-ID>> and confirm the backup itself has been restore-tested.
3. Where the archive is hosted by a third party, confirm in the contract the provider’s obligations for availability, backup, data residency, and legal hold, and confirm an export path exists that would let the company retrieve the full archive, records, metadata, and audit trail, independent of the provider.
4. Log every access to the archive that results in a change to its content or protection settings; the archive itself should carry an audit trail of administrative actions.

5.4 Run a retrieval test

1. On the frequency set in section 6, select a real record or small set of records from the archive under test. Favor records from a retired system or an older portion of the retention period, since these are the most likely to reveal a gap.
2. Record the request time and the identifiers used to locate the record, as a realistic requester would supply them.
3. Locate, open, and review the record. Confirm it is complete, legible, and carries its metadata and audit trail, and that it matches the raw data definition for its record type.
4. Record the elapsed time from request to a usable, readable record.
5. Log the result on the retrieval test log (section 8). Any gap, an unreadable record, a missing metadata element, an index that failed to locate the record, or an elapsed time that would not meet the timeframe expected during an inspection, is raised as a finding under section 5.5.

5.5 Handle a retrieval test finding

1. Record the finding with enough detail to reproduce it: the record requested, what was expected, and what was found.
2. Notify the archive owner and Quality Assurance the same working day for any finding involving an unreadable or incomplete record.
3. Open a deviation or CAPA per <<FILL: SOP-ID for deviations / CAPA>> when the finding indicates a systemic gap (a format about to become unreadable, an index gap affecting more than the sampled record, a media failure).
4. Remediate before the next scheduled test, and confirm the remediation with a repeat retrieval of the same or an equivalent record.

5.6 Disposition at end of retention

1. When a record set reaches the end of its retention period per the schedule, the records owner confirms the period has genuinely expired.
2. Legal confirms no open legal hold, inspection, investigation, litigation, or recall touches the record set.
3. Quality Assurance authorizes destruction in writing.
4. Destruction is executed and a destruction record is created (record type, quantity, date, method, executor, authorizer) and itself retained.

6. Retrieval test frequency

Set frequency from criticality and use the table below as the default, documenting the basis for each archive in the archive’s own record.

7. Acceptance criteria

• Every GxP record type has a documented retention period, basis, and owner in the retention and disposition schedule.
• Every archive holding those records has a documented format, location, protection, and index.
• Dynamic records retain their processing function in the archive or are paired with a system that provides it.
• A retrieval test has been run within the frequency set for each archive, and it confirms the record is complete, legible, and carries its metadata and audit trail.
• Every retrieval test finding is logged, and systemic findings are resolved through deviation or CAPA before the next test.
• No record is destroyed without an authorized destruction record, and no record under legal hold is destroyed.

8. Records generated

Retrieval test log entry

9. References

21 CFR 211.180 (general records requirements, including that records be readily available for inspection) and 211.194 (laboratory records). 21 CFR Part 11 (electronic records and signatures), including retrievability and readability throughout the retention period. EU GMP Annex 11 (Computerised Systems) and EU GMP Chapter 4 (Documentation). MHRA GxP Data Integrity Guidance and Definitions (March 2018). PIC/S PI 041, Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments. FDA guidance, Data Integrity and Compliance With Drug CGMP, Questions and Answers (December 2018). ICH Q9(R1) (2022), Quality Risk Management, for the risk-based retrieval test frequency.

Confirm the current version and clause numbers of each reference before issue.

10. Revision history

11. Approvals

Filled specimen

The following shows a retrieval test completed for an example laboratory raw data archive built when a legacy chromatography data system was retired, so you can see the level of detail an inspector expects. The company, system, and numbers are illustrative; replace them with your own.

A second test from the same cycle did surface a finding, shown here because a clean specimen alone does not demonstrate what the control is for: a request for stability batch S-0442 raw data from the same archive took 55 minutes because the index did not include stability batch numbers, only sample IDs, so the archivist had to search by date range. Finding logged, deviation DEV-2026-0201 opened, and the index was corrected to include batch number as a search key; the repeat test located the record in under 5 minutes and the remediation was confirmed closed.

Common inspection findings this SOP prevents

• Records are retained past their retention period, but nobody has ever confirmed they can still be opened.
• A retention period is applied inconsistently across record types with no documented basis for the period chosen.
• An archive exists, but there is no evidence any retrieval was ever tested before an inspector’s request became the first real test.
• A dynamic record was archived as a flat export and can no longer be reprocessed when a result is challenged.
• A cloud-hosted archive’s contract lapses or the vendor changes platforms, and no tested export path exists to recover the data.
• Records are destroyed while a related inspection, investigation, or litigation is open.

How to adapt this SOP

1. Set your document number, owner, and effective date in the header.
2. Point sections 2 and 5.1 at your actual decommissioning and backup procedures so the boundaries between this SOP and those procedures are clear.
3. Replace the generic archive criticality categories in section 6 with your actual archive inventory and the criticality you assigned each one.
4. Confirm your cloud or hosted archive contracts include a workable export path, and test that path at least once as part of your first retrieval test cycle.
5. Confirm every regulation in section 9 against the current published version before issue.