What Is Operational Qualification? OQ Tests and Example

Operational qualification (OQ) is the documented verification that a piece of equipment, a system, or a utility operates as intended throughout its specified operating ranges. It comes after installation qualification (IQ), which proves the equipment was installed correctly, and before performance qualification (PQ), which proves it performs consistently under routine production conditions. An OQ challenges the equipment's functions, alarms, interlocks, and control system, and it tests critical parameters at the lower and upper limits of the range production will rely on, plus worst-case conditions, against acceptance criteria written and approved before testing starts. When the OQ passes, you have objective evidence that the operating window is real, and that is the evidence that lets you finalize operating procedures, train operators, and move into PQ.

This article covers what that means in practice: what an OQ tests, a worked example, how OQ differs from IQ and PQ, failures, protocol structure, and common audit findings. If you are ready to draft one, the step-by-step guide on how to write an OQ protocol from scratch picks up where this article leaves off.

What the regulations say OQ is

EU GMP Annex 15 (2015), in its section on qualification stages, describes OQ as normally following IQ, with the option of performing them together as an installation and operational qualification (IOQ) depending on the complexity of the equipment. It expects OQ to include tests developed from knowledge of the processes, systems, and equipment to show the system operates as designed, and tests to confirm upper and lower operating limits and/or worst-case conditions. It also expects the completion of a successful OQ to allow the finalization of standard operating procedures and cleaning procedures, operator training, and preventive maintenance requirements.

The GHTF process validation guidance for medical devices (SG3/N99-10:2004) defines OQ in terms of establishing, by objective evidence, process control limits and action levels that result in product meeting all predetermined requirements. That ties the equipment test directly to the product.

The FDA's 2011 guidance, "Process Validation: General Principles and Practices," does not organize itself around the IQ/OQ/PQ labels. It places the qualification of utilities and equipment inside Stage 2, process qualification, ahead of process performance qualification.

For medical device manufacturers, the underlying requirement is ISO 13485:2016 clause 7.5.6, which requires validation of production processes whose output cannot be, or is not, verified by subsequent monitoring or measurement. Since February 2, 2026, the FDA Quality Management System Regulation has incorporated ISO 13485:2016 by reference into 21 CFR Part 820, so that clause now anchors the US requirement. Older documents citing 21 CFR 820.75 reflect the pre-QMSR regulation, not the current citation.

Where OQ sits in the qualification sequence

Each qualification stage answers one question, and OQ only makes sense next to its neighbors.

• Design qualification (DQ) asks whether the proposed design is suitable for its intended purpose, before anything is bought or built. The design qualification guide covers it in depth.
• Installation qualification (IQ) asks whether the equipment was delivered and installed to specification: components, utilities, documentation, calibration status.
• Operational qualification (OQ) asks whether the equipment operates as intended across its specified ranges, including at the limits and under worst-case conditions.
• Performance qualification (PQ) asks whether the equipment, used the way production will use it, consistently produces acceptable results over time.
• Process performance qualification (PPQ), in the FDA lifecycle model, asks whether the full commercial process, running on qualified equipment with trained staff and approved materials, consistently produces conforming product. The PPQ protocol guide explains how PPQ relates to equipment PQ.

OQ is the stage where the equipment is first pushed: running it, driving it to its limits, forcing alarm conditions, and recording what happens. For a detailed side-by-side of the three core stages, see IQ vs OQ vs PQ: what actually goes in each one.

What an OQ tests

OQ content is driven by the equipment's requirements and a risk assessment of which functions and parameters can affect product quality. Most OQs draw from five families of tests.

Functional tests. Every required function is exercised and its result recorded: start and stop, mode changes, cycle selection, emergency stop, manual and automatic operation, power-failure recovery.

Alarms and interlocks. Every alarm and safety or quality interlock that protects the product or the process is deliberately triggered, and the response is verified. An alarm that has never been forced is an alarm you are assuming works.

Operating ranges at low, nominal, and high. Critical parameters are tested across the range production intends to use. The common convention is three points: the lower limit, the routine setpoint, and the upper limit. If the equipment performs acceptably at both edges, the range between them is supported by evidence. The ranges come from process requirements, not from the machine's nameplate, and choosing them well is its own discipline, covered in how to set OQ machine parameters.

Worst-case conditions. Some failures only appear when conditions combine, such as fastest speed with shortest dwell. Annex 15 asks for tests at operating limits and/or worst-case conditions, and its glossary bounds worst case to conditions within standard operating procedures that pose the greatest chance of failure. A worst-case test is the hardest condition production is allowed to create, not a stress test to destruction.

Control system and data checks. Where the equipment is controlled by software or records data, the OQ verifies that the control system behaves as specified: setpoint entry and limits, recipe or program selection, user access levels, audit trail entries for changes, data capture and storage, time and date accuracy, and report output. Where those records are required by FDA regulations and kept electronically, 21 CFR Part 11 applies to the electronic records and signatures, with EU GMP Annex 11 as the EU counterpart, and the system's validation should demonstrate those controls. Larger computerized systems often get their own validation, which the equipment OQ references.

Acceptance criteria: what makes an OQ result count

An OQ test is only as good as the criterion it is judged against. Acceptance criteria are written before execution, approved with the protocol, and stated so that anyone can compare a recorded result to them and reach the same verdict.

A usable criterion has a measurable value, units, a tolerance, and a source. "Chamber temperature stable" is not a criterion. "All probe readings within plus or minus the specified tolerance of setpoint throughout the hold period, per the user requirement specification" is one, because it names what is measured, the limit, and where the limit came from. Sources are usually the user requirement specification, the process specification, the equipment specification, or a referenced standard. The guide on acceptance criteria that won't get flagged in an audit covers the common weaknesses.

The partner to the criterion is the recorded result. The expected result is fixed before execution; the actual result is recorded as observed, at the time, by the person who performed the step, with raw data attached where an instrument produced it. A column of ticks reading "pass" is not a result. The post on expected vs actual results in an OQ protocol shows how to write both sides so the comparison holds up.

A worked example: OQ on a controlled-temperature chamber

Consider a controlled-temperature chamber used to condition components before assembly. Its requirements say it must hold a defined setpoint range, alarm on excursions, recover after door openings within a specified time, and keep an electronic temperature record. IQ has already confirmed the hardware matches the specification and the measuring instruments are calibrated. The OQ then runs, broadly, these tests:

1. Functional checks. Setpoint entry, start and stop, controller display against a calibrated reference, power-failure behavior and restart.
2. Alarm and interlock challenges. High and low temperature alarms are forced by inducing an excursion, and the protocol records whether each alarm annunciates, is logged, and notifies as specified. The door-open alarm delay is verified.
3. Operating range. The empty chamber is run at the lower limit of its claimed range, at the routine setpoint, and at the upper limit. At each setpoint, calibrated probes distributed through the working volume record temperature over a defined hold period. The acceptance criterion is that every probe stays within the specified tolerance throughout the hold.
4. Worst case. At the most demanding permitted condition, such as the setpoint furthest from ambient with a defined door opening, recovery time back into the band is measured against its limit.
5. Data and control checks. The electronic record matches the reference readings, setpoint changes appear in the audit trail with user and time, access levels block unauthorized changes, and records can be retrieved.

Notice what is missing: the chamber is not loaded the way production will load it. Loaded thermal performance under routine use belongs in PQ, typically through a mapping study of the kind described in the temperature mapping guide. OQ proves the chamber can hold its window; PQ proves it does in real use.

OQ vs IQ

IQ is about what is there. OQ is about what it does. An IQ verifies model and serial number, materials, utility connections, software version, documentation, and instrument calibration. An OQ assumes all of that is correct and exercises the equipment. A calibration check of a temperature probe is IQ. A test that the controller holds temperature within tolerance at three setpoints is OQ. Confirming that the software version installed is the one specified is IQ. Confirming that the software rejects a setpoint outside its configured limits is OQ.

OQ vs PQ

OQ tests the equipment's capability across its range, often empty or with a surrogate load, under controlled test conditions, typically run by engineering or validation staff. PQ tests the equipment's performance under the conditions production will actually create: real or representative product, routine procedures, trained production operators, and enough repetition to show consistency.

Put another way, OQ answers "can it?" and PQ answers "does it, reliably, in real use?" Some equipment needs both. Some equipment with no direct product quality impact needs no PQ at all, which is a documented risk decision rather than an omission.

Combined IOQ and OQ/PQ protocols

IOQ. Annex 15 allows IQ and OQ to be performed together as an installation and operational qualification depending on the complexity of the equipment. It is common for simpler equipment. The protocol still needs a gate: the installation checks that OQ depends on, such as calibration of measuring instruments, must pass before the dependent operational tests are executed.

OQ/PQ. Annex 15 states that PQ should normally follow successful IQ and OQ, but that it may in some cases be appropriate to perform it in conjunction with OQ or process validation. A combined OQ/PQ works when the performance demonstration can run straight after the range challenges with the same materials and team. The trade-offs, and the hold points a combined protocol needs, are covered in combined vs separate OQ/PQ protocols.

Whichever packaging you choose, record the choice and the rationale in the validation master plan or the equipment qualification plan, so the structure reads as a decision.

When an OQ test fails

A failed OQ test is information, and the protocol has a defined path for it. The actual result is recorded exactly as observed. The failure is documented as a deviation and investigated under your deviation procedure, which is what Annex 15 expects for results that fail pre-defined acceptance criteria. The investigation establishes the cause, whether equipment fault, setup error, test method problem, or a wrong criterion, and assesses impact on tests already executed.

Corrective action follows the cause. An equipment fault is repaired and affected tests repeated. An execution error may justify a recorded retest. A criterion that was genuinely wrong is changed only through a documented, justified protocol change, never by editing the number to fit the data. The final report summarizes every deviation and its resolution, and states whether the OQ supports release to the next stage. Annex 15 allows a conditional, documented release to the next stage where an open item is assessed as having no significant impact on it.

What an OQ protocol contains, section by section

People searching for an "OQ template" usually want to know the structure. Specific headings vary by company procedure, but a complete OQ protocol carries these sections:

• Approval page. Author, reviewers, and approvers, including quality, with signatures before execution.
• Purpose and scope. The equipment or system, its identifier and location, and what this protocol covers and excludes.
• References. User requirements, functional and design specifications, the DQ and IQ, the risk assessment, the validation master plan, and governing SOPs.
• System description. What the equipment does, its main components, and its control system.
• Responsibilities. Who executes, who reviews, who approves.
• Prerequisites. IQ approved or the relevant IQ items closed, measuring instruments calibrated, SOPs in draft, test personnel trained.
• Test equipment. Reference instruments used, with identifiers and calibration due dates.
• Test cases. For each test: objective, method, step-by-step instructions, expected result with its source, space for the actual result, pass or fail, executor signature and date. Each test traces to a requirement.
• Deviation handling. How failures and protocol departures are recorded and resolved.
• Traceability. A matrix linking requirements and risks to test cases, often as part of a wider traceability matrix.
• Summary report. Results, deviations and their closure, conclusion, and approval for release to the next stage.

The order and depth of each section, and how to write the test cases, are covered in how to write an OQ protocol from scratch.

Common OQ audit findings

The weaknesses auditors find in OQs repeat across industries. These are the ones worth checking your own protocols against.

• Vague acceptance criteria. "Operates correctly" or "within specification" with no number and no source.
• Ranges from the nameplate. Limits tested at the machine's capability rather than the range production uses, or production running outside the range that was tested.
• Alarms listed but not challenged. The protocol confirms an alarm is configured but never forces it.
• Results without evidence. Pass marks with no recorded values or raw data, or results entered after the fact.
• Criteria changed after data. Acceptance criteria edited during execution without a deviation and justification.
• Unresolved deviations. Deviations opened and never closed, or closed without an impact assessment, while the equipment moved into PQ or production.
• No trace to requirements. Tests that cannot be linked to any requirement or risk, and requirements no test covers.
• Uncalibrated test instruments. Reference instruments past their calibration due date at the time of testing.
• Control system gaps. No verification of audit trail, access control, or data integrity on equipment that holds electronic GMP records.

How Valiqa fits

Valiqa generates OQ protocols from equipment specifications, with acceptance criteria and regulatory mappings drafted for review and approval by your team. Approvals use Part 11 electronic signatures, every action is recorded in a hash-chained audit trail, and execution runs as guided step-by-step testing, so actual results are captured against the approved expected results at the time of performance.

The short version

Operational qualification is where equipment proves it can do what its specification claims, across the range production will rely on, including the edges and the worst case. Get the range right, challenge every alarm that matters, write criteria someone else could judge, and treat every failure as a deviation with a cause. That is an OQ that holds up.

---

Valiqa is an AI-powered validation lifecycle platform for regulated manufacturing. Learn more at valiqa.io

Get new validation guides in your inbox

One or two practical guides a week, written for validation engineers. Unsubscribe anytime.