Protocol: Retrospective IQ/OQ (Current-State Qualification) of a Legacy GxP System

This is a ready-to-use retrospective qualification protocol for a legacy GxP computerized system already in production. It confirms the installation from the live system as it exists (current-state IQ) and tests the operational functions in proportion to risk (OQ). Replace every <<FILL: ...>> placeholder, set your document numbers and dates, and route it through document control. Approve the protocol before you execute it. A worked filled specimen follows. This is general guidance to adapt and verify, not legal or regulatory advice; confirm each cited regulation against the current source before you rely on it.

Approval page

Protocol number <<FILL: PROT-ID>>, version <<FILL>>. Governing SOP <<FILL: SOP-ID for retrospective validation>>. Risk assessment reference <<FILL: RA-ID>>.

1. Objective

Provide documented evidence that <<FILL: SYSTEM NAME / ID>>, already in GxP use, is installed and configured as recorded and that its GxP-critical functions operate correctly in the current production configuration. Because the system is in use, the installation is confirmed from the live state rather than specified in advance, and operational testing depth is set by the approved risk assessment.

2. Scope

In scope: the live production instance of the system, its current software and database versions, user roles, audit-trail configuration, backup configuration, and interfaces. Functional testing covers the GxP-critical functions identified as High or Medium risk in <<FILL: RA-ID>>. Out of scope: <<FILL: e.g. server OS qualification covered under infrastructure IQ, prospective changes>>.

3. System description

4. Prerequisites

• Approved risk assessment <<FILL: RA-ID>> on file; classification recorded.
• This protocol approved (approval page) before any test is executed.
• Test evidence method defined (screenshots, exports, printouts), each labelled with system, date, and tester.
• Testers trained on the system and on <<FILL: SOP-ID for test failure management>>.
• A test account set exists for each role to be exercised, or the plan for using production accounts safely is documented.

5. Roles

6. Current-state IQ

Confirm each item from the live system and attach evidence. Record the “as found” value; where a value cannot be confirmed, mark it and raise it as a finding (it feeds the risk picture).

IQ acceptance criterion: a documented, evidence-backed configuration baseline a second qualified person could reproduce from the live system, with every “as found” value either confirmed or explicitly flagged as unverifiable.

7. Risk-based OQ test cases

Execute the cases that match the risk of each function. The set below covers the functions most legacy systems must prove. Add or remove cases to match <<FILL: RA-ID>>.

OQ-01 (High): Audit trail captures a result modification

• Objective: confirm the system records who changed a result, the old and new values, the timestamp, and a reason, and that the entry is immutable.
• Steps: log in as Analyst A, modify a stored result, enter a reason, save. Log in as Reviewer B, open the audit trail for that record. Attempt to edit or delete the audit-trail entry as each role.
• Expected: the audit trail shows Analyst A, the prior and new value, date and time, and the reason; no role can edit or delete the entry.
• Acceptance: all five attributes present and the entry immutable. Evidence: audit-trail screenshot.

OQ-02 (High): Calculation accuracy against an independent recalculation

• Objective: confirm the system computes reportable results correctly, including at the specification boundary.
• Steps: process a defined dataset; record the system result. Recalculate the same result independently (hand calculation or a separate validated tool), including one value at the specification boundary and one deliberately out-of-range value.
• Expected: system result equals the independent recalculation within the defined tolerance; the out-of-range value is flagged as expected.
• Acceptance: agreement within tolerance for every sampled result. Evidence: system printout and the independent recalculation.

OQ-03 (High): Electronic signature behavior

• Objective: confirm signatures are bound to the record and manifest the signer, meaning, and time.
• Steps: apply a signature as the authorized role; inspect the signed record; attempt to apply a signature as an unauthorized role.
• Expected: signature shows name, meaning, date, and time, is bound to the record, and cannot be applied by an unauthorized role.
• Acceptance: all signature attributes present and binding enforced. Evidence: signed-record view.

OQ-04 (Medium): Access control and role enforcement

• Objective: confirm each role can perform only its permitted actions.
• Steps: log in as each defined role; attempt one permitted and one prohibited action per role.
• Expected: permitted actions succeed; prohibited actions are blocked and, where applicable, logged.
• Acceptance: the role matrix in <<FILL: RA-ID>> is enforced as documented. Evidence: per-role screenshots.

OQ-05 (Medium): Time source and timestamp integrity

• Objective: confirm timestamps are accurate and the clock is not user-alterable.
• Steps: compare a system timestamp to the reference time source; attempt to change the clock or time zone as an ordinary user.
• Expected: timestamps match the reference within tolerance; ordinary users cannot change the clock.
• Acceptance: timestamps accurate and clock protected. Evidence: comparison record.

Low-risk, demonstrably stable functions may be covered by lighter, history-supported verification with the reasoning documented rather than a full test case.

8. Deviation handling

Any failed test case is recorded as a deviation per <<FILL: SOP-ID for test failure management>>, assessed as a test-script error or a real system defect, and resolved before the summary can conclude. A script error is corrected, re-approved, and re-executed with both attempts retained; a real defect drives a fix, a compensating control, or a documented limitation.

9. Summary and conclusion

10. Attachments

<<FILL: IQ evidence, OQ evidence, user-list export, configuration exports, deviation records>>.

11. References

21 CFR Part 11 (11.10(a) validation; 11.10(e) audit trail) and 21 CFR 211.68, 211.194. EU GMP Annex 11 (Computerised Systems). ISPE GAMP 5 (Second Edition) for the lifecycle and test-case structure. FDA guidance, Computer Software Assurance for Production and Quality Management System Software (current version 3 February 2026).

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

Filled specimen

One executed OQ case, illustrative, for CDS-03.

The IQ on the same system found the audit trail had been enabled at full detail only after the second upgrade. That “as found” fact was recorded as an IQ finding, fed the historical-review scope, and became a documented limitation in the summary report rather than being smoothed over.

Common inspection findings this protocol prevents

• Reusing an old protocol against a system that has since been upgraded and migrated.
• IQ “as found” values assumed rather than verified from the live system.
• OQ depth flat across all functions with no link to the risk assessment.
• Audit-trail immutability asserted but never actually tested against each role.
• Test failures resolved without a deviation, or the failing attempt discarded.

How to adapt this protocol

1. Set your protocol number and link the governing SOP and risk assessment.
2. Trim or extend the IQ table and the OQ set to match the real system and the approved risk assessment.
3. Define your evidence convention and your specification tolerance for the calculation case.
4. Ensure QA approval is captured on the approval page before any test is executed.
5. Confirm every regulation in section 11 against the current published version before issue.