Validation Risk Assessment (Functional Risk / FMEA)

This is a ready-to-use functional risk assessment (FMEA style) for a validated computerized system. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, attach your requirements and configuration baseline, 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. Verify each cited regulation against the current source before you rely on it.

Document control header

1. Purpose

This risk assessment identifies the ways the functions of <<FILL: SYSTEM NAME>> could fail, judges how bad each failure would be, and sets the depth of verification each function gets. The output is a defensible, risk-based testing scope: high-risk functions are tested hard, low-risk functions are tested light or accepted on supplier evidence. The assessment is the bridge between requirements and the test strategy required by a risk-based validation approach.

2. Scope

This assessment covers the GxP-relevant functions of <<FILL: SYSTEM NAME>>, version <<FILL: version>>, as configured for the process at <<FILL: site / area>>. It assesses functional risk to product quality, patient safety, and data integrity (the three risk dimensions named in ICH Q9 and PIC/S PI 041). It does not cover infrastructure qualification, supplier audit conclusions, or business-continuity risk, which are governed by <<FILL: cross-reference document IDs>>. Functions with no GxP impact are listed and excluded with rationale, not silently dropped.

3. Responsibilities

4. Definitions

• Function: a discrete capability the system performs that maps to one or more requirements, for example “calculate assay result”, “enforce e-signature on approval”, “lock a record after release”.
• Failure mode: the way a function can fail, for example “calculation returns a wrong value”, “signature applied without authentication”, “released record remains editable”.
• Severity (S): how serious the effect of the failure is on product quality, patient safety, or data integrity if it reaches the patient or the record undetected.
• Occurrence (O): how likely the failure is to happen, given the system design, configuration, and how the function is used.
• Detection (D): how likely the failure is to be caught before it does harm, by a system control, a downstream check, or a human review. Higher detection score means harder to detect.
• RPN (risk priority number): S x O x D, used to rank and to set test depth.
• Risk class: a banded outcome (High / Medium / Low) derived from severity and the combined likelihood-detection, used when the team prefers a class matrix over a raw RPN. State which method governs.
• Residual risk: the risk that remains after mitigations and after testing, accepted by Quality before release.

5. Methodology

5.1 Method and standard

This assessment follows ICH Q9 (Quality Risk Management) and the GAMP risk-based approach: identify GxP functions, assess severity, likelihood, and detectability, assign a risk class or RPN, and set verification depth from the class. The method is FMEA (Failure Mode and Effects Analysis). State the governing decision rule once and apply it everywhere.

Governing decision rule for this assessment: <<FILL: state one, e.g. "Risk class is set from the Severity x (Occurrence-Detection) class matrix in 5.5; RPN is computed and recorded as a secondary tie-breaker," OR "RPN = S x O x D governs and class is read from the RPN bands in 5.6." Use one method as primary.>>

5.2 Inputs

5.3 Severity scale

Severity is judged on the worst credible effect of the failure on quality, safety, or data integrity, assuming the failure is not caught. Severity does not change because a control exists; that belongs to occurrence and detection.

5.4 Occurrence scale

Occurrence reflects how likely the failure is in this configuration and use, given software maturity, customization, and complexity.

5.5 Detection scale

Detection reflects how likely the failure is to be caught before harm, by a system control, a downstream reconciliation, or a documented human review. A higher score means harder to detect, which raises risk.

5.6 Risk class and RPN bands

RPN = S x O x D, range 1 to 125. Use the class to set test depth; record RPN to rank within a class and to break ties. A high severity (5) is treated as at least Medium risk regardless of RPN, because a rare, detectable, critical failure still warrants verification of the control that detects it.

State whether the class matrix or the RPN band governs (section 5.1) and apply it consistently. Do not move a function to a lower class by adjusting a score after the test depth is known; that is reverse-engineering the answer.

6. Risk-based test depth

The risk class drives how much verification a function gets. This is the link between this assessment and the test plan.

Every High and Medium function must trace forward to at least one test case in <<FILL: traceability matrix ID>>. A High function with no test, or a Low classification with no rationale, is the first thing an assessor will challenge.

7. Risk assessment table

List every GxP function. For each, record the failure mode, the effect, the three scores, the RPN, the risk class, the mitigation that is in place or added, and the test reference. Add rows as needed.

8. Mitigations

For every High function, and any Medium function where the team chose to reduce risk rather than only test, record the mitigation and how it changes the score. A mitigation that lowers occurrence (better design, less custom code) or improves detection (a system lock, an enforced review) is credited only when the control itself is verified.

A procedural mitigation (an SOP, a second review) is weaker than a verified system control and is challenged harder. State which mitigations are technical and which are procedural, and do not credit a procedural control as if it were an automatic system block.

9. Residual risk

After mitigation and after the planned testing, record the residual risk for every function that started High, and any Medium function that retains material risk. Residual risk is what remains, not what the score would be in a perfect world.

Any function whose residual risk remains High after mitigation and testing requires an explicit, signed acceptance with rationale, or it must be reduced before release. Quality, not the project, owns the acceptance.

10. Acceptance criteria

This risk assessment is acceptable when all of the following are true:

• Every GxP function is listed; non-GxP functions are listed and excluded with rationale.
• Severity, occurrence, and detection are scored against the defined scales, with a recorded reason for each non-obvious score.
• One governing decision rule (class matrix or RPN) is stated and applied consistently.
• Every High and Medium function traces forward to at least one test case.
• Mitigations are recorded with the score change and the verification of the control.
• Residual risk is stated for High functions and accepted by Quality before release.

11. References

ICH Q9, Quality Risk Management (the governing standard for risk-based decisions). EU GMP Annex 11 (Computerised Systems), risk management principle and lifecycle. EU GMP Annex 15 (Qualification and Validation), 2015 revision. 21 CFR Part 11 (electronic records and signatures). 21 CFR 211.68 (automatic, mechanical, and electronic equipment). FDA Computer Software Assurance for Production and Quality Management System Software (final guidance issued 3 February 2026, superseding the 24 September 2025 version). 21 CFR Part 820 (Quality Management System Regulation, QMSR), effective 2 February 2026, which incorporates ISO 13485:2016 by reference. ISO 14971, Application of risk management to medical devices (for device and combination-product contexts). PIC/S PI 041, Good Practices for Data Management and Integrity. GAMP 5 (Second Edition), ISPE, risk-based approach to compliant GxP computerized systems.

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

12. Revision history

13. Approvals

Filled specimen

The following shows the assessment table, mitigation, and residual risk completed for an example laboratory information management system supporting release testing, so you can see the level of detail an assessor expects. The company, system, and numbers are illustrative; replace them with your own. RPN bands here use the secondary RPN method (High 45 to 125, Medium 18 to 44, Low 1 to 17), with severity 5 floored to at least Medium.

Risk assessment table (specimen):

Mitigation (specimen):

Residual risk (specimen):

In this example the team scored the potency calculation and the OOS flag as High, tested them with boundary and negative cases, added a technical control plus a procedural review, recorded the score change with the verification that proved each control, and had Quality accept the residual Medium risk in writing. The cosmetic trend chart was correctly classed Low and accepted on supplier evidence rather than over-tested. That sequence, function to score to mitigation to verified control to accepted residual risk, is exactly what an assessor is expected to see.

Common inspection findings this assessment prevents

• A validation that tested everything to the same depth, with no documented risk basis for the scope.
• Risk scores assigned with no recorded rationale, so the team cannot explain why a function is Low.
• Severity lowered because a control exists, double-counting the control in both severity and detection.
• A High-risk function with no negative or boundary test, only a happy-path screenshot.
• A function dropped from the assessment as “out of scope” with no rationale and no GxP impact judgment.
• A procedural SOP credited as if it were an automatic system control, with no verification that either works.
• Scores quietly adjusted after the fact so a function lands in a lower class and gets less testing.
• Residual risk never stated, or High residual risk accepted by the project team instead of Quality.

How to adapt this assessment

1. Set your document number, owner, system, and effective date in the header, and link your URS and configuration baseline.
2. Choose one governing decision rule in section 5.1 (class matrix or RPN) and delete the wording you do not use, so reviewers cannot argue both ways.
3. Keep the S, O, and D scales as they are or recalibrate them to match your SOP, but use the same scales across all your assessments so scores are comparable.
4. Build the function list in section 7 directly from your requirements, one row per GxP function, and trace every High and Medium function to a test case.
5. Record mitigations with the score change and the verification that proves the control, and mark each as technical or procedural.
6. Have Quality, not the project, sign the residual risk in section 9 before release.
7. Confirm every regulation in section 11 against the current published version before issue.