A risk assessment is the foundation of risk-based computer system validation. It determines testing scope, documentation depth, and ongoing control requirements. Yet poorly constructed risk assessments remain one of the most common root causes of inadequate validation programs — and one of the most cited findings when inspectors look beyond the surface of a validation package.
What Inspectors Actually Look For
FDA and EMA inspectors reviewing risk assessments are asking two fundamental questions: Did the organization genuinely think about what could go wrong and how bad it would be? And did the documented controls actually address those risks? A risk assessment that scores everything as "low" without credible rationale, or that lists generic mitigations disconnected from the specific risks identified, fails both tests.
The Three-Parameter Scoring Approach
GAMP 5 and ICH Q9 both support a multi-parameter risk scoring model. The most practical approach for computer system validation uses Severity (impact of failure), Probability of Occurrence, and Detectability. The Risk Priority Number (RPN) is calculated as S × P × D, with defined thresholds for high, medium, and low risk levels that drive testing and control decisions.
Severity should be scored against patient safety, product quality, and data integrity impacts — not business inconvenience. A system that could allow incorrect drug release data to be used for batch disposition decisions is a Critical/5 severity finding. A system that generates reports with minor formatting issues is a Minor/1.
Probability should reflect realistic failure likelihood given the system's architecture, vendor quality, and deployment context — not worst-case assumptions applied uniformly.
Detectability is where many risk assessments fall short. A risk with no automated detection mechanism, no periodic review, and no user alert is genuinely undetectable (score 5). A risk with real-time automated alerting and mandatory acknowledgment is highly detectable (score 1). The difference drives significantly different control requirements.
Linking Risk to Testing
The risk assessment must explicitly connect to the test plan. Every high-risk finding should trace to specific test cases in the OQ or PQ. Inspectors look for this traceability — a risk assessment that identifies critical risks but has no corresponding test coverage is a significant finding. The Traceability Matrix is the document that makes this linkage explicit and auditable.
For medium risks, the connection to testing should still be documented but may allow for less exhaustive coverage. Low risks may be addressed through standard configuration verification or vendor-supplied documentation rather than custom test execution.
Residual Risk and Acceptance
Every risk assessment must conclude with a residual risk determination — the risk level remaining after controls are applied. The system owner and QA must formally accept residual risk before system release. This acceptance statement is what gives the validation package its regulatory closure. Without it, the risk assessment is an analytical exercise without compliance value.