This is a ready-to-use release readiness checklist. It is the pre-release gate: what a validation lead and QA confirm before the release authorization is signed, so the go-live decision rests on facts rather than optimism. Mark each item Pass, Fail, or N/A, and record a reference for each. Replace every <<FILL: ...>> placeholder with your own specifics. Verify each cited regulation against the current source before you rely on it.
Identification
| Field | Entry |
|---|---|
| System name and version | <<FILL>> |
| Validation plan / VSR referenced | <<FILL: VP and VSR numbers>> |
| Target go-live date | <<FILL: date>> |
| Reviewer | <<FILL: name, role>> |
| Review date | <<FILL: date>> |
1. Execution and evidence
| # | Item | Pass / Fail / NA | Reference |
|---|---|---|---|
| 1.1 | All planned protocols executed and test evidence collected | <<FILL>> | |
| 1.2 | All executed protocols reviewed and approved | <<FILL>> | |
| 1.3 | Executed evidence reconciles to the results summary in the VSR (no hidden failures or reruns) | <<FILL>> |
2. Traceability
| # | Item | Pass / Fail / NA | Reference |
|---|---|---|---|
| 2.1 | Every requirement traced to a verifying test | <<FILL: RTM>> | |
| 2.2 | Every verifying test has a passing result, or a documented, accepted exception | <<FILL>> | |
| 2.3 | No orphan tests (tests with no requirement) and no coverage claimed beyond what is traced | <<FILL>> |
3. Deviations
| # | Item | Pass / Fail / NA | Reference |
|---|---|---|---|
| 3.1 | Every deviation has a root cause, impact assessment, resolution, and status | <<FILL: deviation log>> | |
| 3.2 | All critical deviations closed (a critical deviation is never carried as a condition) | <<FILL>> | |
| 3.3 | All major deviations closed, or carried as explicit conditions with compensating control, owner, and due date | <<FILL>> | |
| 3.4 | No failure reclassified to a lower class without sound technical justification | <<FILL>> |
4. Operational readiness
| # | Item | Pass / Fail / NA | Reference |
|---|---|---|---|
| 4.1 | Operation SOP approved and effective | <<FILL>> | |
| 4.2 | Backup/restore and business continuity / disaster recovery procedures approved | <<FILL>> | |
| 4.3 | Security administration and access-control procedures in place | <<FILL>> | |
| 4.4 | Periodic review procedure and interval defined | <<FILL>> | |
| 4.5 | Training completed for users and administrators | <<FILL>> | |
| 4.6 | Supporting infrastructure qualified | <<FILL>> | |
| 4.7 | Data migration verified, if applicable | <<FILL: or N/A>> |
5. Risk and authorization
| # | Item | Pass / Fail / NA | Reference |
|---|---|---|---|
| 5.1 | Residual risk assessed and formally accepted at the appropriate level | <<FILL: RRA number>> | |
| 5.2 | Fitness conclusion in the VSR is explicit (fit, fit with conditions, or not fit), not a soft “generally meets” | <<FILL>> | |
| 5.3 | Release authorization prepared, with the quality-unit signature as the gating approval | <<FILL: release record>> | |
| 5.4 | QA approval date is on or before the target go-live date | <<FILL>> | |
| 5.5 | Release linked to change control so future changes start from a known validated state | <<FILL: CR number>> |
Signoff
| Role | Name | Signature | Date | Decision |
|---|---|---|---|---|
| Validation lead | <<FILL>> | <<FILL>> | ||
| Quality Assurance | <<FILL>> | <<FILL: Ready to release / Not ready>> |
References
21 CFR 211.22, 211.68; 21 CFR Part 11. EU GMP Annex 11 (computerised systems) and Annex 15 (qualification and validation). GAMP 5 (Second Edition, ISPE 2022); FDA Computer Software Assurance guidance (current version issued 3 February 2026) for risk-proportionate evidence.
Confirm the current version and clause numbers before use.
Filled specimen
Selected rows completed for the example QC LIMS release.
| # | Item | Pass / Fail / NA | Reference |
|---|---|---|---|
| 2.2 | Every test has a passing result or accepted exception | Pass | RTM-LIMS-2026, 142/142 |
| 3.2 | All critical deviations closed | Pass | DEV log; no open criticals |
| 3.3 | Majors closed or carried as conditions | Pass | DEV-05, DEV-06 carried as conditions with owners and due dates |
| 4.7 | Data migration verified | Pass | Migration report; 1 deviation resolved |
| 5.1 | Residual risk accepted | Pass | RRA-2026-011, accepted by Head of QA |
| 5.4 | QA date on or before go-live | Pass | QA approval 19 June; go-live 22 June |
Decision: Ready to release. Every critical item is a clean pass; the two open majors are carried as explicit, tracked conditions rather than hidden, and the QA signature precedes go-live. Had 5.4 failed (QA date after go-live), the release would not be defensible regardless of the other passes.
How to adapt this checklist
- Align section 4 with the SOPs your quality system actually requires before go-live.
- Scale the depth to the system’s risk: a Category 1 infrastructure component does not need the same weight as a Category 5 custom application.
- Treat 3.2 and 5.4 as hard gates: an open critical deviation or a QA signature after go-live blocks release on its own.
- Record a reference for every Pass; a column of bare “Pass” marks with no references reads as a rubber stamp.
- Carry any Fail into the deviation or CAPA system, and do not authorize release until the gating items pass.