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.

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.

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

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.