How to Perform Quality Risk Assessment in Pharma Qualification.

Part 5

The central principle is:

Risk assessment should determine what needs to be tested, why it needs testing, how extensively it should be tested, and where suitable supplier, FAT, SAT, commissioning, or engineering evidence may be leveraged.


5.1 Introduction

Quality Risk Management (QRM) is fundamental to modern pharmaceutical qualification.

Qualification should not apply the same test depth to every:

  • component;
  • function;
  • alarm;
  • instrument;
  • operating parameter;
  • software feature;
  • utility;
  • design characteristic.

Instead, qualification effort should be proportional to:

  1. intended use;
  2. potential GMP impact;
  3. potential failure modes;
  4. consequences of failure;
  5. existing controls;
  6. uncertainty and system/process knowledge;
  7. ability to detect or prevent failure;
  8. residual risk.

A strong risk assessment converts the information developed in Parts 3 and 4 into a practical verification strategy:

URS

GMP/System Impact

Failure Modes

Quality Risk

Critical Aspects

Risk Controls

Verification Requirements

FAT / SAT / IQ / OQ / PQ

Residual Risk

Qualified State


5.2 What Is Quality Risk Management?

Quality Risk Management is a systematic process for:

  • assessing;
  • controlling;
  • communicating; and
  • reviewing

risks to product quality across the lifecycle.

Within qualification, QRM helps determine whether the facility, utility, equipment, or system contains functions whose failure could adversely affect:

  • product quality;
  • patient safety;
  • process control;
  • CPPs;
  • CQAs;
  • contamination control;
  • GMP records;
  • electronic records;
  • data integrity.

5.3 ICH Q9(R1) Principles

The master prompt specifically requires application of ICH Q9(R1).

Two foundational QRM principles are particularly important for qualification:

Evaluation of risk to quality should be based on scientific knowledge and ultimately link to protection of the patient.

and, conceptually:

The level of effort, formality, and documentation applied to QRM should be commensurate with the level of risk.

This does not mean that every qualification activity requires a highly complex FMEA.

The formality of risk management should itself be proportionate to the situation.


5.4 Why Risk Assessment Is Required in Qualification

Without risk assessment, qualification can become:

Template → Test Everything → Generate Documents → Obtain Signatures

This approach often creates large protocols but weak scientific assurance.

A risk-based approach asks:

What could fail?

Why does it matter?

What prevents or detects the failure?

Which failures require qualification testing?

What should be challenged?

What evidence already exists?

What residual risk remains after controls?

This makes qualification scientifically defensible.


5.5 Position of Risk Assessment in the Lifecycle

Risk assessment is not simply performed once before IQ.

It can occur throughout the lifecycle.

Concept / Requirements

Initial risk identification

Design

Design risk assessment

FAT

Testing based on design risks

SAT / Commissioning

Site-related risks

IQ/OQ/PQ

Verification of risk controls

GMP Release

Residual-risk assessment

Routine Operation

Operational risk monitoring

Change Control

Change-specific risk assessment

Requalification

Reassessment of affected risks

Retirement

Data/product/system retirement risks

Risk management is therefore a lifecycle activity.


5.6 Relationship Between Impact Assessment and Risk Assessment

These should not be confused.

Impact Assessment

Asks:

Can this system/function affect GMP operations or product quality?

Risk Assessment

Asks:

How can it fail, what happens if it fails, what controls exist, and what verification is necessary?

Example — Compression Machine

Impact assessment:

Tablet reject mechanism affects product disposition.

Risk assessment:

Failure mode: Reject mechanism fails to remove a tablet designated for rejection.

Potential effect: Nonconforming tablet may enter the accepted-product stream.

Control: Reject logic, physical rejection mechanism and associated monitoring/confirmation where designed.

Qualification: Challenge defined reject conditions during FAT/OQ as appropriate.


5.7 Quality Risk Management Lifecycle

A practical lifecycle is:

             RISK IDENTIFICATION
                     ↓
               RISK ANALYSIS
                     ↓
              RISK EVALUATION
                     ↓
                RISK CONTROL
               ↙           ↘
      RISK REDUCTION     RISK ACCEPTANCE
               \           /
                     ↓
             VERIFICATION
                     ↓
               RISK REVIEW
                     ↓
         LIFECYCLE MONITORING

Risk communication occurs throughout this process.


5.8 Step 1 — Risk Identification

Risk identification asks:

What can go wrong?

The team should identify credible failure modes associated with the intended use.

Potential sources include:

  • URS;
  • process knowledge;
  • equipment design;
  • historical deviations;
  • vendor experience;
  • previous qualification;
  • similar equipment;
  • process FMEA;
  • engineering review;
  • regulatory knowledge.

5.9 Examples of Failure Modes

For a tablet compression machine:

  • incorrect compression force;
  • unstable feeder operation;
  • incorrect turret speed;
  • incorrect tablet-weight control;
  • reject mechanism failure;
  • guard interlock failure;
  • incorrect recipe loaded;
  • unauthorized recipe modification;
  • critical alarm failure;
  • sensor failure;
  • power-recovery failure;
  • loss of GMP data.

Each credible failure mode can then be evaluated.


5.10 Risk Identification vs Hazard Identification

It is useful to distinguish:

Hazard

A potential source of harm.

Failure mode

The way a component/function may fail.

Effect

What happens because of the failure.

Risk

The combination of factors used to evaluate the significance of the potential harm/failure within the selected methodology.

For qualification, FMEA is often convenient because it focuses on:

Function → Failure Mode → Effect → Cause → Controls → Risk


5.11 Step 2 — Risk Analysis

Risk analysis evaluates identified risks.

A common pharmaceutical FMEA considers:

  • Severity (S);
  • Occurrence (O);
  • Detectability (D).

Some organizations use other approaches.

The methodology should be defined before the assessment.


5.12 Severity

Severity evaluates the seriousness of the consequence if the failure occurs.

A sample scale is:

ScoreExample Interpretation
1Negligible GMP/product impact
2Minor impact, readily controlled
3Moderate quality/GMP impact
4Major product/GMP impact
5Potential critical product/patient/compliance impact

The exact definitions should be defined in the company’s approved QRM procedure.


5.13 Severity Example

Consider failure of a compression-machine reject system.

If the failure could allow tablets already identified as nonconforming to enter the accepted stream, the severity may be significant.

The team should not simply assign:

Severity = 5

because the function “sounds critical.”

The rationale should explain the potential quality consequence.


5.14 Occurrence

Occurrence estimates the likelihood or frequency of the failure.

Example scale:

ScoreExample Interpretation
1Remote
2Low
3Occasional
4Probable
5Frequent

Occurrence should be based where possible on evidence such as:

  • historical performance;
  • equipment reliability;
  • supplier data;
  • deviation history;
  • process knowledge;
  • engineering experience.

5.15 Detectability

Detectability considers the ability of existing controls to detect the failure before it causes an unacceptable consequence.

Example:

ScoreExample Interpretation
1Failure almost certainly detected
2High likelihood of detection
3Moderate detectability
4Low detectability
5Failure unlikely to be detected

The direction of scoring must be clearly defined.

In this example:

Higher D = poorer detectability.


5.16 Risk Priority Number — RPN

A traditional FMEA may calculate:

[
RPN = S \times O \times D
]

Example:

Severity = 5

Occurrence = 2

Detectability = 3

Therefore:

[
RPN = 5 \times 2 \times 3 = 30
]

The resulting RPN can support prioritization.

But it should not become the sole decision criterion.


5.17 Limitations of RPN

RPN has important limitations.

Different combinations can generate the same number.

For example:

5 × 2 × 2 = 20

and

2 × 5 × 2 = 20

The numerical RPN is identical, but the first scenario has much higher severity.

Therefore:

A low or moderate RPN should not automatically make a high-severity failure acceptable.


5.18 Avoid Mechanical RPN Thresholds

A weak procedure may state:

RPN below 20 = No action.

RPN 20–40 = Medium.

RPN above 40 = Qualification required.

This can create misleading decisions.

A more mature assessment considers:

  • severity independently;
  • uncertainty;
  • detectability;
  • existing controls;
  • GMP significance;
  • patient/product consequences;
  • system complexity.

Numerical scoring should support scientific judgment, not replace it.


5.19 Risk Matrix Alternative

Some organizations use:

Probability × Severity

Example:

Probability ↓ / Severity →LowModerateHighCritical
RemoteLowLowMediumHigh
UnlikelyLowMediumHighHigh
PossibleMediumHighHighVery High
LikelyHighHighVery HighVery High

The exact matrix should be defined by the company’s QRM methodology.


5.20 Step 3 — Risk Evaluation

Risk evaluation determines whether identified risk is:

  • acceptable;
  • requires additional control;
  • requires further investigation;
  • requires design modification;
  • requires qualification testing;
  • cannot be accepted.

The team should compare the estimated risk against predefined decision criteria while applying scientific judgment.


5.21 Step 4 — Risk Control

Risk control answers:

What will we do about the risk?

Controls generally fall into two categories:

Risk Reduction

Actions that reduce:

  • probability;
  • severity where technically possible;
  • or improve detectability.

Risk Acceptance

Formal acceptance of residual risk when appropriately justified.


5.22 Hierarchy of Risk Controls

Where possible, risk should preferably be controlled through robust design rather than relying solely on detection.

A useful hierarchy is:

Eliminate the hazard/failure opportunity

Design control

Automated prevention/interlock

Automated detection/alarm

Procedural control

Operator detection

The appropriate hierarchy depends on the specific system and risk.


5.23 Example — Incorrect Recipe Selection

Failure Mode

Wrong product recipe selected.

Potential Effect

Incorrect process parameters applied.

Potential Controls

  • unique recipe identification;
  • role-based permissions;
  • controlled recipe approval;
  • product/recipe verification;
  • parameter limits;
  • audit trail where applicable.

Qualification

OQ may challenge:

  • recipe creation permissions;
  • recipe selection;
  • modification restrictions;
  • approved parameter limits;
  • audit-trail generation where applicable.

5.24 Risk Reduction Should Influence Design

Risk assessment should occur early enough to improve design.

Weak sequence:

Design Complete → Equipment Delivered → Risk Assessment → Discover Design Problem

Preferred sequence:

URS → Impact Assessment → Risk Assessment → Design Control → DQ → FAT

This allows risk reduction before installation.


5.25 Step 5 — Risk Review

Risk should be reviewed when new knowledge becomes available.

Triggers include:

  • qualification failures;
  • deviations;
  • recurring alarms;
  • maintenance problems;
  • calibration failures;
  • process changes;
  • software upgrades;
  • regulatory observations;
  • new product introduction;
  • adverse trends.

The original risk assessment should not be considered permanently correct.


5.26 Formal vs Informal Risk Management

Not every qualification decision requires a 30-page FMEA.

The degree of formality should reflect:

  • uncertainty;
  • importance;
  • complexity;
  • novelty;
  • potential impact.

Lower-risk example

Replacement of a non-critical equipment cover with an equivalent part may require a documented technical/change assessment rather than a full FMEA.

Higher-risk example

Replacement of a PLC controlling:

  • recipes;
  • CPPs;
  • alarms;
  • electronic records

may require a formal multidisciplinary risk assessment.


5.27 Common QRM Tools

Possible tools include:

  • FMEA;
  • FMECA;
  • HACCP;
  • Fault Tree Analysis;
  • risk ranking/filtering;
  • preliminary hazard analysis;
  • process mapping;
  • cause-and-effect analysis;
  • structured expert assessment.

For equipment qualification, FMEA is particularly common because it maps functions and failures effectively.


5.28 Failure Mode and Effects Analysis — FMEA

A practical FMEA structure is:

FieldQuestion
FunctionWhat should it do?
Failure ModeHow could it fail?
EffectWhat happens?
CauseWhy might it fail?
Existing ControlWhat prevents/detects it?
SeverityHow serious?
OccurrenceHow likely?
DetectabilityHow detectable?
Risk RatingWhat is the resulting risk?
ActionWhat additional control is needed?
VerificationWhere will it be tested?
Residual RiskIs remaining risk acceptable?

5.29 Practical FMEA — Tablet Compression Machine

FunctionFailure ModePotential EffectExisting/Proposed ControlSODRPNQualification Action
Main compressionIncorrect force controlTablet quality affectedForce monitoring/control52220OQ challenge
Turret speedIncorrect speedProcess performance affectedSpeed feedback/control42216OQ range test
FeederFeeder fails/stallsWeight/content variability risk depending on processAlarm/monitoring42216OQ functional challenge
Reject systemReject failsNonconforming tablet may remainReject control/confirmation52330FAT + OQ challenge
RecipeWrong recipe loadedIncorrect parametersAccess/recipe controls52330OQ/CSV
GuardInterlock failsSafety/control riskSafety circuit42216FAT + OQ
GMP dataData not retainedLoss of evidence/traceabilityStorage/backup controls42324OQ/CSV

Important: These numerical scores are illustrative only. They are not universal pharmaceutical acceptance criteria.


5.30 Add Risk Rationale to the FMEA

A stronger FMEA contains written rationale rather than scores alone.

For example:

Severity = 5

Rationale: Failure of the reject mechanism could allow a tablet already identified as unacceptable to remain in the accepted product stream.

Occurrence = 2

Rationale: Mechanism is established technology with continuous automated control and no significant failure history from equivalent systems.

Detectability = 3

Rationale: Failure may be detected by the control system where confirmation is available, but not all physical rejection failures may necessarily be identified by downstream observation.

The rationale makes the assessment dependable during inspection.


5.31 Critical Aspects

A critical aspect can be understood as a feature, function, component, or condition necessary to assure that the system is fit for its intended GMP use.

Examples for compression equipment may include:

  • product-contact materials;
  • compression-force control;
  • tablet-weight control;
  • reject function;
  • critical instrumentation;
  • recipe control;
  • relevant data-integrity controls.

Risk assessment helps identify these aspects.


5.32 Critical Aspect vs Critical Component

These should not automatically be treated as identical.

Critical Aspect

Could be a function or design characteristic.

Example:

Correct tablet rejection

Components supporting the aspect

  • reject solenoid;
  • air supply;
  • sensor;
  • PLC logic;
  • reject chute;
  • confirmation sensor.

Qualification should focus on demonstrating the critical function, while installation evidence may verify individual components.


5.33 Risk-Based Testing

Risk-based testing means testing depth is determined by risk and intended use.

Higher-risk function

Possible approach:

  • design review;
  • FAT test;
  • installation verification;
  • OQ challenge;
  • traceability;
  • lifecycle monitoring.

Lower-risk function

Possible approach:

  • design/document review;
  • visual verification;
  • commissioning evidence.

This avoids unnecessary repetition.


5.34 Risk-Based Testing Does Not Mean Less Testing

This distinction is essential.

Risk-based testing means:

More meaningful testing.

It may actually result in more rigorous challenge testing for critical functions while reducing low-value checks.

For example:

Instead of spending extensive protocol pages checking cosmetic machine dimensions, qualification resources may focus on:

  • reject failures;
  • alarm limits;
  • interlocks;
  • access controls;
  • recipe changes;
  • failure recovery.

5.35 What Needs to Be Tested?

The risk assessment should identify functions requiring verification.

For every failure mode, ask:

Does this risk require a qualification test?

Possible answers:

Yes — Physical Challenge

Example: emergency stop.

Yes — Functional Challenge

Example: critical alarm.

Yes — Document Verification

Example: material certificate.

Yes — Configuration Review

Example: software version.

Supplier Evidence May Be Leveraged

Example: specific factory functional test.

Engineering Evidence Is Sufficient

For a low-risk engineering characteristic where justified.

No Additional Test Required

When adequate evidence already exists and the rationale is documented.


5.36 Why Does It Need Testing?

Each critical test should have a clear reason.

Weak rationale:

“Test required by OQ template.”

Strong rationale:

“Failure of the automatic reject function could allow identified nonconforming tablets to remain in the accepted product stream; therefore, the function will be challenged under defined reject conditions.”

That is risk-based qualification.


5.37 How Extensively Should It Be Tested?

Testing depth may depend on:

  • severity;
  • complexity;
  • operating range;
  • failure modes;
  • system novelty;
  • supplier knowledge;
  • previous experience;
  • detectability;
  • process variability.

For example, a critical operating control may require testing at:

  • lower limit;
  • nominal condition;
  • upper limit;
  • relevant failure/challenge condition.

Not every parameter automatically needs three-point testing; the scientific rationale determines the appropriate test strategy.


5.38 Normal Testing vs Challenge Testing

Normal-operation testing

Confirms the system works under expected routine conditions.

Challenge testing

Deliberately creates defined conditions to verify the system’s response.

Example:

Normal test: Machine operates with guard closed.

Challenge test: Attempt operation with designated guard open.

Risk assessment helps determine where challenge testing is necessary.


5.39 Worst-Case Testing

Worst-case testing should be scientifically justified.

Potential considerations include:

  • minimum load;
  • maximum load;
  • minimum speed;
  • maximum speed;
  • upper/lower operating limits;
  • difficult product characteristics;
  • environmental extremes within approved ranges.

“Worst case” should not simply be written into a protocol without explaining:

Worst case for what failure mechanism?


5.40 Leveraging Supplier Evidence

Risk assessment can determine where vendor evidence is sufficient or useful.

Supplier evidence may include:

  • FAT results;
  • material certificates;
  • calibration records;
  • software testing;
  • pressure tests;
  • electrical tests;
  • dimensional inspection.

Before leveraging supplier evidence, evaluate its quality.


5.41 Supplier Evidence Assessment

Ask:

  • Was the test predefined?
  • Was it executed against an approved specification?
  • Were acceptance criteria defined?
  • Was the tested configuration representative?
  • Were suitable instruments used?
  • Is raw evidence available?
  • Were deviations documented?
  • Can results be traced?
  • Were changes made after the test?
  • Does installation/transport invalidate the result?

Only then decide whether repeat testing adds value.


5.42 Example — Leveraging FAT

Suppose the vendor performs a comprehensive FAT of a compression machine recipe system.

FAT includes:

  • recipe creation;
  • parameter entry;
  • access restrictions;
  • recipe loading;
  • alarm handling;
  • audit trail.

After FAT, software is not changed.

At site, qualification may potentially leverage portions of this evidence while verifying:

  • installed software version;
  • configuration integrity;
  • site user roles;
  • interfaces;
  • site-specific settings.

However, if software changed significantly after FAT, the original FAT evidence may no longer fully support the installed state.


5.43 Leveraging Commissioning Evidence

Commissioning evidence can support qualification when it is suitable.

Example:

A commissioning loop check may verify:

Temperature transmitter TT-101

  • correct tag;
  • wiring;
  • signal;
  • displayed value;
  • range.

If executed under suitable controlled conditions with retained evidence, repeating the identical test during IQ/OQ may add little value.

Qualification can reference/leverage the evidence where the approved strategy allows.


5.44 Risk Assessment and IQ

Risk assessment can identify IQ-critical items.

Examples:

  • product-contact materials;
  • critical instruments;
  • critical utility connections;
  • software/firmware versions;
  • critical filters;
  • safety devices;
  • network configuration.

Lower-risk installation details may be handled through commissioning or engineering verification.


5.45 Risk Assessment and OQ

Risk assessment is especially important for OQ.

It identifies:

  • functions to challenge;
  • limits to test;
  • alarms to verify;
  • interlocks to challenge;
  • failure modes to simulate;
  • access restrictions to verify;
  • data-integrity functions to assess.

A good OQ should be visibly connected to the risk assessment.


5.46 Risk Assessment and PQ

Risk assessment helps establish:

  • critical operating conditions;
  • load configurations;
  • sampling points;
  • minimum/maximum loads;
  • reproducibility expectations;
  • worst-case conditions where justified.

PQ should not simply consist of “three runs” because a template says so.

The number and design of performance studies should be scientifically justified.


5.47 Risk Assessment for Computerized Functions

Consider a PLC/HMI-controlled machine.

Potential FMEA:

FunctionFailureEffectControlVerification
LoginUnauthorized accessUncontrolled changesRole-based accessOQ
RecipeUnauthorized changeWrong process settingsPermissions/audit trailOQ
AlarmAlarm not generatedAbnormal condition unnoticedAlarm logicFAT/OQ
Audit trailEvent not recordedLoss of traceabilitySystem configurationOQ
BackupBackup failsData lossBackup mechanismOQ/CSV
RestoreData cannot be restoredRecords unavailableRestore procedureOQ/CSV
InterfaceData transfer failsIncomplete/incorrect recordsInterface controlsInterface test

Testing effort should be proportional to the function’s intended GMP use.


5.48 Risk Assessment and Data Integrity

Data-integrity risk assessment should consider the data lifecycle:

Create

Process

Modify

Review

Approve

Store

Retrieve

Archive

Potential risks include:

  • unauthorized deletion;
  • unauthorized modification;
  • shared accounts;
  • uncontrolled administrator privileges;
  • incomplete audit trails;
  • failed backup;
  • incorrect timestamps;
  • incomplete interfaces.

Controls should be verified according to risk.


5.49 Risk Assessment and HVAC

Potential HVAC failure modes include:

  • HEPA filter leakage where applicable;
  • insufficient airflow;
  • pressure differential loss;
  • temperature excursion;
  • RH excursion;
  • airflow reversal;
  • alarm failure.

The applicable tests depend on:

  • room classification;
  • process;
  • exposed product;
  • contamination risk;
  • applicable GMP requirements.

5.50 Risk Assessment and Pharmaceutical Water Systems

Potential failure modes include:

  • microbial proliferation;
  • chemical contamination;
  • inadequate circulation;
  • stagnation;
  • sanitization failure;
  • incorrect temperature;
  • sample-point contamination;
  • monitoring failure.

Risk controls may include:

  • sanitary design;
  • circulation;
  • sanitization;
  • monitoring;
  • sampling;
  • alert/action systems;
  • trending.

Qualification should verify relevant design and operational controls.


5.51 Risk Assessment and Calibration

Not every instrument necessarily carries equal GMP significance.

Risk assessment can identify:

Critical instruments

Measurements directly used for important GMP/process control decisions.

Non-critical/monitoring instruments

Lower GMP significance depending on intended use.

Calibration requirements should then consider:

  • range;
  • accuracy;
  • tolerance;
  • process requirements;
  • failure consequences.

5.52 Residual Risk

After risk controls have been implemented and verified, the remaining risk is the residual risk.

A useful FMEA may show:

Failure ModeInitial RiskControlVerificationResidual Risk
Reject failureHighReject confirmation/controlOQ challengeAcceptable
Unauthorized recipe changeHighRole-based accessOQ access testAcceptable
Data lossHighBackup/restoreRestore challengeAcceptable

Residual-risk acceptance should be justified according to the company’s QRM procedure.


5.53 Qualification Failure and Risk Reassessment

Suppose a critical interlock fails during OQ.

Do not simply:

Repair → Re-test → Pass

A more appropriate lifecycle is:

Failure

Deviation

Impact Assessment

Investigation

Root Cause where warranted

Risk Assessment Updated if necessary

Correction/CAPA

Approved Re-test

Residual-Risk Review

Closure

The failure may reveal that the original risk assessment underestimated a failure mechanism.


5.54 Risk Assessment and Change Control

For an already-qualified system:

Proposed Change

What functions are affected?

What failure modes are introduced/changed?

Has severity/occurrence/detectability changed?

Are existing controls still adequate?

What testing is required?

Update risk assessment

Requalification as necessary

This prevents both unnecessary full requalification and inadequate change testing.


5.55 Risk Assessment Team

A multidisciplinary team is generally preferable.

For major manufacturing equipment:

FunctionContribution
ProductionProcess and operational knowledge
EngineeringEquipment/design knowledge
ValidationQualification/test strategy
QAGMP/QRM oversight
AutomationControl-system knowledge
ITInfrastructure/data knowledge
MaintenanceReliability/failure knowledge
EHSSafety/environmental risk
VendorDetailed design information

The final roles and approvals should follow the company’s PQS.


5.56 Risk Assessment Prerequisites

Before conducting a detailed FMEA, ideally have:

  • intended use;
  • approved/draft URS;
  • process description;
  • system boundary;
  • impact assessment;
  • relevant design information;
  • process knowledge;
  • historical information where available.

Conducting FMEA without understanding the system often produces generic failure modes with little qualification value.


5.57 Recommended Risk Assessment Protocol Structure

1. Document Identification

  • title;
  • number;
  • revision;
  • system ID.

2. Objective

State why the assessment is being performed.

3. Scope

Define included/excluded systems/functions.

4. References

Examples:

  • URS;
  • system-impact assessment;
  • design documents;
  • applicable QRM procedure.

5. Team

Identify participants and functions.

6. System Description

Describe intended use and major functions.

7. Risk Methodology

Define:

  • severity scale;
  • occurrence scale;
  • detectability scale;
  • risk-ranking methodology;
  • action criteria.

8. FMEA

Document identified risks.

9. Risk Controls

Identify design/procedural controls.

10. Qualification Requirements

Map risk controls to verification.

11. Residual Risk

Evaluate after controls.

12. Conclusion

Document overall assessment.

13. Approval

Obtain required approval.


5.58 Expanded FMEA Template

No.URSFunctionFailure ModePotential EffectPotential CauseExisting ControlSODRiskProposed ControlVerificationResidual RiskStatus
1
2
3

This creates direct traceability between requirements, risks, controls, and qualification tests.


5.59 Example — Complete Risk-to-Test Chain

Consider:

URS-CM-078

The machine shall restrict modification of approved recipe parameters to authorized users.

Impact Assessment

Recipe parameters can affect process operation and potentially product quality.

Failure Mode

Unauthorized operator modifies recipe.

Potential Effect

Incorrect process parameters used during manufacturing.

Risk Control

Role-based access with defined permissions.

Design

Operator role = view/select permitted functions.

Supervisor/authorized role = defined recipe privileges.

Administrator = configuration privileges under controlled access.

FAT

Verify configured user-role functionality.

OQ

Challenge:

  1. Login as Operator.
  2. Attempt restricted recipe modification.
  3. Confirm access is denied.
  4. Login using authorized role.
  5. Perform permitted modification according to test design.
  6. Verify audit/event record where applicable.

Evidence

Screenshots/electronic records/test observations as appropriate.

Traceability

URS-CM-078 → giauque → FMEA-024 → SDS → FAT → OQ → RTM

Residual Risk

Evaluated and accepted.

This is a strong risk-based qualification evidence chain.


5.60 Common Risk Assessment Deficiencies

DeficiencyWhy It Is Weak
FMEA copied from another machineMay not represent actual design
Every severity = 5No meaningful differentiation
Every occurrence = 1Artificially reduces risk
No scoring rationaleDecisions cannot be defended
RPN used mechanicallyHigh-severity risks may be missed
Risk assessment after OQRetrospective justification
No URS linkageRequirements disconnected
No test linkageRisk does not drive qualification
Controls listed but never verifiedAssumed control effectiveness
Residual risk absentNo final risk conclusion
No lifecycle reviewAssessment becomes obsolete

5.61 Inspector Perspective

An inspector may ask:

How did you determine which functions required qualification testing?

A strong answer shows:

URS → Impact Assessment → Risk Assessment → Critical Aspects → Test Strategy

The inspector may ask:

Why was this alarm challenged but that alarm was not?

A defensible answer should demonstrate differences in:

  • intended use;
  • GMP impact;
  • risk;
  • available evidence.

The inspector may also ask:

Show me a high-risk item from your FMEA and where you tested the control.

The organization should be able to trace immediately:

Risk → Control → Protocol Test → Raw Evidence → Result


5.62 Strong Response Characteristics

A strong qualification risk assessment demonstrates:

  • multidisciplinary involvement;
  • scientific rationale;
  • system-specific failure modes;
  • meaningful risk differentiation;
  • connection to process knowledge;
  • connection to URS;
  • connection to qualification tests;
  • documented residual risk;
  • lifecycle review.

5.63 Potential Inspection Red Flags

Watch for:

  • FMEA signed after qualification;
  • identical FMEAs for different machines;
  • unexplained risk scores;
  • high-severity items ignored because RPN is low;
  • critical controls not tested;
  • failed controls simply re-tested;
  • supplier claims accepted without evidence;
  • risk assessment not updated after design change;
  • residual high risks without disposition.

5.64 Practical Risk-Based Qualification Decision Tree

Identify Requirement / Function
              ↓
Does failure have GMP impact?
        ┌─────┴─────┐
        │           │
       NO          YES
        │           ↓
 Engineering   Identify Failure Mode
 Verification       ↓
              Assess Consequence
                    ↓
              Evaluate Risk
                    ↓
          Are controls adequate?
             ┌──────┴──────┐
             │             │
            NO            YES
             │             │
      Improve Design/      ↓
          Controls     Determine Verification
             │             ↓
             └──────→ Test / Review / Leverage
                           ↓
                    Acceptance Met?
                      ┌────┴────┐
                      │         │
                     NO        YES
                      │         ↓
                Deviation   Residual Risk
                      │         ↓
              Investigation   Acceptable?
                      │      ┌──┴──┐
                      └────→ NO   YES
                             │     │
                         Control   ↓
                         Further Qualified State

5.65 Risk-Based Qualification Checklist

Before Risk Assessment

  • □ Intended use defined
  • □ System boundary established
  • □ URS available
  • □ GMP impact assessed
  • □ Relevant process knowledge available
  • □ Cross-functional team identified
  • □ Risk methodology defined

During Assessment

  • □ Functions identified
  • □ Failure modes identified
  • □ Effects documented
  • □ Causes considered
  • □ Existing controls identified
  • □ Severity justified
  • □ Occurrence justified
  • □ Detectability justified
  • □ High-severity risks separately considered
  • □ Uncertainty considered
  • □ Critical aspects identified

Risk Control

  • □ Design controls preferred where appropriate
  • □ Additional controls assigned
  • □ Responsible person identified
  • □ Controls incorporated into design
  • □ DQ verification identified
  • □ FAT verification identified
  • □ SAT/IQ verification identified
  • □ OQ challenge testing identified
  • □ PQ requirements identified

Supplier/Commissioning Leverage

  • □ Supplier evidence evaluated
  • □ Test configuration confirmed
  • □ Acceptance criteria reviewed
  • □ Raw evidence available
  • □ Deviations reviewed
  • □ Post-test changes assessed
  • □ Site verification needs determined

Closure

  • □ Risk controls verified
  • □ Failed tests investigated
  • □ Residual risk assessed
  • □ Unacceptable risks resolved
  • □ Traceability updated
  • □ Final assessment approved

Lifecycle

  • □ Risk assessment linked to change control
  • □ Requalification triggers considered
  • □ Significant deviations trigger reassessment
  • □ Adverse trends reviewed
  • □ New process knowledge incorporated

5.66 Quality Risk Management Maturity Model

Level 1 — Documentation-Based

“We perform FMEA because SOP requires it.”

Level 2 — Score-Based

“Anything above RPN 40 is tested.”

Level 3 — Risk-Based

“Failure modes determine qualification scope.”

Level 4 — Science- and Risk-Based

“Process knowledge, failure mechanisms, uncertainty, controls and criticality determine assurance.”

Level 5 — Lifecycle-Based

“Risk assessment continuously supports design, qualification, changes, deviations, periodic review and requalification.”

A mature pharmaceutical organization should move toward Levels 4–5.


5.67 Golden Rule of Risk-Based Qualification

The most useful question during qualification planning is not:

“Which OQ template should we use?”

It is:

“What can fail in this system that could matter to product quality, patient safety, GMP control or data integrity—and what objective evidence will demonstrate that the risk is adequately controlled?”

That question changes qualification from paperwork into quality assurance through engineering evidence.


Part 5 — Key Takeaway

Quality Risk Management is the mechanism that connects GMP impact to qualification evidence.

A robust lifecycle is:

Intended Use → URS → GMP Impact → Failure Modes → Risk Evaluation → Critical Aspects → Design Controls → Verification Strategy → FAT/SAT/IQ/OQ/PQ → Deviations → Residual Risk → Traceability → Qualified State

The risk assessment should ultimately allow the qualification team to answer four critical questions:

1. What needs to be tested?
Functions whose failure could create meaningful GMP/product/data risk.

2. Why does it need testing?
Because a credible failure mode and consequence have been identified.

3. How extensively should it be tested?
According to risk, complexity, uncertainty, operating range and existing controls.

4. Can existing evidence be leveraged?
Yes, where supplier, FAT, SAT, commissioning or engineering evidence is sufficiently reliable, relevant, controlled and traceable.

This provides the direct foundation for Part 6 — Design Qualification (DQ), where the approved URS and risk assessment are translated into a formal assessment of whether the proposed design adequately satisfies GMP, process, quality, cleaning, utility, maintenance, safety, automation and data-integrity requirements before the system proceeds further into fabrication and qualification.

About the Author

Ramesh Palav is a pharmaceutical professional with 20+ years of industry experience in manufacturing, GMP, quality systems, validation, compliance, and operational excellence. Through Pharma Manufacturing Hub, he shares practical insights on pharmaceutical careers, manufacturing, quality, validation, Pharma 4.0, AI, and professional development.

His goal is to help students, freshers, experienced professionals, and career-break professionals build the knowledge and skills needed to succeed in the pharmaceutical industry.

Leave a Comment

Scroll to Top