Part 15

Deviation management is a critical component of qualification because qualification testing is specifically intended to determine whether a facility, utility, equipment, or system performs according to predefined requirements. When actual execution differs from the approved protocol, expected result, acceptance criterion, approved design, or intended system behavior, the event must be appropriately assessed rather than hidden, informally corrected, or simply retested.

Part 15 to address the lifecycle:

Observation → Documentation → Initial Assessment → Impact Assessment → Investigation → Root Cause where required → CAPA/Correction → Re-test → QA Assessment → Closure

It also requires differentiation between:

• documentation error;
• test discrepancy;
• protocol deviation;
• equipment failure;
• acceptance-criteria failure;
• design deficiency;
• GMP-critical failure;

and requires explanation of when qualification may continue and when execution should stop pending assessment.

15.1 What Is a Qualification Deviation?

A qualification deviation is an unexpected event, departure, discrepancy, failure, or condition encountered during qualification that may affect:

• approved protocol execution;
• predefined test methodology;
• acceptance criteria;
• expected system performance;
• approved requirements;
• design specifications;
• equipment functionality;
• GMP compliance;
• data integrity;
• product quality;
• patient safety;
• validity of qualification evidence.

The exact terminology and classification system should follow the company’s Pharmaceutical Quality System (PQS).

15.2 Fundamental Principle

A qualification deviation should never be treated simply as:

Something that prevented the protocol from passing.

Instead, the organization should determine:

What happened? → Why did it happen? → What does it affect? → Is existing evidence still valid? → What correction is required? → What additional testing is necessary? → Can the system still be considered qualified?

15.3 Why Deviations Matter

Qualification is intended to generate objective evidence of fitness for intended use.

A failure may reveal:

• inadequate design;
• incorrect installation;
• equipment malfunction;
• software defect;
• incorrect configuration;
• inappropriate operating range;
• inadequate procedure;
• incorrect acceptance criterion;
• inadequate test method;
• calibration issue;
• data-integrity weakness;
• incomplete training.

Therefore, failures can provide valuable information about the actual system.

The correct response is not to eliminate the failure from the record.

It is to understand it.

15.4 Complete Deviation Lifecycle

The lifecycle specified by your source can be expanded as:

Observation
    ↓
Immediate Documentation
    ↓
Initial Assessment
    ↓
Immediate Containment / Correction
where appropriate
    ↓
Impact Assessment
    ↓
Can Qualification Safely Continue?
 ┌─────────────┴─────────────┐
YES                         NO
 │                           │
Continue unaffected       Stop affected
activities where          testing/system
justified                    ↓
 │                       Investigation
 └──────────────┬────────────┘
                ↓
       Root Cause where required
                ↓
       Correction / CAPA
                ↓
        Change Control
        where applicable
                ↓
       Define Retest Scope
                ↓
       Authorized Retesting
                ↓
       Review Retest Results
                ↓
         QA Assessment
                ↓
             Closure
                ↓
     Qualification Conclusion

This preserves the complete history of qualification.

15.5 Observation

The lifecycle begins when an unexpected condition is observed.

Examples:

• interlock does not activate;
• measured speed exceeds acceptance criteria;
• instrument has expired calibration;
• protocol instruction cannot be executed;
• incorrect drawing is referenced;
• PLC sequence differs from specification;
• alarm does not activate;
• incorrect user permissions are observed;
• audit trail does not capture an expected event;
• test instrument fails;
• equipment stops unexpectedly;
• acceptance criterion appears incorrect.

The observation should not be ignored simply because the system subsequently behaves correctly.

15.6 Immediate Documentation

Record the observation contemporaneously.

Capture, where applicable:

This creates the initial evidence chain.

15.7 Do Not Rewrite the Qualification History

If the original test fails:

OQ-INT-005 — FAIL

and a subsequent justified retest passes:

OQ-INT-005-R1 — PASS

both results should remain visible.

The history should show:

Original Failure → Assessment → Investigation → Correction → Authorized Retest → Successful Result

Part 14 specifically identified discarding failed results and repeating tests until they pass without investigation as unacceptable practices.

15.8 Initial Assessment

The initial assessment determines:

• nature of the event;
• immediate significance;
• whether testing should stop;
• whether safety is affected;
• whether data integrity is affected;
• whether other tests may be affected;
• whether immediate containment is necessary;
• whether formal deviation investigation is required.

The objective is not necessarily to determine the final root cause immediately.

15.9 Initial Assessment Questions

Ask:

What happened?

Define the actual observation.

What was expected?

Reference the protocol/specification.

What is affected?

Test, subsystem, equipment or entire system?

Is safety affected?

Could continued operation create a hazard?

Is GMP affected?

Could the condition affect product or GMP records?

Is data integrity affected?

Can generated qualification data be trusted?

Can unaffected testing continue?

Only after appropriate assessment.

15.10 Impact Assessment

Impact assessment is one of the most important elements of qualification deviation management.

Potential impact should be considered on:

• patient safety;
• product quality;
• product identity;
• strength;
• purity;
• quality;
• CPPs;
• CQAs;
• contamination control;
• equipment functionality;
• utilities;
• electronic records;
• data integrity;
• qualification evidence;
• related tests;
• process validation;
• cleaning validation;
• GMP release.

The depth of assessment should reflect risk.

15.11 Qualification Impact

A specific question must be answered:

Does this event invalidate only one test, several tests, an entire qualification stage, or potentially the qualification status of the system?

Example:

A typographical error in an attachment number may have minimal technical impact.

A PLC logic defect controlling an automatic reject function may affect multiple OQ tests and the qualified configuration.

These should not receive identical treatment.

15.12 Seven Important Event Types

Your source specifically requires differentiation of seven types.

Terminology may vary between companies.

15.13 Documentation Error

A documentation error concerns the record rather than necessarily the equipment or system.

Examples:

• incorrect attachment number;
• transcription error;
• wrong equipment ID entered accidentally;
• incorrect date entered;
• missing unit;
• calculation transcription mistake.

Example

Actual tachometer output:

49.8 rpm

Protocol accidentally records:

48.9 rpm

Source evidence confirms 49.8 rpm.

This may be a documentation/transcription error rather than an equipment failure.

15.14 Handling Documentation Errors

Where appropriate:

Identify Error → Preserve Original Entry → Correct According to GDP → Reference Source → Assess Impact

However, do not classify an actual system failure as a “documentation error” merely to avoid a deviation.

Part 14 emphasized transparent corrections to executed protocols.

15.15 Test Discrepancy

A test discrepancy is an unexpected condition encountered during testing that requires assessment.

Examples:

• test equipment becomes unavailable;
• communication temporarily drops;
• incorrect test setup is identified;
• test cannot be completed as written;
• environmental condition changes unexpectedly.

Depending on the company’s system, a discrepancy may either be managed within the protocol or escalated into a formal deviation.

15.16 Protocol Deviation

A protocol deviation occurs when execution departs from the approved qualification protocol.

Examples:

• required test step omitted;
• sequence changed;
• wrong test instrument used;
• test performed outside specified condition;
• prerequisite not completed;
• required number of measurements not taken;
• different challenge condition used.

The critical question is:

Does the departure affect the validity of the qualification evidence?

15.17 Example — Protocol Deviation

Protocol requires speed verification at:

• 20 rpm;
• 50 rpm;
• 80 rpm.

Executor performs:

• 20 rpm;
• 50 rpm;
• 70 rpm.

Even if all readings pass, the approved upper test point was not executed.

The correct response is not:

“70 rpm was close enough.”

Instead:

Document → Assess impact → Determine whether required upper-range testing remains necessary → Authorize appropriate action/retest

15.18 Equipment Failure

An equipment failure occurs when the system or component fails to perform its intended function.

Examples:

• motor fails to start;
• sensor fails;
• guard interlock does not function;
• valve does not actuate;
• lubrication system fails;
• reject mechanism fails;
• communication module fails.

The failure may require:

• maintenance;
• engineering investigation;
• vendor support;
• component replacement;
• change control;
• partial or expanded retesting.

15.19 Acceptance-Criteria Failure

This occurs when the actual result does not meet a predefined approved acceptance criterion.

Example:

Acceptance:

50 ± 1 rpm

Actual:

52.4 rpm

Result:

FAIL

The result should not be changed to PASS because the equipment appears to operate acceptably.

15.20 Acceptance Failure Decision

Result Outside Criterion
        ↓
Confirm data validity
        ↓
Was test executed correctly?
   ┌──────┴──────┐
  NO            YES
   │              │
Assess test      Assess system/
execution       design/process
issue              ↓
   │           Investigate
   └──────┬───────┘
          ↓
     Determine Cause
          ↓
     Correct/Control
          ↓
     Define Retest

Do not automatically assume every out-of-criterion result is caused by equipment.

15.21 Design Deficiency

A design deficiency means the system may have been installed according to the approved design, but the design itself does not adequately satisfy the requirement or intended use.

Example:

URS requires automatic rejection of a defective tablet condition.

OQ reveals the PLC architecture cannot generate the required reject action under a defined failure mode.

This may be a design deficiency rather than merely an OQ test failure.

15.22 Design Deficiency Lifecycle

A design deficiency may require:

Deviation → Risk Assessment → Engineering Assessment → Design Change → Change Control → Updated Specification → Implementation → Verification → Regression Testing → Traceability Update

Simply changing the machine and repeating the OQ test may not adequately document the lifecycle.

15.23 GMP-Critical Failure

A GMP-critical failure may have potentially significant implications for:

• patient safety;
• product quality;
• contamination;
• cross-contamination;
• critical process control;
• GMP data;
• data integrity;
• validated/qualified state.

Examples could include significant failures of:

• critical alarms/interlocks;
• contamination-control systems;
• electronic record integrity;
• critical process controls;
• critical reject mechanisms.

Classification should follow the company’s approved quality system and documented risk assessment.

15.24 Severity Should Not Be Based on Convenience

A deviation should not be downgraded because:

• project schedule is tight;
• vendor must leave site;
• production wants the equipment;
• many tests have already passed;
• correction appears easy.

Classification should reflect:

GMP Impact + Product/Patient Risk + System Criticality + Data Impact + Qualification Impact

15.25 Root Cause Investigation

Your source requires root cause where required, rather than implying that every minor qualification issue needs the same investigation depth.

Investigation depth should be commensurate with:

• severity;
• recurrence;
• complexity;
• uncertainty;
• GMP impact;
• system impact.

15.26 Potential Root-Cause Categories

Possible categories include:

Equipment

• component failure;
• mechanical problem;
• incorrect installation.

Instrumentation

• sensor problem;
• calibration issue;
• range mismatch.

Software

• PLC logic defect;
• configuration error;
• HMI issue.

Design

• inadequate specification;
• incorrect engineering assumption.

Documentation

• protocol error;
• incorrect reference.

Personnel

• execution error;
• inadequate training.

Method

• inappropriate test method;
• unsuitable test setup.

Root cause should be evidence-based rather than selected merely from a standard category list.

15.27 “Operator Error” Is Not Automatically Root Cause

If an operator performs a test incorrectly, investigate why.

Potential underlying causes:

• ambiguous protocol;
• inadequate training;
• confusing HMI;
• incorrect procedure;
• insufficient supervision;
• poor test design.

Stopping at:

Root Cause: Human Error

may fail to identify the underlying system weakness.

15.28 Correction vs CAPA

These concepts should be distinguished.

Correction

Addresses the immediate identified problem.

Example:

Replace failed proximity sensor.

Corrective Action

Addresses the cause to prevent recurrence.

Example:

Revise sensor installation/maintenance approach after identifying repeated damage caused by mounting design.

Preventive/systemic action

May be considered where broader similar-system risk exists.

Not every qualification deviation automatically requires a full CAPA.

15.29 Example

Failure:

Guard interlock sensor does not activate.

Immediate correction:

Replace failed sensor.

Investigation identifies:

Sensor mounting causes repeated mechanical impact.

Corrective action:

Modify mounting arrangement under approved change control.

Potential broader assessment:

Review equivalent sensors on similar equipment.

15.30 Change Control Interface

Some qualification deviations lead to changes.

Examples:

• PLC code modification;
• component replacement with different specification;
• HMI configuration change;
• design modification;
• alarm setpoint change;
• new instrument range;
• piping modification.

Your source requires Part 17 to apply the lifecycle:

Change → GMP Impact → Risk Assessment → Qualification Impact → Required Testing → Documentation Update → Approval → Implementation → Verification → Closure.

A deviation does not replace required change control.

15.31 Can Qualification Continue?

This is a central Part 15 question.

Qualification may potentially continue when an appropriate documented assessment concludes that:

• safety is not compromised;
• data integrity remains acceptable;
• unaffected tests remain technically independent;
• continued testing will not generate invalid evidence;
• the deviation does not compromise system configuration required by subsequent testing;
• applicable procedural/QA requirements permit continuation.

Continuation should be justified—not assumed.

15.32 When Qualification Should Be Stopped Pending Assessment

Execution of affected activities should generally be stopped where the issue could materially affect:

• personnel safety;
• product quality;
• critical GMP functionality;
• contamination control;
• data integrity;
• validity of subsequent tests;
• controlled system configuration;
• ability to interpret qualification results.

The scope of the stop should reflect the issue.

Not every failure requires stopping the entire project.

15.33 Stop Scope

There are several possibilities:

Stop only the test

Example: reference instrument fails.

Stop related test group

Example: PLC alarm logic defect affects several alarm tests.

Stop qualification stage

Example: fundamental system configuration is uncontrolled.

Stop equipment use

Example: critical safety or GMP defect.

The decision should be risk-based and documented.

15.34 Continue vs Stop Decision Tree

Deviation / Failure Observed
          ↓
Immediate safety concern?
     ┌────┴────┐
    YES       NO
     │         ↓
   STOP    Potential critical
           GMP/data-integrity
              impact?
           ┌────┴────┐
          YES       NO
           │         ↓
        STOP     Does issue affect
                 validity of other tests?
                    ┌────┴────┐
                   YES       NO
                    │         ↓
               Stop affected  Continue may
               activities     be justified
                    │         under approved
                    │         assessment
                    ↓
              Investigate

15.35 Retesting

Retesting should follow investigation/assessment.

It should answer:

• Why is retesting necessary?
• What caused the original failure?
• What was corrected?
• Who authorized retesting?
• Which tests require repetition?
• Are related tests affected?
• Is regression testing required?
• Is the system configuration controlled?

15.36 Retesting Is Not a Reset Button

The sequence:

Fail → Repeat → Pass

is not adequate deviation management.

The defensible sequence is:

Fail → Document → Assess → Investigate → Correct → Define Retest Scope → Authorize → Retest → Evaluate

Part 14 explicitly identifies repeating tests until they pass without investigation as unacceptable.

15.37 Retest Scope

Retest scope may be:

• exact failed step;
• complete test script;
• related test scripts;
• subsystem;
• broader OQ regression;
• IQ/OQ elements;
• PQ where downstream evidence is affected.

The scope should be justified by impact assessment.

15.38 Regression Testing

Regression testing becomes particularly important after:

• PLC changes;
• HMI changes;
• SCADA changes;
• software upgrades;
• configuration changes;
• control-logic modifications.

Example:

Reject logic changed to correct OQ failure.

Potential affected functions:

Reject Trigger → Reject Confirmation → Reject Count → Alarm → Audit Trail → Batch Record → Recipe

Testing only the original reject trigger may therefore be insufficient.

15.39 Re-Test Identification

A useful convention could be:

Original:

OQ-017 — FAIL

First retest:

OQ-017-R1

Second retest, if justified:

OQ-017-R2

The exact convention is company-specific.

The objective is complete traceability.

15.40 QA Assessment

Your source places QA assessment before closure in the deviation lifecycle.

QA assessment may evaluate:

• adequacy of investigation;
• GMP impact;
• data-integrity impact;
• root cause;
• correction/CAPA;
• change control;
• retest justification;
• retest result;
• residual risk;
• impact on qualification conclusion.

Actual approval responsibilities depend on the PQS.

15.41 Deviation Closure

Before closure, verify as applicable:

• investigation complete;
• impact assessed;
• root cause addressed where required;
• correction completed;
• CAPA assigned/completed as appropriate;
• change control linked;
• retest completed;
• related tests assessed;
• evidence attached;
• traceability updated;
• residual risk assessed;
• QA disposition completed.

Closure should mean the issue has been adequately dispositioned—not merely administratively signed.

15.42 Open Deviations at Qualification Completion

A key question is:

Can a qualification report be approved with open deviations?

There is no universal answer from the supplied source.

The source instead requires the Qualification Summary Report to address:

• deviations;
• open items;
• CAPAs;
• outstanding risks;
• restrictions/limitations;
• QA disposition;
• release for GMP use where applicable.

Therefore, open items should be explicitly evaluated rather than automatically ignored or automatically treated as preventing every form of closure.

15.43 Critical vs Noncritical Open Items

Example of potentially noncritical item:

Cosmetic panel label replacement pending, with no impact on operation or GMP controls.

Potentially significant item:

Critical reject interlock remains unverified.

These should not receive the same qualification disposition.

The impact and residual risk should be documented.

15.44 Deviation Form — Recommended Structure

A practical qualification deviation record may contain:

Administrative Information

• deviation number;
• protocol number;
• test number;
• equipment/system;
• date/time;
• initiator.

Description

• expected condition;
• actual condition;
• acceptance criterion;
• objective evidence.

Initial Assessment

• immediate impact;
• safety;
• GMP impact;
• data impact;
• qualification impact;
• continuation decision.

Investigation

• evidence reviewed;
• investigation performed;
• root cause where required.

Action

• immediate correction;
• CAPA;
• change control.

Retesting

• retest required?
• scope;
• justification;
• authorization;
• results.

Closure

• residual risk;
• qualification impact;
• QA disposition;
• approval.

15.45 Example Deviation

Deviation

Protocol: OQ-TCM-001
Test: OQ-INT-007
Equipment: Tablet Compression Machine
Function: Guard Interlock

Expected Result

Opening the identified guard shall produce the response defined in the approved functional/interlock specification.

Actual Result

During challenge testing, the expected interlock response did not occur.

Initial Status

FAIL

Immediate Action

Affected test execution stopped and the equipment condition preserved for assessment.

Impact Assessment

Potential impact on:

• operator safety;
• machine interlock functionality;
• related OQ interlock tests;
• qualification conclusion.

Investigation

Engineering and automation investigation identifies the cause.

Correction

Implemented through the applicable controlled process.

Retest

Repeat affected test and assess need for regression testing of related interlocks.

Final Disposition

To be determined after successful testing and QA assessment.

This example deliberately avoids inventing a root cause before evidence exists.

15.46 Example — Documentation Error

Source printout:

10.8 Pa

Protocol entry:

18.0 Pa

Investigation confirms a transcription error.

Potential disposition:

Original source data valid → GDP correction → transcription impact assessed → no equipment failure

This should not automatically trigger equipment maintenance.

15.47 Example — Test Execution Error

Protocol requires:

Challenge at 80 rpm.

Executor mistakenly tests at:

70 rpm.

The equipment did not necessarily fail.

The test itself failed to demonstrate the approved requirement.

Therefore:

Protocol/Test Deviation → Assess → Perform required authorized test → Preserve original execution record

15.48 Example — Acceptance-Criteria Failure

Criterion:

Differential pressure ≥ defined approved limit.

Actual result:

Below approved limit.

Potential causes could include:

• HVAC performance;
• door condition;
• sensor error;
• incorrect test setup;
• calibration problem;
• design issue.

Do not assign root cause until investigated.

15.49 Example — Software Failure

OQ requirement:

Unauthorized operator shall not modify critical configuration.

Actual:

Operator role can access critical configuration.

Potential impact:

• access control;
• configuration integrity;
• GMP records;
• data integrity;
• related user-role tests.

Potential lifecycle:

Failure → Deviation → Access Risk Assessment → Configuration Investigation → Controlled Correction → User-Role Regression Testing → Audit-Trail Review where relevant → QA Assessment

15.50 Deviation Trending

Individual deviations should also be considered collectively where appropriate.

Trends may reveal:

• recurring component failures;
• repeated protocol errors;
• vendor design weaknesses;
• recurring software defects;
• poor test preparation;
• inadequate training;
• recurring documentation errors.

A series of individually minor deviations can reveal a larger systemic problem.

15.51 Vendor-Related Deviations

Vendor presence does not change GMP documentation expectations.

Example:

Vendor observes PLC failure and immediately modifies code.

The pharmaceutical company should still preserve the controlled history:

Failure → Documentation → Assessment → Controlled Change → Configuration Identification → Retesting

Avoid undocumented vendor changes during qualification.

15.52 Deviation and Traceability

A deviation can affect the traceability matrix.

Example:

This is stronger than simply changing:

OQ-017 = Pass

and removing the failure history.

15.53 Deviation and Qualification Summary Report

The Qualification Summary Report should summarize significant deviations.

The source specifically requires the QSR to address deviations, open items, CAPAs, change controls, acceptance-criteria status, traceability status, outstanding risks, restrictions and final QA disposition.

A useful summary table is:

15.54 Deviation RACI

R = Responsible, A = Accountable, C = Consulted, I = Informed.

Actual responsibilities depend on the company’s PQS.

15.55 Common Mistakes

1. Calling Every Failure “Minor”

Classification should be based on impact.

2. Retesting Immediately

A failed result should first be assessed.

3. Deleting Failed Data

The original record must remain.

4. Vendor Fixes Without Documentation

Creates configuration and traceability problems.

5. Root Cause = Operator Error

Often insufficient without deeper assessment.

6. No Impact Assessment

A correction alone does not establish that prior/subsequent data remain valid.

7. Retesting Only Failed Step

Related functions may require regression testing.

8. Closing Before CAPA/Change Linkage

The lifecycle may remain incomplete.

9. Treating Protocol Errors as Equipment Failures

First determine what actually failed.

10. Treating Equipment Failures as Documentation Errors

This can conceal genuine technical problems.

15.56 Inspector Perspective — “Show Me the Deviation”

Your source specifically identifies this as an expected inspection question.

An inspector may expect to see:

Original Observation → Initial Assessment → Impact → Investigation → Root Cause → Action → Retest → Closure

A strong deviation should tell the entire story without requiring extensive verbal explanation.

15.57 Inspector Perspective — “Who Approved the Retest?”

This question tests whether the organization controls repeated testing.

Strong evidence includes:

• original failure;
• deviation;
• investigation;
• retest rationale;
• authorization;
• defined retest scope;
• retest result.

Potential red flag:

“The engineer just repeated it because the first result looked unusual.”

15.58 Inspector Perspective — “How Were Qualification Failures Investigated?”

The inspector is testing whether qualification is genuine verification or simply a paperwork exercise.

Strong response:

Failure → Documented Investigation → Evidence-Based Cause → Appropriate Correction → Impact Assessment → Controlled Retest

Potential red flag:

“We repeated every failed test and they all passed eventually.”

15.59 Inspector Perspective — “Did You Assess Other Systems?”

A recurring or design-related problem may extend beyond one equipment item.

Example:

A vendor PLC configuration defect is discovered on one machine.

A reasonable question is:

Do other machines using the same configuration have the same vulnerability?

This is where broader CAPA/systemic assessment may become relevant.

15.60 Inspector Perspective — “Why Did Testing Continue?”

If a significant failure occurs but qualification continues, the organization should be able to explain:

• what was known;
• what impact was assessed;
• why unaffected testing remained valid;
• who authorized continuation;
• what boundaries were applied.

“We did not want to delay the project” is not a GMP rationale.

15.61 Inspector Perspective — “Why Did Testing Stop?”

Stopping testing is not itself evidence of poor qualification.

A controlled stop can demonstrate an effective quality system.

Example:

Critical PLC configuration problem detected → affected OQ suspended → investigation → controlled correction → configuration baseline established → testing resumed.

This can be more defensible than continuing with questionable evidence.

15.62 Qualification Failure Decision Matrix

Final decisions should follow documented risk assessment and site procedures.

15.63 Qualification Deviation Checklist

Observation

• □ Event clearly described
• □ Expected condition identified
• □ Actual condition recorded
• □ Protocol/test identified
• □ Raw evidence retained
• □ Date/time recorded
• □ Observer identified

Initial Assessment

• □ Safety impact assessed
• □ GMP impact assessed
• □ Data-integrity impact assessed
• □ Qualification impact assessed
• □ Continuation/stop decision documented
• □ Immediate containment considered

Investigation

• □ Relevant evidence reviewed
• □ Equipment condition assessed
• □ Test method assessed
• □ Instrument status assessed
• □ Software/configuration assessed where relevant
• □ Root cause determined where required

Action

• □ Correction documented
• □ CAPA considered
• □ Change control considered
• □ Related systems considered

Retest

• □ Retest justified
• □ Retest scope defined
• □ Regression scope considered
• □ Retest authorized
• □ Original failure retained
• □ Retest evidence retained

Closure

• □ Impact assessment complete
• □ Actions complete/appropriately tracked
• □ Traceability updated
• □ Residual risk assessed
• □ Qualification impact concluded
• □ QA disposition completed

15.64 Best-Practice Principles

A robust deviation system should be:

Transparent — preserve the original event.

Contemporaneous — document failures when they occur.

Risk based — investigation depth reflects significance.

Evidence based — root cause follows evidence.

Controlled — corrections and changes are authorized.

Traceable — deviation links to protocol, test and retest.

Complete — failed and passing results remain visible.

Scientifically justified — retest scope follows impact.

Independent — QA oversight is applied according to the PQS.

Lifecycle oriented — deviation impact continues through final qualification disposition.

15.65 Golden Rule for Qualification Deviations

A failed qualification test is not the problem to hide; it is evidence that the qualification process has identified something that requires understanding.

The objective is not:

Make every test look like it passed first time.

The objective is:

Generate reliable evidence, identify failures, understand their impact, correct genuine deficiencies, verify corrections and transparently establish the final qualified state.

15.66 Complete Qualification Deviation Evidence Chain

Approved Requirement
        ↓
Approved Protocol
        ↓
Qualification Test
        ↓
Unexpected Observation / Failure
        ↓
Contemporaneous Documentation
        ↓
Deviation / Discrepancy
        ↓
Initial Assessment
        ↓
Impact Assessment
        ↓
Investigation
        ↓
Root Cause where required
        ↓
Correction / CAPA
        ↓
Change Control where applicable
        ↓
Retest Scope
        ↓
Authorized Retest
        ↓
Regression Testing where required
        ↓
Successful / Unsuccessful Result
        ↓
Residual Risk Assessment
        ↓
QA Disposition
        ↓
Traceability Update
        ↓
Qualification Summary Report
        ↓
Final Qualified-State Decision

15.67 Part 15 — Key Takeaway

Your source defines the qualification deviation lifecycle as:

Observation → Documentation → Initial Assessment → Impact Assessment → Investigation → Root Cause where required → CAPA/Correction → Re-test → QA Assessment → Closure.

The most important practical distinction is that not every problem encountered during qualification is the same. A documentation error, test discrepancy, protocol deviation, equipment failure, acceptance-criteria failure, design deficiency, and GMP-critical failure can require substantially different responses.

The fundamental decision should therefore be:

What failed—the documentation, the test execution, the protocol, the measuring system, the equipment, the design, or the GMP control?

Once that is understood, the organization can appropriately determine:

Impact → Investigation → Correction/CAPA → Change Control → Retest Scope → QA Assessment → Closure

Most importantly:

Qualification should not continue blindly after a significant failure, but neither should every minor discrepancy automatically stop the entire qualification program. The decision to continue, partially suspend, or stop testing should be based on documented impact and risk.

Next — Part 16: Qualification Summary Report

Part 16 – Qualification Summary Report (QSR) covering:

Objective → Scope → Equipment/System → Protocols Executed → Test Summary → Deviations → Open Items → CAPAs → Change Controls → Acceptance-Criteria Status → Traceability Status → Outstanding Risks → Restrictions/Limitations → Conclusion → Recommended Qualified State → QA Disposition → GMP Release where applicable.

A particularly important Part 16 principle will be:

Successful execution of individual IQ/OQ/PQ protocols does not, by itself, automatically establish that the overall system is suitable for GMP use.

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.