Independent and not affiliated with the FDA, MHRA, ISPE, PDA, or any agency. Get the appgoutham@madhadi.com
madhadi.comData Integrity & GxP Quality
Browse all topics -> Articles Templates & Procedures Learning paths GlossaryScenariosToolsRegulatory ReferencesLearning PathsTopics About Start here
Checklist Plug-and-play starting point Clinical & GCP

Checklist: Clinical System Decommissioning After Database Lock

A runnable checklist for retiring EDC, IRT/RTSM, and safety database systems after database lock: defining the final state, extracting a validated archive, a subject-level retrieval test, locking against modification, and documenting the applicable retention floor, with pass/fail/NA columns and a filled specimen.

Document type: Checklist

Read and copy the template below into your own quality system. It is a generic starting point for your own internal use, provided as is, with no warranty; see the Terms and License. Adopting it does not by itself create compliance.

This is a ready-to-use checklist for retiring a clinical computerized system, EDC, IRT/RTSM, or a study-specific safety database instance, after database lock. It walks the decommissioning sequence at the system level: what has to survive the transition, a subject-level retrieval test, and the retention floor that applies. For the mechanics of a single retrieval test, run it alongside the Archive Retrieval and Readability Test checklist. Replace every <<FILL: ...>> placeholder and route it through your normal document control. This is general guidance to adapt and verify, not legal or regulatory advice; confirm each cited regulation against the current source before you rely on it.

Document control header

FieldEntry
Document titleClinical System Decommissioning After Database Lock
Document number<<FILL: CL-ID>>
Study / protocol number<<FILL>>
System being decommissioned<<FILL: EDC / IRT / RTSM / safety database instance, platform and version>>
Version<<FILL: version, e.g. 1.0>>
Effective date<<FILL>>
Document owner<<FILL: role, e.g. Clinical Data Management lead>>

When to use this checklist

Run it once per system, after database lock is formally declared and before the vendor contract lapses, the platform is switched off, or the study data migrates to a new vendor. Run it early enough that a failed retrieval test still leaves time to fix the archive while the live system is still available as a fallback.

Section A: define the final state

#ItemPass / Fail / NAEvidence / note
A1Database lock is formally declared and documented, with the lock date on file
A2Any post-lock corrections are handled through a documented exception process, not by silently reopening the live system
A3All open queries, reconciliations (see the cross-system reconciliation log), and data cleaning activities for this system are closed
A4The system’s final configuration (build spec, edit checks, randomization list, user roles) is itself archived alongside the data

Section B: extract and verify the archive

#ItemPass / Fail / NAEvidence / note
B1Full record set exported, including the complete audit trail, in a structured, non-proprietary format that will remain readable without the original application
B2Record counts reconciled between the live system and the extract, with zero unexplained gaps
B3A sample of full records (recommend a minimum of <<FILL: number or percentage>> subjects, weighted toward high-enrollment sites) compared field-by-field between the live system and the extract
B4Audit trail entries present in the extract for the same sampled records, matching the live system’s trail
B5Metadata preserved: who, when, and version information for every record, not stripped during export

Section C: subject-level retrieval test

#ItemPass / Fail / NAEvidence / note
C1A named subject’s full record, including audit trail, retrieved from the archive alone, with no access to the original system
C2Retrieved record content matches what the live system showed before decommissioning
C3Retrieval completed within a realistic inspection timeframe (recommend documenting actual time taken)
C4Retrieval performed by someone who was not the person who built the archive, to confirm it is usable by a real future requester, not just its author

Section D: lock and document retention

#ItemPass / Fail / NAEvidence / note
D1Archive access restricted and write-protected; who can access it and under what request process is documented
D2Applicable retention floor identified and documented (the longest of the jurisdictions in play; see eTMF and the Trial Master File for the current US, EU, and UK retention floors)
D3A named, current owner of the archive is on file, not an individual expected to remember it informally
D4Decommissioning summary report completed, referencing sections A through D, and filed in the TMF

Acceptance criteria

  • Every item in Sections A through D is Pass or has a documented, risk-justified NA; no open Fail remains at sign-off.
  • The subject-level retrieval test in Section C passed on the first or a documented corrective attempt, performed by someone other than the archive’s builder.
  • The retention floor documented in D2 is the longest one that applies to this trial, not the default of whichever regulator’s rule the team happened to look up first.
  • The live system is not decommissioned or the vendor contract terminated until this checklist is fully signed.

Signoff

RoleNameSignatureDate
System owner<<FILL>>
Clinical Data Management lead<<FILL>>
QA / clinical quality<<FILL>>

References

ICH E6 Good Clinical Practice, essential document retention expectations. 21 CFR 312.62, investigator recordkeeping and record retention. EU Regulation (EU) No 536/2014, Article 58, archiving of the clinical trial master file.

Confirm the current version of each reference and the retention floor applicable to your trial before issue.


Filled specimen

An excerpt from a completed decommissioning checklist for an IRT platform at the end of a Phase 3 study. Illustrative only.

#ItemResultEvidence / note
A1Database lock formally declaredPassLock memo dated 14-Aug-2026, signed by Biostatistics and Data Management
B2Record counts reconciledPass842 randomization records and 3,110 dispensing records in the extract matched the live-system counts exactly
B3Field-by-field sample comparisonPass40 subjects sampled across the two highest-enrollment sites; all fields matched
C1Subject-level retrieval testPassSubject 0231’s full randomization and dispensing history, with audit trail, retrieved from the archive alone in 11 minutes by a data manager not involved in building the archive
D2Retention floor documentedPassTrial includes EU sites; 25-year floor under EU Regulation 536/2014 Article 58 documented as the controlling requirement, longer than the US 21 CFR 312.62 floor

Common inspection findings this checklist prevents

  • A vendor contract lapses and the IRT platform becomes inaccessible before anyone extracted a validated archive.
  • An archive exists but was never retrieval-tested by anyone other than the person who built it, so the first real test happens the day an inspector asks for a record.
  • Retention duration set by default to whichever single jurisdiction’s rule the team looked up first, missing a longer floor that actually applies (commonly the EU 25-year floor on a multi-region trial).
  • Audit trail metadata dropped during export, leaving a readable record with no way to prove nothing changed after lock.

How to adapt this checklist

  1. Run one checklist per system being decommissioned; EDC, IRT, and a safety database instance each get their own, since their record structures and retrieval mechanics differ.
  2. Set the sample size in B3 to your risk assessment; a larger, more complex study warrants a larger sample.
  3. Confirm the retention floor in D2 against every jurisdiction the trial actually touches, not only the sponsor’s home jurisdiction.
  4. Keep this checklist and its evidence in the TMF; it is itself a GCP record subject to the same retention floor it documents.
Use madhadi.com as an app Full screen, works offline, one tap from your home screen.