This is a ready-to-use peer review checklist for the content of a validation protocol, not for the environment it will run in and not for what happened during execution. Replace every <<FILL: ...>> placeholder, score each line Pass, Fail, or N/A, and resolve every Fail before the protocol is routed to the formal approval signatures. A worked filled specimen follows the template. This is general guidance to adapt, not regulatory advice; verify each cited regulation against the current source before you rely on it.
Why this checklist is not a duplicate of the readiness gate
A test readiness gate confirms the environment, instruments, training, and data are ready for an already-approved protocol to be executed. This checklist runs earlier and asks a different question: is the protocol itself, the words on the page, good enough to approve. A protocol can pass every readiness item and still be a bad protocol, vague criteria, bundled steps, no traceability, because readiness says nothing about content quality. This checklist is the content gate; the readiness gate is the execution gate. Run this one first, on the draft, before the protocol goes to the author’s own review and then to formal approval. It is also distinct from a deviation record, which documents what happened during execution, and from the validation summary report, which closes the effort out; this checklist exists entirely before either of those is relevant.
Document control header
| Field | Entry |
|---|---|
| Record title | Validation Protocol and Test Script Content Peer Review |
| Review number | <<FILL: e.g. PR-OQ-LIMS-004>> |
| Protocol under review (number, title, version) | <<FILL>> |
| System / equipment / process | <<FILL>> |
| Validation phase | IQ / OQ / PQ / UAT / <<FILL: other>> |
| Reviewer (independent of the author) | <<FILL: name, role>> |
| Review date | <<FILL>> |
1. Purpose
This checklist confirms that a draft protocol and its test scripts meet the authoring standard before they are routed for approval signature: acceptance criteria are objective and predefined, steps are atomic and unambiguous, evidence is pre-planned and traceable, requirements coverage is complete, and the rigor of each script matches the risk of the function it tests. Catching a weak criterion or a bundled step here costs a redline. Catching the same problem during execution costs a deviation, a re-execution, and a credibility question from whoever reviews the executed package later. Catching it after an inspector reads the executed protocol costs a finding.
2. Content review checklist
| # | Item | What good looks like | Result (Pass/Fail/NA) | Comment |
|---|---|---|---|---|
| 1 | Purpose statement is specific to this system and this protocol | Not “this protocol validates the system”; states exactly what will be demonstrated, in terms specific to this system | <<FILL>> | |
| 2 | Scope states explicit exclusions with a reason | Not “everything in scope”; excluded modules, interfaces, or functions are named with why they are excluded | <<FILL>> | |
| 3 | Every in-scope requirement has at least one linked test | Cross-check the protocol’s test list against the requirements or risk assessment document, not just against itself | <<FILL>> | |
| 4 | Every test traces back to a requirement ID | No orphan tests that exercise something nobody asked for, unless justified and documented as such | <<FILL>> | |
| 5 | Acceptance criteria are objective, measurable, and binary | No “functions correctly,” “displays properly,” or “works as expected.” A reviewer not present at execution could read an actual result and reach the same verdict without judgment | <<FILL>> | |
| 6 | Each test step is a single atomic action | No step that bundles login, navigation, and an assertion into one line; a failure has to be localizable to one step | <<FILL>> | |
| 7 | Steps that carry proof have a written expected result | Not every step needs one (moving to a screen usually does not), but the steps that matter do | <<FILL>> | |
| 8 | Test data and accounts are named and specific | No “a user,” no “some data”; named test accounts and identified test data sets or record IDs throughout | <<FILL>> | |
| 9 | Positive, negative, and boundary cases are present where the function has a meaningful failure mode | A script that only proves the happy path is incomplete; check that denial, rejection, and edge-value behavior are tested where relevant | <<FILL>> | |
| 10 | Objective evidence references are pre-planned into the script | Evidence numbering (for example SS-012-3) already exists as a placeholder in the draft script, not left for the executor to invent | <<FILL>> | |
| 11 | The rigor of each script matches the documented risk of the function | Direct-impact, Part 11/Annex 11 controls (audit trail, e-signature, access control) get full scripted testing; genuinely indirect-impact functions routed to unscripted or exploratory testing carry a written risk basis, not an informal call | <<FILL>> | |
| 12 | Prerequisites and entry criteria are specific to this system | Not generic boilerplate; states what must actually be true (prior gate approved, specific accounts configured, specific test data loaded) before execution starts | <<FILL>> | |
| 13 | Assumptions, limitations, and exclusions are stated, not silent | Anything a reader needs to correctly interpret the results (simulated interface, test environment differences from production) is written down | <<FILL>> | |
| 14 | No copy-paste artifacts from a reused template | System name, function names, screen names, and account names are consistent with the actual system under test throughout, with no leftover references to a different system | <<FILL>> | |
| 15 | Roles and approval routing are complete | Author, SME, and QA are all named as approvers, with no execution date field pre-filled before approval | <<FILL>> | |
| 16 | Deviation and amendment handling is referenced correctly | The protocol points to the deviation process for execution-time departures and states how a pre-execution or mid-execution correction to the protocol text itself would be controlled | <<FILL>> |
3. Review decision
| Field | Entry |
|---|---|
| Overall review result | Approve for routing / Minor rework / Substantive rework |
| Items requiring correction | <<FILL: item number, description, owner>> |
| Reviewer sign-off | <<FILL: name, date>> |
4. Acceptance criteria for this checklist
This review is complete only when every applicable line is scored, every Fail is either corrected and re-checked or explicitly accepted with a documented rationale by the reviewer, and the review decision is recorded with a name and a date before the protocol is forwarded for formal approval signature.
5. References
21 CFR 211.100 and 211.194 (written procedures and complete testing/examination records), for the underlying expectation that test methods and results be documented and defensible. 21 CFR Part 11 (electronic records and signatures), where the protocol or its evidence is electronic. EU GMP Annex 11 (Computerised Systems) and Annex 15 (Qualification and Validation), 2015 revision. GAMP 5 (Second Edition, ISPE) for the specification-and-verification model and the discipline of test script authorship. FDA Computer Software Assurance for Production and Quality Management System Software, final guidance issued 3 February 2026, superseding the 24 September 2025 version, for the risk basis behind item 11.
Confirm the current version and clause numbers 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 draft OQ protocol for a laboratory information management system (LIMS), before it was routed for approval. The system and findings are illustrative; replace them with your own.
| # | Item | Result | Comment |
|---|---|---|---|
| 1 | Purpose statement specific | Pass | States the protocol verifies e-signature enforcement, audit trail capture on result changes, and role-based reprocessing restriction |
| 2 | Scope exclusions stated with reason | Pass | Instrument-integration interface explicitly out of scope, validated separately under a different protocol |
| 3 | Every in-scope requirement linked to a test | Fail | URS-LIMS-052 (retention of superseded results) has no corresponding test case in the draft |
| 4 | Every test traces to a requirement | Pass | Spot-checked 12 of 34 test cases against the URS, all trace cleanly |
| 5 | Acceptance criteria objective and binary | Fail | TC-019’s criterion reads “audit trail works correctly,” no named fields or values |
| 6 | Steps are atomic | Fail | TC-011 step 3 combines “log in, navigate to results, and attempt reprocessing” in one line |
| 7 | Proving steps have expected results | Pass | Spot-checked; present where needed |
| 8 | Named test data and accounts | Pass | Test accounts and sample IDs named throughout |
| 9 | Positive and negative cases present | Pass | Reprocessing restriction has both an allowed-role and a denied-role test |
| 10 | Evidence numbering pre-planned | Pass | SS-xxx-x placeholders present in every proving step |
| 11 | Script rigor matches risk | Fail | The result-rounding display function (indirect, cosmetic) is scripted at the same six-step depth as the e-signature binding test, with no documented risk basis for either choice |
| 12 | Prerequisites specific to this system | Pass | Names the exact build, IQ reference, and test account roles |
| 13 | Assumptions and exclusions stated | Pass | States testing occurs in the validation environment, not production |
| 14 | No copy-paste artifacts | Pass | No references to any other system found |
| 15 | Roles and approval routing complete | Pass | Author, SME, QA all named; execution date fields blank |
| 16 | Deviation and amendment handling referenced | Pass | Points to the site deviation SOP and states protocol text corrections route through a numbered addendum |
| Overall result | Substantive rework | Items 3, 5, 6, and 11 require correction and a full re-review before routing | |
| Items requiring correction | Item 3: add TC for URS-LIMS-052, owner Author. Item 5: rewrite TC-019 criterion to name the captured fields, owner Author. Item 6: split TC-011 step 3 into three steps, owner Author. Item 11: document a risk basis for the rounding-display function and either descope it to exploratory or justify the full script, owner Author with SME input | ||
| Reviewer sign-off | K. Nakamura, Validation Lead, 2026-08-19 |
In this example, the protocol was well built in most respects, named data, complete evidence numbering, sound scope statement, but the reviewer caught a genuine coverage gap (item 3), a criterion that would have been unfalsifiable at execution (item 5), a bundled step that would have made any failure impossible to localize (item 6), and an undocumented rigor decision that would not have survived a question about why two functions of different risk got identical treatment (item 11). All four are cheap to fix on a draft and expensive to discover mid-execution or in front of an inspector.
Common inspection findings this checklist prevents
- A protocol approved with an acceptance criterion so vague that the pass/fail decision at execution was effectively made by the executor’s judgment, not by a predefined bar.
- A test step that bundled three actions, so a failure could not be traced to which action actually failed, and the deviation investigation had to guess.
- A requirement with no linked test, discovered only when an inspector builds a traceability matrix independently and finds the gap the team missed.
- A copy-paste protocol with a leftover reference to a different system’s screen name, exposing that the document was never actually read end to end before approval.
- A low-risk, indirect-impact function scripted at the same depth as a Part 11 control, and a high-risk function tested unscripted, both with no written rationale, so the rigor decisions look arbitrary under questioning.
- A protocol whose deviation and amendment handling is never mentioned, so the first time anyone thinks about how a mid-execution correction would work is during the correction itself.
How to adapt this checklist
- Set your review numbering scheme and require this checklist for every protocol phase, IQ, OQ, PQ, or UAT, before it leaves draft status.
- Assign the reviewer role to someone independent of the protocol’s author; a self-review by the author is not this checklist, even if they run through the same items.
- Tune item 11 to your own risk-based testing program; if your site has not adopted a CSA-aligned risk classification, mark it N/A and consider whether that is itself a gap worth closing.
- Keep the review decision literal, a recorded go or no-go with a name and date, never a status narrative with no decision.
- File the completed checklist with the protocol package so a later reviewer, or an auditor, can see that content quality was checked before approval, not only after execution.