Requalification /
Revalidation Protocol FAQ

A partial, bridging requalification is appropriate when the triggering change or the elapsed time since last qualification only affects specific, identifiable aspects of the system's performance, while a full requalification is warranted when the change is significant enough — such as a major version upgrade or a substantial equipment modification — that confidence in the system's overall validated state can no longer be reasonably assumed from the original data alone.

The decision should be documented in a risk assessment specific to the requalification, explicitly identifying which original qualification results are still considered valid and being leveraged, and which areas require fresh testing.

The original qualification protocol establishes a system's validated state from a starting point of no prior evidence; a requalification protocol builds on and references that existing qualification history, typically testing a narrower, risk-justified scope focused on what's changed or what time has elapsed since, rather than repeating every test performed originally.

A requalification protocol needs a targeted risk assessment specific to the requalification trigger — assessing what the change or elapsed time actually affects — even though it can and should reference the original system risk assessment as context; simply reusing the original risk assessment unchanged doesn't address the specific question of what needs to be reverified now.

Yes — strong, well-trended routine monitoring or periodic review data can justify reducing requalification testing scope for the specific parameters that data already demonstrates remain in control, provided the leveraging rationale is explicitly documented in the requalification protocol rather than simply assumed.

Only the aspects genuinely affected by the requalification trigger typically need retesting, provided a documented impact assessment supports that narrower scope — retesting the entire original IQ/OQ/PQ regardless of what actually changed is usually unnecessary effort that doesn't add meaningful assurance beyond a properly scoped, risk-based requalification.

The requalification protocol should explicitly reference the original URS, risk assessment, and IQ/OQ/PQ protocols and reports it's building on, along with any subsequent change control records affecting the system, so a reviewer can trace the complete lineage from initial qualification through every intervening change to the current requalification.

Missing original qualification documentation should be treated as a gap requiring remediation, typically through a documented retrospective assessment or, for higher-risk systems, a fresh full qualification rather than a reduced-scope requalification — you can't credibly leverage or reference qualification evidence that doesn't actually exist or can't be located.

Acceptance criteria should generally remain consistent with the original qualification unless there's a specific, documented reason to change them — such as a revised regulatory expectation or a corrected error in the original criteria — since changing acceptance criteria without justification during requalification can look like an attempt to make a marginal system pass rather than a genuine reassessment.

This should be treated as a deviation, triggering an investigation into when and why the system drifted out of compliance, an assessment of any GxP activity affected during the period the requirement wasn't being met, and corrective action to restore compliance before the requalification can be successfully concluded.

Some requalification testing, particularly passive verification or data review, can often be performed without disrupting live production, while testing that requires forcing conditions or challenging the system beyond normal operating parameters typically requires scheduled downtime — the requalification protocol should explicitly plan for which tests need offline execution and coordinate that downtime in advance.

The requalification protocol should follow the same approval hierarchy as the original qualification protocols — typically the system owner, engineering, and QA — since it carries the same weight as evidence supporting the system's validated status and needs the same level of formal review before execution begins.

The requalification protocol should be approved and, where practical, executed as close as possible to the change implementation, ideally with the protocol approved before the change goes live so the requalification testing itself can begin immediately afterward — leaving a significant gap between a change and its requalification extends the period the system operates without confirmed validated status.

The change control record should reference the requalification protocol as part of its implementation and closure requirements, and the change shouldn't be considered fully closed until the requalification protocol has been successfully executed and approved — treating the change as closed before requalification is complete creates a gap where the system's validated status is technically unconfirmed.

A delay to scheduled or due requalification should be documented with a risk assessment justifying continued system use during the delay period, an updated target date, and QA approval of the delay — an undocumented, informal delay leaves the system's validated status unsupported for however long the gap actually extends.

A full requalification typically warrants its own summary report similar in structure to a validation summary report, while a smaller, bridging requalification is often documented through a lighter-weight summary or an addendum to the existing validation documentation — the level of documentation should be proportionate to the scope and risk of the requalification itself.

A complete requalification protocol should state the specific trigger for the requalification, reference the original qualification evidence being leveraged, define the scope of testing with justification for what's included and excluded, specify acceptance criteria, and identify the approvers.

• Trigger and rationale for the requalification.
• Reference to original qualification protocols and reports.
• Risk assessment justifying the requalification scope.
• Test scripts and acceptance criteria for the areas being retested.
• Reference to the associated change control record, if applicable.
• Approval signatures and dates.

Successful requalification should update the system's GxP inventory entry and validation file with the new requalification date, a reference to the requalification report, and, where relevant, an updated next-due date for periodic review or future requalification, so the system's official record reflects the most current qualification evidence rather than only the original, superseded qualification.

Requalification protocols and results should be retained for as long as the system remains in GxP use, plus the site's standard retention period after decommissioning, since each requalification cycle is part of the continuous evidentiary chain demonstrating the system's validated status throughout its operational life.

Inspectors typically check that the requalification scope was genuinely justified by a documented risk assessment rather than arbitrarily narrowed, that the protocol traces clearly back to the original qualification and any relevant change control, and that requalification occurred on schedule or any delay was properly risk-assessed and approved.

A frequent finding is a requalification with a reduced test scope but no documented rationale explaining why specific tests from the original qualification were omitted — this reads as scope-cutting rather than a deliberate, risk-based decision.

The most common mistake is scoping a requalification protocol too narrowly to save time and cost without a genuine, documented risk-based justification — the reduced scope might be entirely defensible, but without the documented rationale, it looks identical to an unjustified shortcut, which is exactly what an inspector will assume when reviewing it.