SOP: Retrospective Validation of Legacy GxP Computerized Systems

This is a ready-to-use SOP for the retrospective (retroactive) validation of a GxP computerized system that entered use without adequate validation. 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. 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.

Document control header

1. Purpose

This procedure defines how <<FILL: COMPANY NAME>> brings a legacy GxP computerized system into a validated state when the system entered regulated use without adequate validation, or when its validation no longer reflects the system as configured today. The objective is documented evidence that the live system does what it is intended to do reliably, that the data it has produced can be trusted for the decisions it feeds, and that the remediation is scoped to risk and documented honestly.

2. Scope

This procedure applies to any computerized system, application, instrument controller, embedded system, or spreadsheet that creates, modifies, stores, or transmits GxP records at the sites listed in the header and that is found to be unvalidated or under-validated. It covers the discovery, classification, risk assessment, remediation-path decision, retrospective qualification, historical data review, disclosure assessment, and return to routine control. It does not govern the validation of new systems, which follows <<FILL: SOP-ID for prospective CSV>>, nor process or method validation.

3. Responsibilities

4. Definitions

• Legacy system: a GxP computerized system already in operational use that lacks adequate, current validation evidence for its present configuration.
• Retrospective (retroactive) validation: performing, now, the validation activities that should have been done originally, testing the live current state and using operating history only as an input to risk and scope, not as a substitute for testing. It is distinct from the abandoned practice of “retrospective process validation” (concluding a process is valid from historical batch data).
• Current-state IQ: an installation qualification confirmed from the live system as it exists, rather than specified in advance of installation.
• Classification (A / B / C): a documented judgment of the system’s condition that determines the remediation path. See section 5.2.
• Historical data review: a risk-based, sampled review of data already generated by the system, designed to detect data integrity problems in the records the system has produced.

5. Procedure

5.1 Trigger and inventory

1. This procedure is triggered when a system in section 2 scope is identified as unvalidated or under-validated, whether by inventory, internal audit, a change request, due diligence, or inspection.
2. Confirm the system is on the computerized system inventory (<<FILL: inventory register ID>>) with a validation-status flag. If it is not, add it before proceeding, because an unlisted system is itself a gap.
3. Once the gap is documented and known, remediation is time-bound. Record the discovery date; inaction after a known gap becomes its own finding.

5.2 Classify the system

Classify the system honestly in a signed record before any remediation begins. The classification is the rationale for everything that follows.

5.3 Risk assessment

1. Run a structured risk assessment aligned with ICH Q9(R1) and <<FILL: SOP-ID for CSV risk assessment>>, using the classification as context. Record it on <<FILL: form ID for legacy classification and risk assessment>>.
2. Score each GxP function of the system on severity of consequence, probability of error, and detectability, letting severity dominate because it is the patient-facing dimension.
3. Address at least: the GxP decisions the data feeds, the failure modes (correctness versus trust-of-record), the data integrity controls actually present now, the evidence the system has worked, and whether the data reached a regulatory submission.
4. The risk assessment sets the depth of testing in section 5.6 and the extent of the historical review in section 5.7. High-risk functions get full testing; low-risk, demonstrably stable functions get a lighter touch justified in writing.

5.4 Remediation-path decision

1. Decide between retrospective validation and replacement using the classification and risk assessment.
2. Choose replacement (or remediate-then-replace) when any of the following is true: the production version can no longer be meaningfully qualified because vendor support and testing evidence are gone; the design cannot support required GxP controls (no audit trail, no individual authentication) and cannot be upgraded; the historical integrity picture cannot be characterized because no audit trail was ever kept; or the total cost of retrospective validation plus ongoing maintenance exceeds a modern replacement.
3. Document the decision and its basis. A replacement decision routes to <<FILL: SOP-ID for system replacement / migration>> and, for data carried forward, <<FILL: SOP-ID or protocol for data migration validation>>.

5.5 Validation plan

Open the remediation with a validation plan (or a remediation section in the validation master plan) that names the deliverables, the approvers, the acceptance criteria, and the schedule, so the package has a controlling document from the start and the retrospective nature is declared up front.

5.6 Retrospective IQ and risk-based OQ

1. Write, approve, then execute the protocols. Even in retrospective remediation the protocol is approved before execution. Writing a protocol, reading results that already exist, and documenting them as if executed prospectively is fabrication and is prohibited.
2. Perform a current-state IQ that records the live configuration (software and database versions, settings, user roles, audit-trail configuration, backup configuration, interfaces), verified from the system rather than assumed. Flag any value that cannot be confirmed as a finding.
3. Perform an OQ scoped to risk: full testing of critical GxP functions (audit trail completeness, access control, electronic signature behavior, calculation accuracy, and any function feeding a submission); lighter, history-supported testing of stable low-risk functions, with the reasoning documented.
4. Route any test failure through <<FILL: SOP-ID for validation test failure management>> (deviation, assessment of script error versus real defect, documented resolution) before the report can conclude.

5.7 Historical data review

1. Run a risk-based, sampled review of the data the system has already produced, sized to the risk, with a defined population and a defensible sampling basis (confidence-reliability, an AQL-style table, or a stratified plan that oversamples the riskiest windows such as an upgrade or a reduced-logging period).
2. Look for unexplained modifications or deletions, access patterns inconsistent with normal operation, calculation results that do not match a manual recalculation, gaps or signs of “testing into compliance,” and inconsistent timestamps.
3. Investigate any finding per <<FILL: SOP-ID for deviations>> and assess impact on product quality and on submissions. Finding problems is not a reason to halt; surfacing them is a main reason to do the review.
4. Record the review, including what would have constituted a finding, on <<FILL: report ID for historical / retrospective data review>>.

5.8 Disclosure assessment

1. Assess whether data from the unvalidated system reached a regulatory submission or supported a commitment in one.
2. Where it did, regulatory affairs and legal assess impact and any notification obligation; the quality team does not decide alone.
3. Where nothing was submitted, the package stays in the quality system and is presented transparently on inspection.
4. Document the assessment and its conclusion. Never backdate documents or obscure the timeline; backdating is detectable and is treated as a data integrity violation.

5.9 Return to routine control

1. Close the change history so there is a continuous controlled record rather than a cliff edge, then bring the system under routine change control per <<FILL: SOP-ID for change control>>.
2. Enroll the system in periodic review per <<FILL: SOP-ID for periodic review>> and normal operations per <<FILL: SOP-ID for computerized system operations>>.
3. Close with a validation summary report (section 8) carrying QA’s explicit conclusion that the system is fit for continued GxP use, referencing the history and disclosure section on the face of the conclusion.

6. Acceptance criteria

The remediation is acceptable when all of the following are true:

• The classification and risk assessment are documented, signed by QA, and traceable to the chosen path.
• Every protocol was approved before execution; no result was documented as executed that was not.
• The current-state IQ baseline is verified from the live system, with unverifiable values flagged.
• Critical GxP functions passed OQ in the current configuration; every deviation is resolved.
• The historical review has a defined population, a justified sample, stated criteria, findings, and an impact statement; “no adverse findings” holds only where the review was designed to detect them.
• The disclosure assessment is complete and, where submissions are involved, made cross-functionally.
• The system is under forward change control and periodic review, and QA has signed the summary report.

7. References

21 CFR 211.68 (automatic, mechanical, and electronic equipment) and 211.194 (laboratory records). 21 CFR Part 11 (electronic records and signatures), 11.10(a) validation of systems. EU GMP Annex 11 (Computerised Systems) and EudraLex Volume 4 Chapter 4 (Documentation). ICH Q9(R1), Quality Risk Management. FDA guidance, Computer Software Assurance for Production and Quality Management System Software (current version 3 February 2026), for the risk-based testing approach. ISPE GAMP 5 (Second Edition), as the recognized industry method. For medical devices and combination products: the QMSR (21 CFR Part 820, effective 2 February 2026, incorporating ISO 13485:2016 by reference).

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

8. Records generated

9. Revision history

10. Approvals

Filled specimen

The following shows the procedure applied to an example legacy chromatography data system, so you can see the level of detail expected. The company, system, and numbers are illustrative; replace them with your own.

The outcome is a validated baseline, an honest history section, one open limitation with a justification, and a system now under control. An inspector may still observe the years of uncontrolled change, but the remediation reads as competent and truthful rather than cosmetic.

Common inspection findings this SOP prevents

• Protocols or reports created after testing but dated as if executed prospectively (backdating).
• A risk assessment written to justify a predetermined scope, rating every awkward function low.
• A historical review with a token sample, no defined population, and a conclusion of “no issues” that could never have failed.
• Validating the old configuration rather than the current live state.
• Jumping to forward change control without closing the prior change history.
• A known gap identified in a prior audit that sat without remediation progress.

How to adapt this SOP

1. Set your document number, owner, and effective date in the header.
2. Point every <<FILL: SOP-ID ...>> cross-reference to your real inventory, risk assessment, change control, deviation, periodic review, and migration procedures.
3. Align the classification table in 5.2 and the acceptance criteria to your quality system’s language.
4. Name the forms and reports in section 8 that your organization uses for the risk assessment, historical review, and summary report.
5. Confirm every regulation in section 7 against the current published version before issue.