SOP: Risk-Based Computer System Validation Scoping

This is a ready-to-use SOP for deciding how much validation a computerized system needs, before any protocol is written. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, and route it through your document control. A worked filled specimen follows the template. Verify each cited regulation against the current source before you rely on it.

Document control header

1. Purpose

This procedure defines how <<FILL: COMPANY NAME>> determines the validation effort a computerized system requires, so that testing and documentation are proportionate to the risk the system poses to patient safety, product quality, and data integrity. The objective is a defensible, traceable link from what a system does to how it was tested, with no over-validation of low-risk functions and no under-validation of the functions that matter.

2. Scope

This procedure applies to all GxP computerized systems and to configured or custom functions within them, at the sites listed in the header. It covers new systems, major changes to validated systems, and the periodic re-look at accepted risk. It does not itself execute testing; the testing approach it selects is executed under the applicable validation protocol procedure, <<FILL: SOP-ID for protocols>>, and change is governed by <<FILL: SOP-ID for change control>>.

3. Responsibilities

4. Definitions

• GxP function: a system function that creates, changes, or controls data or a process used to make a GxP decision, or that maintains a regulated record.
• GAMP category: the GAMP 5 software classification (1 infrastructure, 3 non-configured, 4 configured, 5 custom) that sets the baseline validation posture. Category 2 is retired.
• Severity (S), Occurrence (O), Detectability (D): the three FMEA axes; their product is the Risk Priority Number (RPN).
• Severity gate: a rule that any high-severity function receives rigorous testing regardless of RPN.
• Residual risk: the risk that remains after controls are applied; it is re-rated and formally accepted.

5. Procedure

5.1 Determine GxP applicability

1. Answer, for the system, whether it creates or processes GxP-decision data, controls a quality-critical process, generates regulated records, or feeds a regulatory submission.
2. If every answer is no, record “not GxP” with a short rationale and stop; no pharmaceutical validation is required.
3. If any answer is yes, record the in-scope boundary (which modules and uses are GxP, which are not). Capture this on the GxP determination record, section 8.1.

5.2 Assign the GAMP category

1. Assign the GAMP 5 category (1, 3, 4, or 5) for the system as a whole, with a one-line rationale.
2. Identify any custom elements embedded in a configured platform (custom calculations, bespoke integrations, scripted workflows) and assign them Category 5 individually.
3. Record the category and any embedded-custom split on the categorization worksheet, section 8.2. The category informs the occurrence score; it is not scored as a second risk axis.

5.3 Identify GxP-critical functions

1. Drive the function list from the user requirements, not a feature tour of the software.
2. Rate each function’s criticality (High / Low / None) by whether it affects release or disposition decisions, patient safety, record integrity, or a critical quality attribute or process parameter.
3. Name out-of-scope functions and justify them; do not silently omit them. Record on the criticality matrix, section 8.3.

5.4 Score the risk

1. For each High-criticality function, name a specific failure mode, its effect, and score Severity, Occurrence, and Detectability against the anchor tables in this SOP (section 6). Use one scale throughout; never mix a 1-5 and a 1-10 scale.
2. Compute RPN (S x O x D). Where functions do not decompose into discrete failure modes, use risk ranking and filtering with weighted factors instead, and record why.
3. Write a one-line reason for every score. An unexplained number is not acceptable.

5.5 Select the testing approach

1. Convert each score to a testing approach using the rule in section 6.3. Apply the severity gate: any Severity 4 or 5 function receives scripted testing with documented expected results, including a negative test where detectability is high, regardless of RPN.
2. Record the approach per function so it traces, row by row, to the protocols.

5.6 Decide vendor-evidence reliance

1. For any function you intend to cover with vendor evidence rather than site testing, confirm the vendor’s quality system, development testing, and documentation actually cover the function for your configuration.
2. Record the reliance decision and its basis, or record that site testing is required because the vendor evidence is insufficient. The supplier is accountable for the product as built; the site remains accountable for the system as configured and used.

5.7 Control residual risk and obtain acceptance

1. Apply controls (testing, configuration, procedural, monitoring), re-rate the residual risk, and record it.
2. Route any high residual risk for Quality acceptance with a named owner and, where applicable, a committed remediation. Do not score residual risk down to look acceptable.

5.8 Approve before protocols

1. The author and Quality Assurance sign the assessment before validation protocols are finalized, because the protocols flow from it.
2. Re-open the assessment, scoped to the change, whenever the system changes or a new critical function emerges. It is a living document.

6. Acceptance criteria and scoring scales

6.1 Severity, occurrence, detectability anchors

6.2 Assessment acceptance criteria

A completed assessment is acceptable when all are true:

• Every in-scope function has a criticality rating with a one-line rationale, and out-of-scope items are named and justified.
• The GAMP category is assigned and any embedded custom elements are called out with their own category.
• Scoring scales are defined and used consistently; no mixed scales, no unanchored numbers.
• Every Severity 4 or 5 function has a scripted test, including a negative test where detectability is low.
• The testing-approach column traces row by row to real protocol test cases.
• Residual risk is re-rated, and any high residual risk is accepted by Quality with a named owner.
• The assessment is signed by the author and Quality before protocol execution begins.

6.3 Score-to-testing rule

7. References

21 CFR Part 11 (electronic records and signatures). 21 CFR 211.68 (automatic, mechanical, and electronic equipment). EU GMP Annex 11 (computerised systems); a draft revision was issued for consultation on 7 July 2025 and is not in force, confirm the current status before citing it. FDA guidance, Computer Software Assurance for Production and Quality Management System Software. ISPE GAMP 5, A Risk-Based Approach to Compliant GxP Computerized Systems (Second Edition). ICH Q9(R1), Quality Risk Management.

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

8. Records generated

8.1 GxP determination record

8.2 GAMP categorization

8.3 Function criticality and FMEA summary

8.4 Residual-risk acceptance

9. Revision history

10. Approvals

Filled specimen

The following shows the assessment completed for an example laboratory information management system (LIMS) supporting release testing. The company, system, and numbers are illustrative; replace them with your own.

GxP determination

GAMP categorization: Overall Category 4 (configured platform). Embedded Category 5 element: a custom stability-trend calculation. Rationale: standard vendor platform configured for site use; one bespoke calculation authored on site.

Function criticality and FMEA summary (excerpt)

Residual-risk acceptance (excerpt)

In this example the custom calculation, initially the joint-highest risk, was reduced by code review and by locking the logic against user edits, then accepted at a low residual by QA. The audit trail row, despite a moderate RPN, drew scripted testing with a negative test purely on the severity-plus-low-detectability signal. That is the method working: effort followed the risk, not the RPN alone.

Common inspection findings this SOP prevents

• Every function rated High and scripted, so no real risk decision is visible (a flat matrix).
• Audit trail or access control rated Low because “we trust the vendor,” when both are direct Part 11 and Annex 11 requirements.
• Scores with no written reason, reverse-engineered to justify a predetermined scope.
• A custom calculation inside a “configured” system that never received custom-software scrutiny.
• A testing scope in the protocols that does not match the risk assessment.
• Residual risk never re-rated or accepted, so a known high risk went live with no signed decision.

How to adapt this SOP

1. Set your document number, owner, and effective date in the header.
2. Point the cross-references in section 2 to your real protocol and change-control procedures.
3. Confirm the scoring anchors in section 6.1 match the scale your quality risk management procedure uses, so CSV assessments and process risk assessments read consistently.
4. If you use risk ranking and filtering for some systems, add your weighted factors and filter line to section 6.
5. Confirm every regulation in section 7 against the current published version before issue.