GAMP 5 Risk Assessment:
How to Score and Justify
Your Validation Scope

Why Risk Assessment Drives Everything in GAMP 5

GAMP 5 is fundamentally a risk-based framework. The risk assessment is not a compliance checkbox — it is the document that justifies the level of validation effort applied to your system. Done correctly, it allows you to focus testing where it matters most and defend a lighter approach on low-risk functions. Done incorrectly, it either over-burdens the project or leaves critical gaps exposed in an audit.

The risk assessment should be completed early in the project — after the URS is drafted, before the test protocols are written — because the risk scores directly influence how many test cases each requirement needs and how much evidence the OQ must generate.

The Risk Scoring Model

GAMP 5 uses a risk matrix based on two factors: Probability (how likely is the failure?) and Impact (if it fails, how bad is it?). Some organisations add a third factor: Detectability (how likely is the failure to be detected before it causes harm?). The product of these scores gives a Risk Priority Number (RPN).

What to Include in the Risk Assessment

The risk assessment covers every function and requirement in the URS. Each row in the risk assessment register corresponds to one URS requirement or one system function. The columns are: Function/Requirement, Failure Mode, Effect of Failure, Probability (1–3), Impact (1–3), RPN, Risk Level, and Mitigating Controls.

The "Effect of Failure" column is the most important. It is what justifies the Impact score. The question to ask is: if this function fails silently without detection, what is the worst credible outcome? For a temperature control function in a biological manufacturing process, the answer is product loss and potential patient harm — Impact 3, Critical. For a report formatting function, the answer is an inconvenient document — Impact 1, Low.

Thinking Through Failure Modes

A common weakness in risk assessments is vague failure modes: "Function fails" or "Data not recorded." Useful failure modes are specific:

• "Temperature alarm fails to activate when process exceeds critical limit" — not just "alarm failure"
• "Audit trail entry not generated for setpoint change made during network outage"
• "Recipe parameter modified without audit trail entry due to admin bypass"
• "Historian data gap occurs after UPS switchover due to buffer overflow"

Specific failure modes lead to specific mitigating controls, which lead to specific OQ test cases. Vague failure modes lead to vague test cases that don't actually verify anything useful.

Mitigating Controls and Residual Risk

After scoring the initial risk, you document the mitigating controls — the design features or procedural controls that reduce probability or impact. After applying controls, you re-score to get the residual risk. The residual risk must be acceptable before the system can be released.

Crucially, the OQ test cases are themselves mitigating controls. A critical function with a high impact failure mode is mitigated by a comprehensive OQ that verifies the protection mechanisms work. If the OQ test passes, residual risk drops. If it fails, you have a deviation — which is the system working correctly.