Part 10

The qualification sequence is:

URS → Risk Assessment → DQ → FAT → SAT → IQ → OQ → PQ → Qualification Summary → GMP Release

The fundamental OQ question is:

Does the installed and configured equipment/system consistently operate according to approved functional requirements throughout its specified operating ranges, including appropriate responses to abnormal and failure conditions?

10.1 What Is Operational Qualification?

Operational Qualification (OQ) is documented verification that installed equipment, facilities, utilities, systems, controls, and computerized functions operate as intended throughout anticipated operating ranges.

OQ should provide objective evidence that applicable:

• operating controls;
• parameter ranges;
• sequences;
• alarms;
• interlocks;
• permissives;
• safety functions;
• recipes;
• PLC/HMI/SCADA functions;
• user-access controls;
• electronic records;
• audit trails;
• failure responses;
• recovery functions;
• backup/restore functions

perform according to approved requirements.

10.2 Purpose of OQ

IQ establishes:

“The correct system is installed.”

OQ establishes:

“The installed system functions correctly.”

PQ subsequently establishes:

“The system performs effectively and reproducibly under intended process/use conditions.”

Therefore:

IQ = Installation

OQ = Operation

PQ = Performance

10.3 OQ Position in the Qualification Lifecycle

Approved URS
     ↓
Quality Risk Assessment
     ↓
Design Qualification
     ↓
FAT
     ↓
SAT
     ↓
Installation Qualification
     ↓
┌────────────────────────┐
│ Operational Qualification│
└────────────────────────┘
     ↓
Performance Qualification
     ↓
Qualification Summary
     ↓
GMP Release

10.4 Core Objectives of OQ

A robust OQ should demonstrate, as applicable:

1. normal operation;
2. defined operating ranges;
3. parameter controls;
4. lower/upper operating boundaries;
5. alarms;
6. interlocks;
7. permissives;
8. safety functions;
9. sequences;
10. recipes;
11. automated controls;
12. failure modes;
13. power-loss response;
14. communication-loss response;
15. recovery;
16. user access;
17. audit trails;
18. electronic records;
19. backup and restore;
20. interfaces.

OQ should not be limited to:

“Start machine → Run machine → Stop machine → Pass.”

That is normally inadequate for a critical GMP system.

10.5 Risk-Based OQ

OQ should be driven by:

URS + Risk Assessment + Critical Aspects + Design + FAT/SAT/IQ Evidence

Higher-risk functions generally require stronger challenge testing.

Example:

10.6 OQ Should Challenge the System

A common weakness is testing only successful normal operation.

OQ should ask:

What happens when conditions are not normal?

Examples:

• pressure falls;
• temperature rises;
• guard opens;
• sensor fails;
• communication is lost;
• unauthorized user attempts a restricted action;
• power fails;
• incorrect parameter is entered;
• operating limit is exceeded.

This is where OQ becomes true qualification rather than demonstration.

10.7 OQ Inputs

Typical OQ inputs include:

• approved URS;
• qualification plan/VMP;
• system impact assessment;
• risk assessment;
• DQ;
• FAT report;
• SAT report;
• IQ protocol/report;
• functional specification;
• software specification;
• control philosophy;
• alarm list;
• interlock matrix;
• recipe specification;
• user-role matrix;
• instrument list;
• operating manuals;
• approved OQ protocol.

10.8 OQ Prerequisites

Before execution, verify as applicable:

• □ IQ successfully completed or acceptable for OQ progression
• □ Critical IQ deviations closed
• □ OQ protocol approved
• □ Equipment status identified
• □ Utilities available
• □ Critical instruments calibrated
• □ Test instruments calibrated
• □ Software baseline established
• □ PLC/HMI/SCADA configuration controlled
• □ Safety systems available
• □ Required procedures available
• □ Test personnel trained
• □ Required test materials available
• □ FAT/SAT leveraged tests identified
• □ Open items assessed for OQ impact

10.9 Recommended OQ Protocol Structure

A comprehensive OQ protocol may include:

1. Document Control

• protocol title;
• document number;
• revision;
• equipment/system ID;
• project number.

2. Approval

• prepared by;
• reviewed by;
• approved by.

3. Objective

4. Scope

5. System Description

6. Responsibilities

7. References

8. Definitions

9. Prerequisites

10. Test Instruments

11. Operating Controls

12. Operating Range Verification

13. Parameter Challenge Tests

14. Sequence Verification

15. Permissive Verification

16. Alarm Testing

17. Interlock Testing

18. Safety Functions

19. Failure-Mode Testing

20. Power-Failure/Recovery

21. Communication Failure/Recovery

22. Recipe Functions

23. PLC/HMI/SCADA Functions

24. User Access

25. Audit Trails

26. Electronic Records

27. Reports

28. Backup/Restore

29. Interface Testing

30. Deviations

31. Retesting

32. Traceability

33. OQ Summary

34. PQ Readiness

10.10 Standard OQ Test Format

Each significant OQ test should contain:

Test ID

Unique identifier.

Test Title

Specific function being challenged.

Objective

What is the test intended to demonstrate?

Prerequisites

Conditions necessary before execution.

Test Method

Detailed executable steps.

Expected Result

Predefined expected response.

Actual Result

Observed result.

Acceptance Criteria

Objective pass/fail requirements.

Evidence

Raw data, printouts, screenshots, records, measurements, etc.

Status

PASS / FAIL / N/A

Executed By

Name/signature/date.

Reviewed By

Name/signature/date.

10.11 Normal Operating Functions

OQ should first establish normal operation.

Typical functions include:

• power ON;
• initialization;
• startup;
• machine ready;
• manual mode;
• automatic mode;
• parameter entry;
• operation;
• normal stop;
• controlled shutdown;
• restart.

10.12 Operating Control Verification

Verify all relevant operator controls.

Examples:

• start;
• stop;
• pause;
• reset;
• emergency stop;
• mode selection;
• parameter entry;
• recipe selection;
• alarm acknowledgement.

Each control should produce the specified response.

10.13 Operating Range Verification

Critical operating parameters should be tested over applicable defined ranges.

Example:

If equipment is specified to operate between:

20–80 rpm

OQ should not automatically test only:

50 rpm

The protocol should consider:

• lower operating range;
• nominal condition;
• upper operating range.

10.14 Three-Point Range Testing

A common risk-based approach for suitable parameters is:

However, three-point testing should not be used mechanically.

The number and location of test points should reflect:

• risk;
• control characteristics;
• equipment capability;
• intended use.

10.15 Boundary Testing

Boundary testing evaluates operation close to defined limits.

Suppose the approved operating range is:

20–80 rpm

Potential testing may include:

• minimum intended setting;
• normal setting;
• maximum intended setting;
• attempts to enter values outside permitted configuration where relevant.

The objective is to verify both operation and control of limits.

10.16 Worst-Case Testing

Worst case means a condition or combination of conditions representing the greatest challenge to the function being evaluated.

Examples might include:

• lowest allowable speed;
• highest allowable speed;
• minimum utility pressure;
• maximum load;
• minimum load;
• highest configured parameter;
• lowest configured parameter.

Worst-case selection should be scientifically justified.

10.17 Proven Acceptable Range

Qualification should distinguish between:

• equipment capability;
• qualified operating range;
• process operating range;
• routine set point.

These are not automatically identical.

For example:

Equipment mechanically capable: 10–100 rpm

Qualified operating range: 20–80 rpm

Routine process range: 35–60 rpm

OQ evidence should clearly identify what has actually been challenged.

10.18 Set Point vs Actual Value

Where a control loop or parameter is important, record both:

Set Value → Actual Value

Example:

Do not invent universal tolerances. Use approved specifications.

10.19 Sequence Verification

Automated equipment frequently operates according to programmed sequences.

Example:

Power ON
   ↓
Initialization
   ↓
Safety Check
   ↓
Utility Check
   ↓
Ready State
   ↓
Start Command
   ↓
Auxiliary Systems
   ↓
Main Operation
   ↓
Process Control
   ↓
Normal Stop

OQ should verify the sequence against the approved functional specification.

10.20 Sequence Failure Testing

Do not test only the successful sequence.

Challenge conditions such as:

• utility unavailable;
• guard open;
• emergency stop active;
• downstream equipment unavailable;
• critical alarm active.

The equipment should not proceed when required permissives are absent.

10.21 Permissive Testing

A permissive is a required condition before an action is allowed.

Example machine-start permissives:

• emergency stop reset;
• guards closed;
• lubrication available;
• compressed air available;
• no critical fault;
• downstream system ready.

OQ should challenge critical permissives individually where practicable.

10.22 Example Permissive Test

Objective

Verify machine cannot start when compressed-air pressure is below the defined requirement.

Method

1. Establish system ready condition.
2. Create/simulate low-air condition using approved method.
3. Attempt machine start.
4. Observe response.
5. Restore acceptable air condition.
6. Reset system.
7. attempt start.

Expected Result

Machine-start behavior shall conform to the approved control specification.

10.23 Alarm Qualification

Alarm testing is a major OQ activity.

Each critical alarm should be challenged using an appropriate method.

Verify:

1. trigger condition;
2. alarm set point where applicable;
3. alarm text;
4. visual indication;
5. audible indication where applicable;
6. equipment response;
7. acknowledgement;
8. reset;
9. alarm history/record where applicable.

10.24 Alarm Matrix

Develop a controlled alarm matrix.

Alarm criticality should be established through the approved risk process.

10.25 Alarm Set-Point Testing

Where alarms depend on numerical set points, verify the configured set point and functional response.

Example:

Low pressure alarm set point = approved value

Test around the threshold as appropriate:

• above alarm condition;
• transition through threshold;
• below threshold;
• recovery.

Record actual values.

10.26 Alarm Text

Alarm messages should be meaningful to users.

Instead of simply checking:

“Alarm displayed.”

Verify the displayed alarm corresponds to the actual condition.

Incorrect alarm text can lead to:

• incorrect operator response;
• delayed troubleshooting;
• process risk.

10.27 Alarm Acknowledgement

Where applicable verify:

• authorized user can acknowledge;
• acknowledgement does not improperly remove the underlying fault;
• alarm remains active where condition persists;
• alarm clears/reset behaves as designed;
• record/history is retained where required.

10.28 Interlock Qualification

An interlock automatically prevents or initiates an action based on a defined condition.

Examples:

• guard open → machine stop;
• low lubrication → operation inhibited;
• high pressure → operation stopped;
• downstream failure → upstream machine stopped.

OQ should challenge critical interlocks.

10.29 Example Interlock Test

Test ID

OQ-INT-004

Objective

Verify the designated guard interlock.

Method

1. Establish normal operation.
2. Open designated guard under controlled safe conditions.
3. Observe response.
4. Attempt restart with guard open.
5. Close guard.
6. Perform required reset.
7. Restart.

Acceptance Criteria

System behavior shall correspond to the approved safety/functional specification.

10.30 Safety Functions

Applicable safety functions may include:

• emergency stops;
• guards;
• interlocks;
• pressure protection;
• overload protection;
• safety relays.

OQ should distinguish between:

Safety Engineering Requirements

and

GMP Qualification Requirements

while coordinating testing where both apply.

10.31 Emergency-Stop Testing

For each required emergency stop:

1. identify device;
2. establish safe operating condition;
3. activate device;
4. verify equipment response;
5. verify reset;
6. verify restart behavior.

Do not assume testing one emergency stop proves all independently wired devices.

10.32 Failure-Mode Testing

Failure-mode testing is one of the most important OQ elements.

Consider credible failures such as:

• loss of compressed air;
• power failure;
• sensor failure;
• communication loss;
• motor overload;
• downstream equipment failure;
• database/server unavailability;
• printer failure where relevant.

Test scope should be based on risk.

10.33 Failure-Mode Philosophy

For each critical failure ask:

What should the equipment do?

Possible responses:

• continue safely;
• stop immediately;
• complete current step then stop;
• alarm;
• inhibit startup;
• preserve data;
• reject affected material;
• require authorized reset.

The expected response should be defined before testing.

10.34 Power Failure

Power-loss testing may verify:

• equipment enters safe state;
• data are retained as required;
• recipe/configuration remains intact;
• relevant records are preserved;
• automatic restart is controlled;
• recovery is appropriate;
• alarms/events are recorded where applicable.

10.35 Example Power-Loss Test

Initial Condition

Machine operating under defined test condition.

Action

Interrupt electrical power using an approved safe test method.

Verify

• machine response;
• product/material handling implications;
• HMI/PLC state;
• data retention;
• recipe retention;
• time/event records;
• restoration behavior.

Restore Power

Verify:

• controlled startup;
• appropriate status;
• no unintended operation;
• data/configuration availability.

10.36 Communication Failure

For networked systems, challenge critical communication links where risk warrants.

Examples:

• PLC ↔ HMI;
• PLC ↔ SCADA;
• equipment ↔ MES;
• equipment ↔ historian;
• machine ↔ peripheral device.

Verify:

• detection;
• alarm;
• safe response;
• data handling;
• reconnection;
• recovery.

10.37 Sensor Failure

Where critical sensors drive GMP functions, consider failure simulation.

Examples:

• disconnected sensor;
• invalid signal;
• out-of-range signal.

Verify that the system does not silently interpret an invalid critical signal as a valid process condition.

10.38 Recovery Testing

Qualification should verify not only failure response but also recovery.

Ask:

What happens after the fault is removed?

Verify as appropriate:

• alarm clearance;
• reset;
• state restoration;
• data availability;
• recipe retention;
• controlled restart.

10.39 PLC Functional Testing

OQ may challenge critical PLC-controlled functions including:

• sequence;
• timers;
• counters;
• calculations;
• alarms;
• interlocks;
• permissives;
• output control;
• failure response.

Testing should focus on GMP-relevant intended functions rather than every line of PLC code.

10.40 HMI Functional Testing

Potential HMI tests include:

• login;
• navigation;
• status display;
• parameter display;
• parameter entry;
• alarm display;
• recipe management;
• trend display;
• report access;
• user access;
• date/time display.

10.41 HMI Parameter Limits

Suppose a parameter is permitted from:

10 to 50 units

Test:

• 10 → accepted;
• nominal value → accepted;
• 50 → accepted;
• below 10 → rejected/prevented as designed;
• above 50 → rejected/prevented as designed.

This demonstrates both valid-range operation and limit enforcement.

10.42 SCADA Functional Testing

Where SCADA is GMP relevant, OQ may include:

• process values;
• communication;
• alarms;
• trends;
• historian;
• user access;
• reports;
• audit trails;
• data retrieval;
• system status.

The master prompt requires computerized-system documentation to align with applicable lifecycle expectations for PLC/HMI/SCADA/DCS/MES-controlled systems.

10.43 Recipe Management

Recipe functionality may be critical because incorrect recipes can directly affect manufacturing.

OQ may verify:

• recipe creation;
• recipe selection;
• parameter limits;
• recipe modification;
• recipe approval where configured;
• recipe deletion;
• version control;
• user authorization;
• audit trail.

10.44 Recipe Creation

Verify that:

• authorized user can create a recipe where intended;
• mandatory fields are controlled;
• parameter ranges are enforced;
• recipe identity is unique where required;
• saving functions correctly.

10.45 Recipe Selection

Verify:

• correct recipe can be selected;
• recipe identity is visible;
• selected parameters load correctly;
• wrong/unauthorized selection is controlled as specified.

For critical applications, the operator should be able to identify which recipe is active.

10.46 Recipe Modification

Challenge:

Operator

Attempt modification.

Expected:

Prevented if role is unauthorized.

Authorized Supervisor/Engineer

Attempt permitted modification.

Expected:

Allowed according to approved role matrix.

Then verify applicable audit-trail information.

10.47 Recipe Parameter Limits

Example:

Approved feeder-speed recipe range:

Xmin–Xmax

Test:

• Xmin;
• nominal;
• Xmax;
• below Xmin;
• above Xmax.

Acceptance should be based on the approved specification.

10.48 User Access Control

Where computerized access is GMP relevant, OQ should challenge the approved user-role matrix.

Typical roles might include:

• Operator;
• Supervisor;
• Engineer;
• Administrator.

Do not assume role names alone demonstrate appropriate access.

10.49 User-Role Matrix

Actual permissions must come from approved requirements.

10.50 Unique User Accounts

Verify as applicable:

• individual login;
• unique user identity;
• unauthorized access prevention;
• password control;
• inactive/disabled account behavior;
• session handling.

Shared generic accounts should be assessed against intended GMP use and applicable site requirements.

10.51 Password Controls

Depending on the approved requirements, OQ may verify:

• minimum password requirements;
• password change;
• failed-login handling;
• account lockout;
• password masking;
• password reuse controls;
• administrative reset.

Do not invent arbitrary password rules; test the approved configuration.

10.52 Session Management

Where applicable verify:

• automatic logout;
• screen locking;
• session timeout;
• reauthentication.

The extent should be risk based.

10.53 Administrator Controls

Administrative privileges are highly powerful.

Verify:

• access restricted;
• user administration controlled;
• critical configuration access controlled;
• auditability as applicable;
• vendor accounts appropriately controlled.

10.54 Audit-Trail Qualification

For GMP-relevant computerized functions, OQ may need to demonstrate appropriate audit-trail functionality.

Challenge relevant actions such as:

• parameter change;
• recipe change;
• user administration;
• configuration change;
• record modification where allowed.

10.55 Audit-Trail Evidence

Depending on system design, verify applicable information such as:

• user identity;
• date/time;
• event;
• changed field;
• original value;
• new value;
• reason for change where required/configured.

The exact expectation should correspond to system requirements and applicable controls.

10.56 Audit-Trail Protection

Verify ordinary users cannot:

• disable required audit trails;
• modify audit-trail records;
• delete audit-trail records

where the system is designed to prevent such actions.

10.57 Audit-Trail Retrieval

A control is of limited value if records cannot be practically retrieved.

Verify:

• access;
• filtering/search where applicable;
• readability;
• chronological information;
• linkage to relevant record/batch where applicable.

10.58 Electronic Records

Where the system creates GMP-relevant electronic records, OQ may verify:

• record generation;
• completeness;
• accuracy;
• storage;
• retrieval;
• readability;
• protection;
• retention-related configuration where applicable.

10.59 Electronic Reports

Test applicable reports for:

• correct title;
• equipment/system identity;
• batch/record identity;
• parameter values;
• date/time;
• user identity where required;
• completeness;
• accuracy.

Report testing should verify content, not merely that a PDF or printout is generated.

10.60 Date and Time

For GMP-relevant electronic systems, verify:

• correct system time;
• time synchronization;
• time zone;
• access restrictions for changing time;
• appropriate handling of time-related records.

Site architecture determines the detailed test approach.

10.61 Data Integrity

Data-integrity controls should be challenged where relevant.

The evidence should support appropriate principles of:

Attributable → Legible → Contemporaneous → Original/True Copy → Accurate → Complete → Consistent → Enduring → Available

OQ should test actual system functions supporting these controls rather than merely stating “ALCOA+ compliant.”

10.62 Backup Qualification

Where backup is part of the system’s GMP control strategy, verify:

• defined data/configuration can be backed up;
• backup completes;
• backup is identifiable;
• backup is protected;
• backup can be retrieved.

But:

A successful backup alone does not prove recoverability.

Restore testing provides that evidence.

10.63 Restore Testing

A controlled restore test may verify:

1. create controlled test data/configuration;
2. perform backup;
3. change/remove test state as permitted;
4. restore from backup;
5. verify restored information;
6. compare against original;
7. document results.

Restore testing should be designed carefully to avoid unintended impact on live data.

10.64 Disaster/Recovery Functions

For more complex computerized systems, recovery testing may include:

• application restart;
• server restart;
• service restart;
• database recovery;
• failover;
• restoration from backup.

Scope depends on system architecture and risk.

10.65 Interface Qualification

Interfaces can be a significant source of data-integrity and process-control risk.

Examples:

Equipment → SCADA

SCADA → Historian

Equipment → MES

MES → ERP

Compression Machine → Metal Detector

10.66 Interface Testing

Verify as applicable:

• correct data sent;
• correct data received;
• correct units;
• correct equipment/batch identity;
• communication failure;
• duplicate transmission;
• recovery;
• error handling.

10.67 Peripheral Equipment Interface

For a tablet line:

Compression Machine
        ↓
     Deduster
        ↓
  Metal Detector
        ↓
   Checkweigher
        ↓
Collection

OQ should challenge critical line interactions where within qualification scope.

10.68 Reject-System Qualification

For a tablet compression system, reject mechanisms may directly affect product quality.

Potential challenges:

• defined reject condition;
• reject activation;
• physical rejection;
• reject confirmation;
• reject count;
• alarm;
• failure condition;
• recovery.

10.69 Reject Challenge Philosophy

The test should demonstrate:

Known unacceptable/test-condition unit → Correct detection → Correct reject command → Physical segregation → Appropriate record/indication

where this is the intended system design.

10.70 Tablet Compression Machine — Critical OQ Parameters

For the handbook’s tablet compression machine example, important OQ areas may include:

• turret speed;
• feeder speed;
• fill depth;
• pre-compression force;
• main compression force;
• tablet-weight control;
• lubrication;
• motor operation;
• reject mechanism;
• guards;
• emergency stops;
• alarms;
• interlocks;
• recipes;
• user access;
• audit trails;
• power recovery;
• interfaces.

The exact parameters and acceptance limits must come from the approved URS/design/process requirements.

10.71 Compression Machine OQ Matrix

10.72 Example Full OQ Test — Turret Speed

Test ID

OQ-PAR-001

Title

Turret Speed Operating Range Verification

Objective

Verify that the compression machine operates and controls turret speed throughout the approved operating range.

Prerequisites

• IQ completed;
• speed-measurement system calibrated;
• approved operating range available;
• test tachometer calibrated where used.

Method

1. Set machine to approved lower test speed.
2. Allow speed to stabilize.
3. Record displayed value.
4. Record independent measured value where required.
5. Repeat at nominal condition.
6. Repeat at approved upper test speed.
7. Observe stability and abnormal behavior.

Expected Result

The machine shall operate at each defined test point according to approved specifications.

Actual Results

Acceptance Criteria

Results shall comply with approved speed-control requirements.

Evidence

Protocol readings and calibrated test-instrument details.

Status

PASS / FAIL

10.73 Example Full OQ Test — Guard Interlock

Test ID

OQ-INT-002

Objective

Verify the designated safety guard interlock operates according to approved requirements.

Method

1. Confirm guard closed.
2. Start equipment under approved safe conditions.
3. Open guard.
4. Observe machine response.
5. Attempt restart with guard open.
6. Close guard.
7. Perform reset.
8. Verify restart behavior.

Acceptance Criteria

System response shall conform to the approved interlock specification.

Evidence

Executed test record and relevant supporting evidence.

10.74 Example Full OQ Test — Recipe Access

Test ID

OQ-CSV-010

Objective

Verify that recipe modification is restricted according to the approved user-role matrix.

Method

1. Login as Operator.
2. Attempt to modify restricted recipe parameter.
3. Record system response.
4. Login as authorized role.
5. Modify permitted test parameter.
6. Save recipe.
7. Review applicable audit trail.
8. Restore approved test configuration.

Acceptance Criteria

• unauthorized modification prevented;
• authorized modification permitted;
• applicable change recorded according to approved requirements.

10.75 Example Full OQ Test — Power Recovery

Test ID

OQ-FLT-005

Objective

Verify equipment response and recovery following loss of electrical power.

Method

1. Establish defined operating state.
2. Record active recipe/configuration.
3. Initiate controlled power interruption.
4. Observe equipment response.
5. Restore power.
6. Observe startup state.
7. Verify retained configuration/data as applicable.
8. Verify no unintended automatic restart.
9. Verify relevant event/alarm record where specified.

Acceptance Criteria

System response and recovery shall comply with approved functional requirements.

10.76 Example Full OQ Test — Audit Trail

Test ID

OQ-DI-004

Objective

Verify generation of the required audit record following modification of a GMP-relevant parameter.

Method

1. Login using authorized test account.
2. Record original parameter value.
3. Change parameter to approved test value.
4. Save change.
5. Access audit trail.
6. Identify corresponding event.
7. Verify required event information.
8. Restore original value under controlled conditions.
9. Verify restoration event.

Acceptance Criteria

The applicable audit record shall contain the information required by the approved system specification.

10.77 Test Instruments During OQ

Test instruments should be suitable for their intended measurement.

Record:

• instrument name;
• ID;
• range;
• resolution where relevant;
• calibration status;
• due date.

Example:

10.78 Measurement Uncertainty and Accuracy

For critical measurements, qualification design should consider whether the test instrument can meaningfully verify the acceptance criterion.

Example:

If an acceptance criterion is extremely narrow, a low-accuracy reference instrument may be incapable of proving compliance.

The measurement method should therefore be technically appropriate.

10.79 Repetition

Some tests may require repetition to demonstrate repeatability.

Examples:

• reject mechanism;
• alarm activation;
• sequence;
• control loop;
• automated adjustment.

The number of repetitions should be justified based on risk and test objective rather than automatically choosing three.

10.80 OQ Deviations

An OQ deviation occurs when:

• expected result is not achieved;
• acceptance criterion fails;
• protocol cannot be followed;
• unexpected behavior occurs;
• configuration changes;
• test equipment becomes unsuitable;
• data are missing.

The deviation should be documented contemporaneously.

10.81 Failed OQ Test

A failed test is not automatically proof that the equipment is permanently unacceptable.

It means:

The predefined qualification expectation was not demonstrated.

The next steps are:

Document → Assess → Investigate → Correct → Assess Impact → Retest → Disposition

10.82 Do Not Test Into Compliance

Unacceptable:

Fail → Adjust → Repeat → Fail → Adjust → Repeat → Pass → Record only Pass.

Correct:

Retain all results and document why adjustments/retests occurred.

Qualification must show what actually happened.

10.83 Software Changes During OQ

If a software defect is discovered during OQ:

1. document the failure;
2. assess GMP impact;
3. raise appropriate change/deviation;
4. define software modification;
5. identify new version;
6. perform impact assessment;
7. determine regression scope;
8. execute regression tests;
9. repeat affected OQ tests;
10. establish final baseline.

10.84 Regression Testing

Suppose the vendor modifies reject logic.

Potentially affected functions include:

• reject trigger;
• reject output;
• reject confirmation;
• counts;
• alarm;
• audit trail;
• downstream interface.

Testing only the one failed screen would likely be insufficient.

Regression testing should follow impact assessment.

10.85 Configuration Control During OQ

OQ should be executed against a known configuration.

Control:

• software version;
• recipe version;
• parameter configuration;
• user roles;
• alarm set points;
• interlock configuration;
• network configuration.

Otherwise, different OQ tests could unknowingly be executed against different system states.

10.86 Raw Data

OQ raw data may include:

• instrument readings;
• electronic records;
• screenshots;
• audit trails;
• alarm history;
• trend records;
• printouts;
• calculations;
• reports.

Raw data should be attributable and linked to the applicable test.

10.87 Screenshots

For computerized systems, screenshots may be valuable but should be controlled.

A screenshot should identify, where practical:

• system;
• test;
• relevant screen;
• date/time;
• user/context.

Avoid excessive screenshots with no defined purpose.

10.88 Calculations

If OQ includes calculations:

• define formula;
• define units;
• identify source data;
• verify calculation;
• document rounding rules where important.

Spreadsheet-based qualification calculations may themselves require appropriate control depending on use and risk.

10.89 FAT Evidence in OQ

FAT may already contain extensive functional testing.

OQ should therefore decide:

Repeat, Verify, Reference, or Leverage?

This should be based on:

• criticality;
• site dependency;
• configuration changes;
• FAT evidence quality;
• transportation impact;
• installation impact.

10.90 Example of FAT Leverage

FAT

PLC calculation comprehensively challenged.

Site

• identical approved software version confirmed;
• no relevant changes;
• calculation independent of site hardware.

OQ Strategy

Potentially reference controlled FAT evidence and perform appropriate site verification rather than duplicating every calculation test.

The strategy should be predefined and justified.

10.91 Example Requiring OQ Retest

FAT

Low compressed-air interlock tested.

Site

Different site air supply, piping and pressure switch connection.

Therefore:

Site OQ challenge is appropriate because actual installed conditions can affect the function.

10.92 OQ Traceability

Every critical requirement should be traceable to qualification evidence.

Example:

The objective is not to test every requirement repeatedly.

It is to demonstrate:

Every applicable requirement has adequate objective evidence.

10.93 Risk-to-OQ Traceability Example

URS

Machine shall automatically reject tablets meeting defined reject criteria.

↓

Risk

Failure could permit identified nonconforming units to enter the accepted product stream.

↓

Design

PLC-controlled reject mechanism.

↓

FAT

Basic reject logic verified.

↓

IQ

Reject components installed and identified.

↓

OQ

Challenge:

• reject trigger;
• physical rejection;
• confirmation;
• count;
• alarm;
• failure response.

↓

PQ

Demonstrate performance under representative process conditions where applicable.

This is strong lifecycle qualification.

10.94 OQ Summary Report

The OQ report should summarize:

1. objective;
2. scope;
3. protocol executed;
4. test results;
5. operating ranges tested;
6. alarms/interlocks tested;
7. computerized functions tested;
8. deviations;
9. retests;
10. software changes;
11. regression tests;
12. outstanding items;
13. traceability;
14. final configuration;
15. conclusion;
16. PQ readiness.

10.95 Example OQ Summary

Original failures and retest histories should remain visible in the qualification package.

10.96 PQ Readiness

Before progression to PQ, confirm as applicable:

• □ OQ completed
• □ Critical OQ tests passed
• □ Critical deviations closed
• □ Final software configuration controlled
• □ Required regression testing completed
• □ Operating ranges established
• □ Critical alarms verified
• □ Critical interlocks verified
• □ Failure/recovery behavior acceptable
• □ User access verified
• □ Data-integrity controls verified as applicable
• □ Required SOPs available
• □ Operators appropriately trained
• □ PQ protocol approved
• □ Remaining open items assessed

10.97 OQ Does Not Establish Process Performance

Successful OQ demonstrates that equipment/system functions correctly.

It does not necessarily demonstrate that:

• tablets meet commercial quality attributes;
• a manufacturing process is validated;
• cleaning is validated;
• operators can reproducibly manufacture commercial batches.

Those may require PQ/process validation/other validation activities.

10.98 OQ vs PQ Example

OQ

Challenge tablet compression machine:

• turret speed;
• feeder speed;
• compression controls;
• alarms;
• interlocks;
• reject system.

PQ

Operate equipment under defined representative production conditions and demonstrate that it performs effectively for intended use.

Thus:

OQ challenges equipment capability and controls.

PQ demonstrates performance in the intended operational/process context.

10.99 OQ and SOPs

OQ may identify operating controls and failure responses that need to be incorporated into SOPs.

Examples:

• startup;
• shutdown;
• alarm handling;
• emergency response;
• recipe selection;
• user access;
• backup;
• recovery.

Qualification and procedural controls should be aligned.

10.100 OQ and Training

Personnel involved in execution should be trained according to their assigned responsibilities.

Before routine GMP operation, relevant personnel should be trained on approved procedures.

Training should cover applicable:

• normal operation;
• alarm response;
• cleaning;
• changeover;
• computerized-system use;
• data-integrity expectations.

10.101 Inspector Perspective — Operating Range

An inspector may ask:

How did you determine the range over which this machine was qualified?

A strong response should connect:

URS → Process/Equipment Requirements → Risk Assessment → OQ Test Range → Results

The organization should not rely on an undocumented vendor capability range.

10.102 Inspector Perspective — Alarm

An inspector may ask:

Show me how you qualified this critical alarm.

Expected evidence:

Requirement → Alarm Set Point → Test Method → Actual Trigger → Machine Response → Alarm Record → Result

Simply showing an alarm list is not qualification.

10.103 Inspector Perspective — Failure

An inspector may ask:

What happens if power fails during operation?

The answer should come from:

• approved design;
• risk assessment;
• executed OQ test;
• SOP/recovery procedure.

Not from operator assumption.

10.104 Inspector Perspective — User Access

An inspector may ask:

Can an operator change this critical recipe parameter?

A strong answer should show:

• user-role matrix;
• OQ challenge;
• system configuration;
• applicable audit-trail evidence.

10.105 Inspector Perspective — Audit Trail

An inspector may ask:

Show me what happens when an authorized user changes this parameter.

The organization should be able to demonstrate:

Login → Change → Save → Audit Record → User → Timestamp → Change Details

according to the system’s approved requirements.

10.106 Inspector Perspective — Software Change

An inspector may ask:

Was the software changed during qualification?

The organization should be able to reconstruct:

FAT Version → SAT Version → IQ Baseline → OQ Change → Regression Testing → Final Qualified Version

This is why configuration management is essential.

10.107 Common OQ Deficiencies

10.108 OQ Inspection-Readiness Checklist

Prerequisites

• □ IQ status acceptable
• □ Approved OQ protocol
• □ Critical deviations closed
• □ Utilities available
• □ Instruments calibrated
• □ Test equipment calibrated
• □ Software baseline controlled
• □ Personnel trained

Operating Functions

• □ Power ON/OFF
• □ Startup
• □ Shutdown
• □ Manual mode
• □ Automatic mode
• □ Controls
• □ Displays

Parameters

• □ Critical parameters identified
• □ Lower range tested
• □ Nominal condition tested
• □ Upper range tested
• □ Parameter limits challenged
• □ Set vs actual recorded
• □ Worst-case conditions justified

Alarms

• □ Critical alarms identified
• □ Trigger challenged
• □ Set point verified
• □ Alarm text verified
• □ Machine response verified
• □ Acknowledgement verified
• □ Reset verified
• □ History verified where applicable

Interlocks and Permissives

• □ Guard interlocks
• □ Utility permissives
• □ Process interlocks
• □ Startup permissives
• □ Restart controls

Failure/Recovery

• □ Power failure
• □ Utility failure
• □ Sensor failure where applicable
• □ Communication failure
• □ Peripheral failure
• □ Recovery
• □ Data retention

Automation

• □ PLC
• □ HMI
• □ SCADA
• □ Sequences
• □ Calculations
• □ Timers/counters
• □ Interfaces

Data Integrity

• □ Unique users
• □ Role permissions
• □ Password controls
• □ Audit trails
• □ Electronic records
• □ Reports
• □ Date/time
• □ Backup
• □ Restore

Closure

• □ Actual results recorded
• □ Raw data retained
• □ Deviations documented
• □ Failed results retained
• □ Retests authorized
• □ Software changes controlled
• □ Regression testing complete
• □ Traceability updated
• □ Final baseline identified
• □ OQ report approved
• □ PQ readiness established

10.109 OQ Decision Tree

OQ Execution Complete
        ↓
Critical Test Failure?
    ┌───┴───┐
   Yes      No
    │        ↓
 Hold PQ   Open Items?
    │       ┌──┴──┐
Investigate Yes   No
    │       │      │
Correct   Assess   ↓
    │     Impact  OQ Acceptable
    ↓       │      │
Retest      │      ↓
    │       └──→ PQ Readiness
    ↓
Regression Testing
    ↓
Close

10.110 Golden Rule of Operational Qualification

The central principle is:

Do not merely demonstrate that the equipment works. Challenge the functions that protect product quality, patient safety, data integrity, process control, and reliable operation—and demonstrate with objective evidence that the system behaves correctly at normal, boundary, abnormal, and failure conditions.

Part 10 — Key Takeaway

Operational Qualification transforms the IQ-established installed baseline into a demonstrated functional baseline.

A strong OQ establishes ten major areas:

1. Operating Capability
The equipment operates correctly throughout the approved range.

2. Boundary Control
Upper/lower limits and parameter restrictions function as designed.

3. Sequence Control
Automated sequences and permissives operate correctly.

4. Alarm Control
Critical abnormal conditions are detected and appropriately communicated.

5. Interlock Protection
Critical equipment/process/safety interlocks perform correctly.

6. Failure Management
The system behaves predictably during power, utility, sensor, communication, and other credible failures.

7. Recovery
The system returns to an appropriate controlled state following failure.

8. Automation and Data Integrity
Applicable PLC/HMI/SCADA, recipes, access controls, audit trails, records, reports and backup/restore functions operate as intended.

9. Configuration Integrity
The final hardware/software/configuration tested during OQ is known and controlled.

10. PQ Readiness
Critical functional deficiencies are resolved before performance qualification begins.

The lifecycle evidence chain is now:

URS → Risk Assessment → DQ → FAT → SAT → IQ Installed Baseline → OQ Functional Baseline → PQ Performance Evidence → Qualification Summary → GMP Release

Next: Part 11 — Performance Qualification (PQ)

Part 11 should establish whether the equipment/system performs effectively and reproducibly under intended operating/process conditions, including:

PQ prerequisites → routine operating conditions → representative/worst-case conditions → product/placebo/load selection → critical process parameters → critical quality attributes → sampling strategy → acceptance criteria → number of runs/cycles → statistical evaluation where appropriate → deviations → continued qualification → final PQ report and release decision.

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.