IQ OQ PQ Explained:
A Practical Guide for
Automation Engineers

What is IQ OQ PQ?

IQ, OQ, and PQ stand for Installation Qualification, Operational Qualification, and Performance Qualification. Together they form the core of the qualification lifecycle for any automated system installed in a GMP-regulated pharmaceutical environment.

Think of them as three layers of evidence. Each layer proves something increasingly important to the regulator: first that the system was built correctly, then that it works correctly, then that it performs correctly under real production conditions.

The Three Phases

Before diving into what each protocol contains, it helps to understand the intent behind each one.

Where DQ Fits

You will see this written both ways: IQ/OQ/PQ and DQ/IQ/OQ/PQ. The extra letter is Design Qualification, and its job is to document that the proposed design actually satisfies the user requirements before anyone builds or installs anything.

In automation work, DQ rarely arrives as a standalone protocol. It is usually satisfied by the formal review and approval of your design specifications — the FDS, SDS and HDS signed off against the URS. That review is the design qualification. If your client asks where your DQ is and you have approved design specs with a traceability matrix linking them to requirements, you already have the answer.

The sequence matters more than the labelling. Each phase depends on the one before it being approved, which is why compressing the schedule tends to fail in a specific way — see how long a validation project realistically takes for what that looks like on a real programme.

IQ — Installation Qualification in Detail

The IQ is the first thing you execute on site, typically after Factory Acceptance Testing (FAT) is complete and the system has been physically delivered and installed. Its purpose is simple: confirm that what was designed is what was installed.

For a typical PLC/SCADA system, your IQ protocol will cover:

• Hardware inventory — every device, module, and component verified against the Hardware Design Specification (HDS)
• Software version records — exact firmware and application software versions recorded and matched against approved versions
• Network and communications — IP addresses, subnet configuration, Ethernet topology verified
• Utilities verification — power supply, UPS, instrument air, earthing confirmed within specification
• Physical installation checks — enclosure rating, cable labelling, segregation of signal and power cables
• Calibration status — all instruments confirmed with valid calibration certificates at point of installation

OQ — Operational Qualification in Detail

The OQ is where most of the testing effort sits. Once installation is confirmed, you now prove that every function of the system works correctly — across its full operational range, including failure modes and alarm conditions.

For a SCADA-based system, OQ test cases typically cover:

• Normal operation — all control loops, setpoints, automatic sequences, manual overrides
• Alarm generation and acknowledgement — every alarm tag verified to trigger at the correct threshold
• Interlocks and safety functions — confirm that safety shutdowns trigger correctly and cannot be bypassed without authorisation
• Boundary conditions — what happens at the top and bottom of each analog range
• User access control — role-based access, audit trail entries, electronic signature functionality
• Data integrity — trending, historisation, and report generation verified against 21 CFR Part 11 requirements — including the audit trail

Each OQ test case follows a standard structure: a test reference number, a description of what is being tested, the step-by-step method, the expected result, the actual result, and a pass/fail verdict. Any deviation from the expected result is raised as a formal deviation and must be resolved before the protocol can be closed.

PQ — Performance Qualification in Detail

The PQ is the final qualification stage and the one that carries the most regulatory weight. Where OQ proves the system can function correctly, PQ proves it performs consistently over time and under real conditions.

PQ typically involves running the system through a defined number of consecutive successful production runs — often three — with all process parameters within specification. The number of runs and acceptance criteria should be defined in the Validation Plan before execution begins.

For automation engineers, PQ often feels like less "your" work — the process engineering team usually leads it. Your role is to ensure the system is stable, the data historian is capturing all required parameters, and any control-system deviations are properly documented.

Qualification vs Process Validation

This is the distinction that causes the most confusion, and getting it wrong is what turns a PQ protocol into an unfinishable document.

IQ/OQ/PQ qualifies the system. It proves your PLC, SCADA, instrumentation and network were installed correctly, function as specified, and hold up under production conditions. Process validation proves the manufacturing process consistently produces product meeting its predetermined quality attributes. They are two different exercises with two different owners.

PQ is where they meet, which is why the boundary blurs there. Under the FDA's process validation framework you will also encounter PPQ — Process Performance Qualification — which sits inside process validation, not inside system qualification. PPQ is normally owned by process engineering and QA. It is not your deliverable, even when it runs on the system you built.

The practical test: if a failed acceptance criterion would be fixed by changing your code, your configuration or your hardware, it belongs in PQ. If it would be fixed by changing the recipe, the raw materials or the process parameters, it belongs in process validation. Anything genuinely ambiguous should be recorded as a deviation and dispositioned rather than argued about in the field — the deviation management process exists precisely for that.

The Documents You Need

Each qualification phase requires a protocol (the plan, written and approved before execution) and a completed version of that protocol with all test results, signatures, and any deviation references. Neither the IQ, OQ, nor PQ can be closed without QA sign-off.

In a well-structured GAMP 5 project, the document chain looks like this:

• URS → defines what the system must do (drives IQ/OQ/PQ scope)
• FDS + HDS + SDS → defines how it was designed (IQ verifies against these)
• FAT protocol → tests at the supplier's works before delivery
• SAT protocol → tests on site after installation, often merged with IQ
• IQ protocol → verifies installation against design
• OQ protocol → verifies all functions against requirements
• PQ protocol → verifies performance under real conditions
• Validation Summary Report → summarises all phases, closes the lifecycle

Common Questions

What does IQ OQ PQ stand for?

Installation Qualification, Operational Qualification and Performance Qualification. They are the three documented testing phases that prove a system was installed as designed, operates as specified, and performs consistently in production.

What is the difference between OQ and PQ?

OQ tests the system across its full functional range in a controlled way, including limits and failure modes, usually without real product. PQ tests it under actual production conditions with real product or process fluids, over enough repetition to demonstrate consistency. OQ asks whether it can work; PQ asks whether it does, reliably.

Do I need a separate DQ document?

Usually not. In automation projects, Design Qualification is normally satisfied by formal review and approval of the FDS, SDS and HDS against the URS, evidenced through the traceability matrix. Some clients require a standalone DQ protocol — ask during the validation planning stage rather than discovering it at handover.

Can IQ and OQ be combined?

Yes, as a combined IOQ protocol, and it is common on smaller systems. The document merges but the testing does not — QA still expects complete as-built verification and complete functional test evidence.

Is IQ OQ PQ the same as process validation?

No. IQ/OQ/PQ qualifies the system; process validation proves the manufacturing process. PQ is where they touch, and PPQ belongs to process validation rather than to system qualification. Keeping product-quality acceptance criteria out of your PQ is the practical consequence.

Who signs the protocols?

Typically the author, an engineering reviewer, and the client's QA representative, with QA approval required before execution and again after. The specific signature matrix is defined in the Validation Plan, so agree it before writing a single protocol.

What happens after PQ is approved?

The Validation Summary Report closes the exercise out — it consolidates results across all three phases, dispositions every deviation, and states whether the system is released for GMP use. See what a Validation Summary Report must contain.

What This Means for You

As the automation engineer delivering the system, you will typically author the IQ and OQ protocols — or at minimum, provide the technical content that a validation specialist formats into the final documents. The PQ is usually led by the client's process team, with your support.

The most important thing to internalise early: in a GMP project, the document is the product. A perfectly engineered system with poor documentation will fail a regulatory inspection. A well-documented system with minor technical imperfections — properly raised as deviations, with impact assessments and corrective actions — will pass.

That's not bureaucracy for its own sake. It's the mechanism by which a regulator can trust that a system is safe to use in the manufacture of medicines.