Validation Retest / Re-execution Authorization Form

This is a ready-to-use form. 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. Verify each cited regulation against the current published source before you rely on it, and treat this as an educational reference to adapt rather than as legal or regulatory advice.

One form covers one authorization to re-execute. It is completed and approved before the re-execution runs, never after. The governing process sits in SOP: Validation Test Incident Management.

Why this form exists

Re-running a failed test is the single most scrutinized action in validation execution. A legitimate re-test and testing into compliance look identical in the final result: both end in a PASS. What separates them is what was known and approved beforehand. This form is the record of what was known beforehand.

If a reviewer asks “why were you allowed to run this again?”, this form is the answer.

Form control header

Field table

Complete every required field. Where a field is not applicable, write N/A with a reason. Do not leave a required field blank.

1. Incident reference and context

If prior attempts exist, state each attempt reference and result. Where the attempt count reaches the limit set in your procedure, this form is not the right route; escalate instead.

2. Verified root cause

A re-test is authorized on the strength of a known cause. An unknown cause means the re-test would only be an experiment to see whether the failure recurs, which is not an authorized activity under this form.

A statement that restates the symptom is not acceptable here. “The report printed a blank batch number” is the symptom. “The report template referenced field BATCH_ID_EXT, which is only populated for externally manufactured lots, instead of BATCH_ID” is a cause.

3. Corrective action, completed and independently verified

Gate 3A. If the corrective action is not complete at the time of signing, this form is not approvable. Re-executing “while the fix is being finalized” produces a result that belongs to neither the broken nor the fixed state.

Gate 3B. Verification of completion is performed by someone other than the person who implemented the change. Self-verification of one’s own correction is one of the easiest findings for a reviewer to spot from the signature block alone.

4. Re-test scope and its justification

Scope is where a re-test authorization earns its keep. The failing step is the obvious part. Everything the correction could have disturbed is the part teams under schedule pressure cut.

4.1 Primary scope

If the acceptance criterion changed, the change is approved separately at the level that approved the original protocol, with the original text, the corrected text, and the justification recorded. A criterion may not be relaxed in this form.

4.2 Regression scope

Work the prompts below and record an answer for each. The default answer to “should we run regression?” is yes. A “no” needs a reason a reviewer would accept.

4.3 Scope justification statement

<<FILL: two to five sentences explaining the scope. State what the correction touched, what could plausibly have been affected, what is therefore in scope, and what is excluded and why. A reviewer should be able to disagree with the reasoning, which means the reasoning has to be visible.>>

5. Environment and build the re-test will run on

A re-test that runs on a different environment or build than the one intended proves nothing about the intended one. Confirm and record the exact configuration.

6. Testing-into-compliance attestation

This is the gate. Read each statement, answer honestly, and sign. A “No” on any statement means the re-execution is not authorized and the form is returned.

Attestation. I confirm that the responses above are accurate, that this re-execution is not being requested in order to obtain a passing result without an understood and corrected cause, and that I am aware that repeated re-execution without a corrected cause constitutes testing into compliance.

7. Approvals

Approval level rises with GxP impact. No person signs more than one row on the same form, and the executor of the original test does not approve its re-execution.

Rule. The latest approval date on this form is on or before the re-execution date recorded in section 8. A form approved after the re-execution ran is not an authorization; it is a retrospective justification, and the audit trail will show the order.

8. Re-execution outcome

Completed after the re-execution runs.

A failed re-execution raises a new incident referencing the original. It does not reopen the same authorization for a further attempt, because reusing the authorization hides how many attempts were made.

9. References

21 CFR 211.192, which requires that unexplained discrepancies be thoroughly investigated with the conclusion and follow-up recorded. The same logic applies to a failed validation test result. 21 CFR Part 11, for the integrity and attributability of electronically captured re-execution evidence. EU GMP Annex 15, Qualification and Validation (2015), which requires deviations from validation protocols to be documented with appropriate justification under quality risk management. EU GMP Annex 11, Computerised Systems (2011, currently in force), for reporting and assessment of deviations arising during validation. The revision published in draft on 7 July 2025, consultation closed 7 October 2025, is not final. ICH Q9(R1), Quality Risk Management, for the risk basis of the approval tiers. FDA guidance “Computer Software Assurance for Production and Quality Management System Software”, issued 3 February 2026, for the risk-based assurance context. FDA 2018 data integrity guidance, MHRA GxP Data Integrity Guidance and Definitions, and PIC/S PI 041, for the ALCOA+ expectations applied to the re-execution record. ISPE GAMP 5 Second Edition (2022), for the lifecycle context. Reference only.

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

Filled specimen

The following shows the form completed for a re-execution during the OQ of a laboratory information management system in a biologics QC laboratory. The company, system, names, and numbers are illustrative.

Sections 1 to 3

Section 4, scope

Sections 5 to 8

Read the specimen in order and the logic is visible: the cause names a specific operator and the specification gap that allowed it, the correction was verified by someone other than the person who made it, the regression scope was set by what the shared rule engine could reach rather than by what the schedule allowed, the boundary values were the exact values that exposed the defect, and every approval date precedes the execution date. That last point is what an audit trail check will confirm or contradict.

Common inspection findings this form prevents

• Re-execution records that exist with no documented authorization, so there is no evidence anyone decided the re-test was legitimate.
• Authorization forms signed after the re-execution ran, contradicted by the system audit trail.
• Re-tests approved with the root cause recorded as “unknown” or “not determined”, meaning the re-test was an attempt to see whether the failure would recur.
• Corrective actions verified by the same person who implemented them.
• Re-execution performed on a different build or environment than the one the failure occurred on, with the difference unrecorded.
• Acceptance criteria quietly relaxed between the original execution and the re-test, so the re-test passes against an easier target.
• Regression skipped after a fix to shared logic, with no justification and no QA sign-off on the omission.
• Test cases that passed while a defective condition was present, left as PASS and never revisited.
• Multiple re-execution attempts on the same step recorded as a single authorization, so the number of attempts is not visible.
• Higher-impact re-tests approved at the same level as trivial ones, with no escalation for GxP-critical functions.
• The person who executed the failing test also approving its re-execution.

How to adapt this form

1. Set your form number, numbering scheme, and the incident classification labels in section 1 to match your own procedure. If you use Critical, Major, and Minor rather than C1 to C6, rewrite the approval tier table in section 7 against your own severity terms and keep the escalation at the top severity.
2. Decide which classes require a QMS deviation number in field 3 and make that conditional rule explicit, so a form cannot be approved with the field left blank.
3. Add any regression prompts specific to your technology to section 4.2. Systems with recipe inheritance, master data hierarchies, multi-tenant configuration, or shared report templates each deserve their own prompt.
4. If you run paper execution, add a field for the controlled copy number of the re-execution pages so the new record is traceable to a controlled issue.
5. Set your attempt limit in your governing procedure and add a field to section 1 that forces disclosure of the count. The count is the signal, and hiding it is how testing into compliance survives review.
6. Keep the attestation in section 6 as a signed statement rather than a tick box. A signature against a named statement is materially different from an unattributed mark.
7. If your electronic QMS holds this form, configure the workflow so the approval step cannot be completed after the execution record is created, and so the executor cannot be selected as an approver.
8. Confirm every regulation in section 9 against the current published version before issue, in particular the status of the EU GMP Annex 11 revision, which was still in draft at the time of writing.