This is a ready-to-use risk assessment that classifies a legacy GxP computerized system, scores its functions, and scopes the remediation. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, and route it through document control. A worked filled specimen follows the template. 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
| Field | Entry |
|---|---|
| Document title | Legacy System Classification and Remediation Risk Assessment |
| Document number | <<FILL: ID, e.g. RA-CSV-021-01>> |
| Version | <<FILL: version>> |
| Effective / assessment date | <<FILL: date>> |
| Governing SOP | <<FILL: SOP-ID for retrospective validation>> |
| System assessed | <<FILL: SYSTEM NAME / ID>> |
| Assessment owner | <<FILL: role, e.g. CSV Lead>> |
1. Methodology
This assessment is performed in two parts. Part A classifies the system’s condition to select a remediation path. Part B scores each GxP function of the system so that testing depth and the extent of the historical data review are tied to consequence rather than set arbitrarily. The method aligns with ICH Q9(R1) quality risk management and the risk-based testing approach of the current FDA Computer Software Assurance guidance. Severity is weighted most heavily because it is the patient-facing dimension. Participants and their functions are named so the judgment is traceable.
Assessment team: <<FILL: names and roles: system owner, CSV lead, QA, IT, data integrity SME>>.
2. System description and use
| Field | Entry |
|---|---|
| System / application | <<FILL>> |
| Version(s) in use | <<FILL>> |
| GxP process supported | <<FILL>> |
| Data generated | <<FILL>> |
| GxP decisions the data feeds | <<FILL: release, OOS, stability, submission, DHR, etc.>> |
| Date entered GxP use | <<FILL>> |
| Prior validation (if any) | <<FILL: none / date and scope>> |
| Data used in a regulatory submission | Yes / No, <<FILL: which>> |
Part A: Classification
3. Classification determination
Mark each condition from the live evidence, then read the resulting scenario.
| Condition | Evidence | Yes / No |
|---|---|---|
| Validation documentation exists and reflects the current configuration | <<FILL>> | <<FILL>> |
| System has run under formal change control | <<FILL>> | <<FILL>> |
| Configuration history is known and reconstructable | <<FILL>> | <<FILL>> |
| Individual authentication and an audit trail are present and were enabled | <<FILL>> | <<FILL>> |
| Data has been reviewed by QA before use, with training records for users | <<FILL>> | <<FILL>> |
| Scenario | Pattern | Path |
|---|---|---|
| A | No validation docs, but controlled operation (change control, stable config, reviewed data, trained users) | Retrospective validation, documentation-led |
| B | Validated once, but outdated and the system has changed without control | Retrospective validation, baseline-led |
| C | Never validated, unknown configuration history, no evidence of controlled operation | Replacement, or remediate then replace |
Assigned classification: <<FILL: A / B / C>>. Rationale: <<FILL: two or three sentences tying the evidence to the scenario>>.
Part B: Function-level risk scoring
4. Scoring scales
Score each GxP function on the three scales below. Risk priority is read from the combination, with severity dominant.
Severity (S), the consequence if the function errs:
| Score | Meaning |
|---|---|
| 5 | Directly wrong release, safety, or submission decision possible |
| 4 | Significant quality-decision impact, likely caught downstream |
| 3 | Moderate impact, contained within the process |
| 2 | Minor impact, no decision effect |
| 1 | Negligible, informational only |
Probability (P), the chance of an error occurring:
| Score | Meaning |
|---|---|
| 5 | Frequent; weak or no preventive control |
| 3 | Occasional; partial control |
| 1 | Rare; strong preventive control and stable history |
Detectability (D), how hard an error is to detect before it causes harm (higher = harder):
| Score | Meaning |
|---|---|
| 5 | Would not be detected by any existing check |
| 3 | Detectable by routine review |
| 1 | Detected immediately by an automated or independent check |
Risk priority: High if S is 4 or 5 and either P or D is 3 or higher; Medium if S is 3, or S is 4 or 5 with strong control (P and D both low); Low if S is 1 or 2. Testing depth follows the priority.
5. Function risk table
| GxP function | S | P | D | Risk priority | Testing depth / historical-review weight |
|---|---|---|---|---|---|
<<FILL: function>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
<<FILL: function>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
<<FILL: function>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
6. Data integrity controls actually present now
| Control | Present? | Notes |
|---|---|---|
| Audit trail enabled and complete | <<FILL>> | <<FILL>> |
| Individual (non-shared) authentication | <<FILL>> | <<FILL>> |
| Role-based access, admin segregated | <<FILL>> | <<FILL>> |
| Backup and verified restore | <<FILL>> | <<FILL>> |
| Time source controlled | <<FILL>> | <<FILL>> |
7. Remediation-path decision and residual risk
Path chosen: <<FILL: retrospective validation (doc-led / baseline-led) / replacement / remediate-then-replace>>.
Replacement is indicated when any of these holds: the production version cannot be qualified because vendor support and testing evidence are gone; the design cannot support required GxP controls and cannot be upgraded; the historical integrity picture cannot be characterized because no audit trail was kept; or lifetime remediation cost exceeds a modern replacement.
| Item | Entry |
|---|---|
| Interim controls during remediation | <<FILL: enhanced review, tightened access, second-person verification>> |
| Residual risk after remediation | <<FILL: statement, including any open limitation>> |
| Historical data review required? | Yes / No, <<FILL: population and sampling basis>> |
| Disclosure assessment required? | Yes / No, <<FILL: submission exposure>> |
8. References
ICH Q9(R1), Quality Risk Management. 21 CFR Part 11 (11.10(a) validation) and 21 CFR 211.68, 211.194. EU GMP Annex 11 (Computerised Systems). FDA guidance, Computer Software Assurance for Production and Quality Management System Software (current version 3 February 2026), for risk-graded testing. ISPE GAMP 5 (Second Edition).
Confirm the current version and clause numbers of each reference before issue.
9. Approval
| Role | Name | Signature | Date |
|---|---|---|---|
| Assessment owner (CSV) | <<FILL>> | ||
| System owner | <<FILL>> | ||
| Quality Assurance | <<FILL>> |
Filled specimen
Illustrative, for a legacy quality control chromatography data system feeding release and a stability submission.
System: CDS-03, chromatography data system, versions upgraded twice since a 2014 validation; a server migration in 2019, none under formal change control.
Part A classification: Scenario B. Validation docs exist but describe an earlier version; change control lapsed; configuration partly known; individual authentication and audit trail present. Path: retrospective validation, baseline-led.
Part B function scoring:
| GxP function | S | P | D | Risk priority | Testing depth / review weight |
|---|---|---|---|---|---|
| Peak integration and result calculation | 5 | 3 | 4 | High | Full OQ; manual recalculation of a sampled set; heavy in historical review |
| Audit-trail completeness | 5 | 3 | 5 | High | Full OQ; provoke and review entries; examine the reduced-logging window closely |
| Electronic signature binding | 4 | 2 | 4 | High | Full OQ; signature manifestation tested |
| Access control and roles | 4 | 2 | 3 | Medium | Targeted OQ; role matrix verified |
| Report header formatting | 1 | 2 | 1 | Low | Light verification, history-supported |
Controls present: audit trail enabled at full detail only from the second upgrade (gap noted); individual authentication yes; role-based access yes; backup with an untested restore (flagged).
Path decision: retrospective validation, baseline-led. Design supports required controls, so replacement is not warranted. Interim control: second-person review of release results until the OQ is complete. Historical review required, population all release results over the period of concern, stratified to oversample the reduced-logging window. Disclosure assessment required because stability data reached a submission.
The assessment produces high-risk findings for a system that feeds release, which is what a genuine assessment should do; a legacy risk assessment that finds nothing high risk for a release-critical system is the classic tell of scope written to a predetermined answer.
Common inspection findings this assessment prevents
- A risk assessment that rates every awkward function low so the testing scope stays small.
- Classification asserted without evidence, so the chosen path cannot be defended.
- Testing depth set flat across all functions with no link to consequence.
- No record of the data integrity controls actually present, so the historical-review scope is guesswork.
- A replacement-versus-remediation decision made on cost alone, ignoring whether the past can be reconstructed.
How to adapt this assessment
- Set your document number and point the governing SOP field to your retrospective validation procedure.
- Keep or adjust the S/P/D scales to match your quality system’s risk model, but keep severity dominant.
- List the real GxP functions of the system under assessment; do not reuse the specimen’s functions blindly.
- Record the controls actually present from the live system, verified, not assumed.
- Confirm every regulation in section 8 against the current published version before issue.