Checklist: Validation Test Readiness Gate

This is a ready-to-use go/no-go checklist for the test readiness gate, the checkpoint between an approved protocol and the first executed test step. Run it before IQ, before OQ, and before PQ/UAT; a system that is ready for IQ is not automatically ready for OQ. Replace every <<FILL: ...>> placeholder, score each line Pass, Fail, or N/A, and hold execution until every applicable line passes. A worked filled specimen follows the template.

Document control header

Field	Entry
Document title	Test Readiness Gate Checklist
Document number	`<<FILL: reference, e.g. TRG-VPP-031-OQ>>`
System / project	`<<FILL: SYSTEM NAME>>`
Gate	`<<FILL: IQ / OQ / PQ-UAT>>`
Date of review	`<<FILL: date>>`
Reviewed by	`<<FILL: Validation Lead, QA>>`

1. Purpose

This checklist confirms that every prerequisite for executing a validation protocol is objectively in place before the first test step is performed, so that execution effort is not spent against a broken environment, an expired calibration, an unapproved protocol, or an untrained executor. It is the single most schedule-protective gate in a validation project because a failure caught here costs a delay; the same failure caught mid-execution costs a delay plus rework plus a credibility hit with QA.

2. Readiness checklist

#	Item	Evidence to check	Result (Pass/Fail/NA)
1	The qualified environment exists and matches the assumptions in the IQ / protocol	Environment build record, configuration baseline	`<<FILL>>`
2	Every test instrument used in this execution is in calibration for the full execution window	Calibration certificates, due dates beyond planned execution end	`<<FILL>>`
3	Reference standards or challenge materials are within their use-by date	Certificates of analysis, expiry dates	`<<FILL>>`
4	The protocol is approved with pre-approved, unambiguous acceptance criteria	Signed protocol, approval dates	`<<FILL>>`
5	No open, unresolved deviation from a prerequisite gate blocks this execution	Deviation log for prior gate	`<<FILL>>`
6	Every executor is trained on the protocol and the system, and that training is documented as complete before today’s date	Training records, curriculum assignment	`<<FILL>>`
7	Test data, including any negative or challenge-test data, is prepared and available	Test data set, data preparation record	`<<FILL>>`
8	Required user accounts, access, and permissions for testers are provisioned and verified	Access request / provisioning record	`<<FILL>>`
9	Vendor or support resources needed during execution are confirmed available for the window	Vendor coordination log, on-call confirmation	`<<FILL>>`
10	Blank protocol copies, data capture forms, and the deviation log are ready and controlled	Document control issue record	`<<FILL>>`
11	The system clock / time source is synchronized and controlled for the execution window	Time synchronization check	`<<FILL>>`
12	For OQ/PQ specifically: the prior gate (IQ for OQ; OQ for PQ) is passed and its deviations are dispositioned, not just closed for scheduling convenience	Prior gate summary, deviation dispositions	`<<FILL>>`

3. Gate decision

Every applicable line above scored Pass? Yes → Proceed, record the decision and start execution

↓

One or more Fail, and the item can be closed same day with no risk to test integrity? → Hold, close the item, re-score, then proceed

↓

One or more Fail, cannot close same day, but a documented, risk-assessed conditional path exists (for example, testing a subset that does not depend on the failed item)? → Conditional proceed, name the open item, owner, and due date in writing, QA concurs

↓

One or more Fail with no safe conditional path? → Hold execution, re-baseline the schedule, escalate to the sponsor

Field	Entry
Overall gate result	Proceed / Hold / Conditional proceed / Hold execution
Open items (if conditional)	`<<FILL: item, owner, due date>>`
Validation Lead decision	`<<FILL: name, date>>`
QA concurrence	`<<FILL: name, date>>`

4. Acceptance criteria

The gate is passed when every applicable line is scored Pass, or when a documented conditional-proceed decision has been made by the Validation Lead with QA concurrence, naming the open item, its owner, and its due date in writing. “Proceed and fix it later” with nothing written down is not an acceptable outcome under any circumstance.

5. References

GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems, Second Edition (ISPE), for the risk-based test strategy this gate protects. EU GMP Annex 15 (Qualification and Validation), for qualification stage sequencing. 21 CFR 211.68, for the requirement that equipment used to test and record data be suitable and appropriately checked.

Confirm the current version of each reference before issue.

6. Revision history

Version	Date	Author	Summary of change
`<<FILL: 1.0>>`	`<<FILL: date>>`	`<<FILL: author>>`	Initial issue.

Filled specimen

The following shows the checklist completed for an example OQ gate on a configured LIMS, so you can see the level of detail expected. The system and dates are illustrative; replace them with your own.

#	Item	Result	Comment
1	Environment matches IQ assumptions	Pass	Build record BR-014 confirms configuration baseline CFG-LIMS02-1.0
2	Test instruments in calibration	Pass	Reference balance BAL-014, cal due 2026-11-30, covers execution window
3	Reference standards within date	N/A	No physical reference standards used in this OQ
4	Protocol approved with pre-approved criteria	Pass	OQ-LIMS02-1.0 approved 2026-08-10
5	No open deviation blocking from prior gate	Pass	IQ-LIMS02-1.0, 1 deviation, closed and dispositioned 2026-08-08
6	Executors trained	Fail	One of three executors’ training record not yet complete
7	Test data prepared	Pass	Challenge data set TD-LIMS02-OQ loaded to test environment
8	Accounts and access provisioned	Pass	Access request AR-2026-0311 verified
9	Vendor support confirmed	Pass	Vendor confirmed on-call for execution week
10	Controlled forms ready	Pass	Issued by document control 2026-08-11
11	System clock synchronized	Pass	NTP sync verified against site controlled time source
12	Prior gate passed and dispositioned	Pass	See item 5
Overall gate result	Conditional proceed	Untrained executor is reassigned off the execution roster for this week; remaining two executors are fully trained and sufficient for the planned test cases; training completion required before that executor is added to any execution roster
Open items	Complete training for third executor, owner: Training Coordinator, due 2026-08-18
Decision	Validation Lead J. Alvarez, 2026-08-12; QA concurrence R. Gomez, 2026-08-12

Common inspection findings this checklist prevents

Execution started with an executor whose training record post-dates the execution date, discovered only when an inspector cross-checks training against the execution log.
A test instrument’s calibration expired mid-execution, invalidating every test result that relied on it.
Acceptance criteria added or changed after execution began because the protocol was rushed into use before formal approval.
A verbal “we’ll sort it out” readiness decision with nothing written down, later impossible to reconstruct when a deviation is investigated.

How to adapt this checklist

Set the system, gate, and reviewer fields in the header, and run one instance per gate (IQ, OQ, PQ/UAT), not one for the whole project.
Add or remove readiness lines to match your environment; a cloud/SaaS system may need a line for confirmed vendor change-freeze during execution, a manufacturing system may need a line for utility qualification status.
Keep the gate decision section as a literal go/no-go with names and dates; never let it become a status narrative with no decision recorded.
File the completed checklist with the protocol package so an inspector or auditor can find it alongside the execution evidence it gates.