Risk Assessment Is Not a Compliance Box — It Determines Your Validation Depth | GMP Computerized System Validation

Walk into any pharma plant during a GMP inspection and you will see the same scene. An inspector opens a validation package. The risk assessment is there, beautifully formatted. Version-controlled cover page. Three neat chapters: risk identification, risk analysis, risk control. Every item scored for probability, severity, and detectability. RPN values calculated, sorted high to low. Control measures listed. A confident conclusion at the bottom: “All risks are acceptable after controls are applied.”

On paper, it is a perfect document.

Then the inspector asks one question: “The risk of audit trail being disabled — what RPN did you assign to that?”

The answer: Probability 2, Severity 3, Detectability 2. RPN = 12. Low risk. Control measure: an SOP prohibiting the disabling of audit trails.

Follow-up: “Your system admin account can disable audit trails directly in the backend, with no record left behind. How does an SOP control that risk?”

Silence.

This gap between what risk assessment looks like and what it actually accomplishes is more common in pharma than most teams want to admit. And it matters, because regulators are not fooled by pretty formats.

Where Risk Assessment Really Belongs in Validation

A lot of teams treat risk assessment as a document inside a validation package. Validation gets done, a risk assessment gets drafted alongside it, the binder goes on the shelf, and the compliance checklist is ticked.

This understanding is fundamentally backward.

Risk assessment is not an accessory to validation. It is the commander of validation. Its job is to answer one question: For this system, what needs to be validated, and to what depth? And equally important: what can be simplified, and why?

Without a risk assessment leading the way, validation has no direction. Teams either test everything — burning enormous resources on low-value scenarios — or they copy someone else’s template and miss the real risks.

Annex 11 and China’s GMP Annex on Computerized Systems say this plainly: the scope and extent of validation shall be determined based on a documented risk assessment. That is not a suggestion. It is cause and effect. The risk assessment drives the validation protocol — what to test, how to test it, and how deeply.

How Inspectors Tell Real Risk Assessment from Paperwork

Inspectors do not judge a risk assessment by its formatting or its RPN table. They look at three things.

First: Does it cover GMP-specific scenarios?

A generic IT risk assessment will flag system downtime, network security, data loss. Those are valid but not enough.

GMP-computerized systems carry a unique category of risk: data integrity risks. Inspectors want to see whether the assessment asks questions like:

• Can raw data be modified without leaving a trace?
• Can the audit trail be disabled — intentionally or accidentally?
• Can the system clock be adjusted to falsify operation timestamps?
• Can electronic signatures be bypassed or shared?
• Is there integrity verification for data transfers between instruments and systems?

These risks do not show up in standard IT risk frameworks. If a LIMS risk assessment is missing these, it means the person who wrote it either does not understand GMP data integrity, or never thought about what an inspector would ask.

Second: Are the risk controls actually tested?

This is the most direct test of whether a risk assessment was real.

Take every control measure from the risk assessment. Go find the corresponding test scenario in the validation protocol. If you cannot find it, the risk assessment and the validation protocol were produced by two different teams with no real connection.

If a control measure says “the system requires mandatory dual-person review,” the validation script should test: Can a single operator skip the review? What happens when the review is bypassed? Is the interception recorded and traceable?

A control measure without a test is just words on a page.

Third: Has the risk assessment been updated?

After a system goes live, changes happen. A new module is added. The database version is upgraded. Permissions are restructured. Did the risk assessment get reviewed too?

In too many facilities, the risk assessment was done once at initial validation and never touched again. But risk is not static. A feature rated low risk three years ago, with no external dependencies, may be high risk today after connecting to a new interface.

A risk assessment that is never updated is not a risk assessment of the current system. It is a historical artifact.

RPN Scoring: Useful, but Not in the Way Most People Think

The FMEA scoring method (Probability × Severity × Detectability = RPN) is widely used in computerized system risk assessments. It is also widely misused.

The most common misuse is treating the RPN number as the sole determinant of risk level, then adjusting scores to produce the desired outcome.

Consider a risk where probability is scored 1, severity is scored 3, and detectability is scored 2. RPN = 6. Low risk. Simplified validation.

But if that risk materializes as falsified test data that leads to releasing non-conforming product — does severity truly deserve a 3?

The subjectivity of scoring is an inherent limitation of FMEA. Inspectors do not just look at the number. They look at whether the rationale behind each score holds up.

Why is probability low? Because there is access control. But has that access control itself been validated? If the control measure used to justify a low probability score has not been proven effective, the logic is circular.

An effective risk assessment thinks through these questions before scoring. The scoring is just a structured way to present the conclusion — not a substitute for thinking.

How Risk Assessment Determines Validation Depth

A practical framework:

High-risk functions: Full validation. Positive and negative testing both required. Negative testing means deliberately trying to make the system fail — can unauthorized operations be intercepted? How does the system respond to out-of-range inputs? Is data lost during a network interruption? These tests can be simplified for low-risk systems but are mandatory for high-risk functions.

Medium-risk functions: Validate the core path. Test critical parameter boundaries. Not every scenario needs coverage, but the main flow must work end-to-end, and the complete chain of critical data — write, store, read, modify — must be tested.

Low-risk functions: Vendor test documentation can be leveraged, with spot-check validation by the enterprise. But “low risk” must be justified. A function is not low risk just because it seems simple. The rationale must explain why it presents low risk specifically in a GMP context.

The logic: concentrate limited validation resources where they matter most. That is what risk assessment is for.

The Most Commonly Underestimated Risk: System Integration Interfaces

When validation teams evaluate individual systems, they typically do a reasonable job. But when two systems are connected through a data interface, the interface becomes a blind spot.

Take an interface between ERP and LIMS, where material data is pushed from ERP to LIMS. Questions that need asking:

• Is data transfer real-time or batch-synchronized?
• Does a transfer failure trigger an alert and a retry?
• Is there a reconciliation mechanism to detect discrepancies between the two systems?
• Are configuration changes to the interface logged with version control?

These questions appear in neither system’s risk assessment. In the ERP assessment, they belong to “the LIMS side.” In the LIMS assessment, they belong to “the ERP side.”

The interface falls between two chairs.

The consequence? An inspector finds one version of the data in ERP and a different version in LIMS. No one can explain which is correct, or when the discrepancy appeared.

The Bottom Line

A properly executed risk assessment is the eyes of the entire validation system. It tells you where to look.

A poorly executed risk assessment is the fig leaf of validation — covering up the fact that risk was never genuinely thought through.

Inspectors can tell the difference immediately. Not because they have special powers, but because a risk assessment that was truly done, and one that was filled out as a procedural exercise, have completely different textures in their details.

One reveals thinking. The other reveals its absence.

The choice of which kind your team produces is not a documentation preference. It is a compliance decision with real consequences for product quality and patient safety.