If you work anywhere near pharmaceutical manufacturing, biotech, food production, or any regulated industrial environment, you’ve run into the term IQOQ.
It shows up on equipment purchase orders, in validation master plans, and in emails from quality assurance asking, “Where’s the IQOQ documentation for this skid?”
For control systems engineers coming from a general industrial automation background, IQOQ can feel like a different language layered on top of familiar work.
Commissioning, testing, and documenting a system you already know how to build. That’s not far off.
IQOQ is essentially rigorous, auditable commissioning, done in a specific order, with paper trails that regulators can trust.
This guide breaks down what IQOQ means, how it applies to PLCs, HMIs, and building/process control systems, and where engineers commonly trip up.
What Does IQOQ Stand For?
IQOQ is shorthand for Installation Qualification (IQ) and Operational Qualification (OQ), two phases in the equipment and system validation lifecycle used in regulated industries such as pharmaceuticals, medical devices, food and beverage, and biotechnology.
- Installation Qualification (IQ) confirms that equipment and systems are installed correctly, according to the manufacturer’s specifications and the approved design documentation.
- Operational Qualification (OQ) confirms that the equipment operates as intended, across its specified operating ranges, once it’s installed.
Together, IQ and OQ form documented, objective evidence that a piece of equipment a PLC-controlled skid, an HVAC system, a filling line, or a cleanroom air handler was built right and works right before it’s ever used to make or handle a regulated product.
IQOQ almost always sits inside a broader validation framework that also includes:
- DQ: Design Qualification: confirms the design meets user requirements before anything is built or installed
- PQ: Performance Qualification: confirms the system performs consistently under real production conditions, with real product, over time
So the typical sequence an automation engineer will encounter is DQ → IQ → OQ → PQ, sometimes bundled and referred to loosely as “IQOQ” or “IQ/OQ/PQ” depending on the site’s quality system.
Why IQOQ Exists
Regulators, the FDA, EMA, and equivalent bodies, don’t take a manufacturer’s word that a system works.
They require documented proof. This comes from Good Manufacturing Practice (GMP) requirements and, in the US, guidance from 21 CFR Part 211 for pharmaceutical manufacturing and process validation expectations under the FDA’s process validation guidance.
For control systems specifically, IQOQ answers two blunt questions an auditor will ask:
- Is this system built the way it was supposed to be built?
- Does it perform as intended, reliably, across its full operating range?
If you can’t answer both with signed, dated, reviewed documentation, the system and potentially the product it touches aren’t considered validated, regardless of how well it actually runs on the floor.
Installation Qualification (IQ): What Gets Checked
IQ is a physical and documentation-level verification. It happens after installation but before the system is powered up and tested functionally. A typical IQ protocol for a control system or automated skid verifies the following.
- Equipment identification: correct model, serial numbers, and revision levels match purchase specifications
- Component verification: PLCs, HMIs, sensors, actuators, VFDs, and I/O modules match the approved bill of materials
- Installation conditions: wiring, grounding, panel layout, and enclosure ratings meet the design drawings and applicable codes (NEC, NFPA 70, or local equivalents)
- Utilities and services: power supply specifications, compressed air, network connections, and instrument air match design requirements
- Software and firmware: Correct PLC program version, HMI application version, and firmware revisions are installed and match the released, version-controlled source
- Calibration status: instruments (sensors, transmitters, gauges) have current, traceable calibration certificates
- Drawing accuracy: as-built P&IDs, electrical schematics, and network architecture diagrams match what’s physically installed
- Documentation package: manuals, spare parts lists, and vendor certificates are on file
IQ is asking, “Is this exactly what we specified, exactly where and how we specified it?” Nothing is tested for function yet. This step is purely about installed correctness.
Operational Qualification (OQ): What Gets Checked
Once IQ is signed off, OQ verifies the system actually functions correctly across its intended operating range.
For control systems, this phase is where an automation engineer’s normal commissioning instincts map directly onto the qualification protocol. OQ typically covers:
Functional testing of control logic
Every interlock, alarm, permissive, and sequence step is tested against the functional specification, including edge cases.
Alarm and interlock verification
High/low setpoints, safety interlocks, and critical alarms trigger correctly and at the correct thresholds.
Operating range testing
The system is exercised across its full specified range (temperature, pressure, speed, flow), not just at nominal setpoints.
Failure mode testing
What happens on power loss, sensor failure, communication loss, or E-stop, and whether the system fails to a safe state.
User access and security
Login levels, audit trails, and electronic records comply with requirements like 21 CFR Part 11 where applicable
Recipe and setpoint verification
For systems with recipe-driven control, confirming parameters load and execute correctly
Data integrity checks
Confirming logged data, alarms, and audit trails are accurate, timestamped, and tamper-evident.
If IQ confirms “it’s built right,” OQ confirms “it does what it’s supposed to do, every time, across the full range it’s designed for.”
A system can pass IQ and still fail OQ. For example, wiring and components match the drawings perfectly, but an interlock doesn’t trip at the specified setpoint because of a logic error or a miscalibrated sensor.
IQOQ vs. PQ: Where the Line Is
This distinction trips people up constantly, so it’s worth being precise.
| Qualification Stage | Core Question | When It Happens | Typical Test Conditions |
|---|---|---|---|
| IQ (Installation) | Is it installed correctly? | Right after installation, before power-up testing | Static visual/documentation checks |
| OQ (Operational) | Does it function correctly across its range? | After IQ passes, before production use | Dynamic system run empty or with test media, across full operating range |
| PQ (Performance) | Does it perform consistently in real production? | After OQ passes, using real product/process | Dynamic real product, real production conditions, multiple runs |
OQ tests the system’s capability to maintain setpoints, while PQ assesses whether the batch consistently meets specifications during operation.
OQ is largely engineering-driven; PQ usually pulls in process and quality teams more heavily.
A Simplified IQOQ Protocol Structure
Most IQOQ protocols, regardless of industry, follow a similar document skeleton:
- Purpose and scope: what system, what boundaries.
- Roles and responsibilities: who executes, who reviews, who approves.
- Prerequisites: training completed, documentation available, calibration current.
- IQ test cases: numbered, with acceptance criteria and space for actual results.
- OQ test cases: numbered, with acceptance criteria, expected results, and actual results.
- Deviation log: any failed test case, its root cause, and resolution.
- Summary and approval: sign-off from engineering, quality, and often the equipment owner.
Every test case needs a predefined, objective acceptance criterion written before testing starts. “Alarm triggers at 85°C ± 1°C and displays on HMI within 2 seconds” is a testable criterion. “Alarm works correctly” is not a testable criterion, and an auditor will flag it.
Common Places Engineers Get Tripped Up on IQ/OQ
Here are a few recurring issues from the field, especially for engineers new to validated environments.
Testing before documentation is finalized
If drawings or the functional specification changes after OQ testing starts, the protocol needs a formal deviation or revision. You can’t just quietly retest and move on.
Vague acceptance criteria
Every test step needs a specific, measurable pass/fail condition. “The system should respond appropriately” will get rejected in review.
Skipping failure mode testing
It’s tempting to only test the happy path. OQ specifically wants to see what happens when something goes wrong sensor failure, network dropout, power interruption and that the system fails safely.
Software version mismatches
The PLC program or HMI application tested during OQ must be the exact version that goes into production.
Any post-OQ code change, even a minor tweak, typically requires re-qualification of the affected functions.
Treating IQOQ as a one-time event
Significant changes to a validated system, a firmware update, a new sensor, or a logic change generally trigger a re-validation assessment, not just a change request in the maintenance log.
Who’s Involved in IQOQ Execution
IQOQ isn’t usually a solo effort. A typical execution team includes:
- Automation/controls engineer: executes functional and logic testing, often writes the OQ test scripts.
- Quality assurance: reviews and approves protocols and results and ensures compliance with the site’s validation master plan.
- Equipment vendor/OEM: frequently supports or co-executes IQ, especially for skid-mounted or packaged systems.
- Metrology/calibration team: provides calibration certificates and may execute instrument-specific checks.
- Process/production engineering: defines operating ranges and acceptance criteria tied to actual process needs.
FAQ
Is IQOQ the same as commissioning?
No, though they overlap. Commissioning is the general process of getting a system running correctly.
IQOQ is the formal, documented subset of that work required for regulatory compliance in validated environments.
You can commission a system without ever generating IQOQ paperwork, but you can’t complete IQOQ without effectively commissioning the system first.
Does every control system need IQOQ?
No, IQOQ is required for equipment and systems that touch a regulated product or process in pharmaceutical, biotech, medical device, and certain food/beverage applications.
A general industrial or building automation system outside a regulated GxP environment typically doesn’t require formal IQOQ, though many companies apply similar rigor voluntarily for critical systems.
Who writes the IQOQ protocol, engineering or quality?
It’s usually collaborative. Engineering typically drafts the technical test cases based on design and functional specifications, while quality assurance reviews, standardizes format, and ensures the protocol meets the site’s validation procedures before execution.
What happens if a test case fails during OQ?
It gets logged as a deviation, investigated for root cause, corrected, and retested either the specific failed case or, depending on the site’s SOP, the full test sequence. The deviation and resolution become part of the permanent validation record.
Can IQ and OQ be combined into one document?
Yes, this practice is common, especially for smaller systems or less complex equipment. Hence the combined term “IQOQ.”
Larger or higher-risk systems often keep them as separate protocols executed sequentially.
The Bottom Line
IQOQ isn’t a separate skill set from good controls engineering. It’s controls engineering with the documentation discipline that regulated industries require.
If you already write clear functional specifications, test interlocks methodically, and version-control your PLC code, you’re most of the way to IQOQ-ready work.
The remaining gap is almost always documentation rigor: predefined acceptance criteria, traceable version control, and a paper trail an auditor who’s never met you can follow from design intent to tested result.
