IQ / OQ / PQInstallation / Operational / Performance Qualification

IQ, OQ and PQ are the three execution stages of equipment, utility, facility and computerised-system qualification. They sit inside the wider Validation lifecycle, which also includes Design Qualification (DQ) before construction and Process Validation (PV) once the equipment is in use. The model is universal across pharma, medical devices, biologics, food, cosmetics and laboratories — although the regulatory framing differs by sector.

Installation Qualification (IQ) proves the equipment was delivered, installed and connected the way the specification says it should be. Operational Qualification (OQ) proves the equipment operates within its specified parameters across its full operating range. Performance Qualification (PQ) proves the equipment, under real production conditions and over time, consistently produces conforming output. Each stage has its own protocol, its own pre-approved acceptance criteria, its own execution evidence and its own approval signature.

The IQ/OQ/PQ structure was formalised in the FDA's 1987 Guideline on General Principles of Process Validation and has been the global default ever since. EU GMP Annex 15 (Qualification and Validation, revised 2015) is the operative European source — it defines DQ, IQ, OQ and PQ explicitly and ties them to user requirements and risk assessment. ICH Q7 Section 12 covers the same ground for active pharmaceutical ingredients. 21 CFR 820.75 (Process Validation) embeds the model into the medical-device QMS.

For computerised systems, GAMP 5 (2nd Edition, 2022) adapts IQ/OQ/PQ to a software lifecycle: configuration is qualified at IQ, functional behaviour at OQ, business process at PQ — with depth proportional to GAMP category (1 infrastructure → 5 custom application). FDA's Computer Software Assurance for Production and Quality System Software guidance (2022 draft) reframes the same activities as risk-based assurance evidence rather than checkbox documentation, but the underlying decomposition is the same.

Importantly, the FDA's 2011 Process Validation guidance moves to a three-stage lifecycle (Stage 1 — Process Design; Stage 2 — Process Qualification; Stage 3 — Continued Process Verification) that incorporates IQ/OQ/PQ but is broader. PQ in the 1987 sense is what Stage 2 calls 'Process Performance Qualification' (PPQ). The terminology drift catches new validation engineers out — your master plan needs to be explicit about which vocabulary you are using.

Design Qualification is the documented verification that the proposed design of the facility, system or equipment is suitable for the intended purpose. It happens before purchase or construction. The inputs are the User Requirements Specification (URS) and the risk assessment; the output is a signed DQ report that maps URS items to vendor capabilities and identifies gaps.

Skipping DQ is the single most expensive validation mistake. Buying a piece of equipment that cannot meet the URS, then trying to qualify it, ends with either a re-engineered specification (and a delayed validation) or a deviation-laden PQ. Annex 15 §3.2 makes DQ explicit for new facilities, systems and equipment.

IQ verifies that the equipment, utility or system has been delivered and installed in accordance with the approved design, the vendor specification and the manufacturer's recommendations. It is the audit-trail of what physically arrived, where it was put and how it was connected.

Typical IQ checklist

• Equipment identification — model, serial, manufacturer, PO, GRN.
• Documentation received — manuals, certificates, drawings, BOMs, software-version certificates.
• Component / utility verification — power, water, compressed air, drainage, environmental conditions match the URS and the vendor spec.
• Physical installation — location, orientation, anchoring, levelling, alignment, clearances.
• Calibration certificates for instruments shipped pre-calibrated.
• Spare parts, lubricants, consumables — inventoried.
• Safety devices — interlocks, emergency stops, guarding — present and identified.
• Materials of construction — verified against vendor certificates (3.1 / 3.2 EN 10204 for stainless steel parts in contact with product).
• Software/firmware version — recorded; configuration baseline captured.

IQ deviations are common (a missing certificate, a transit-damaged sensor, a wrong-rated breaker on a utility tap) and are usually closed by a CAPA before OQ starts. An IQ that completes with zero deviations on a complex system is rare and often means someone did not look hard enough.

OQ verifies that the equipment operates as intended throughout the anticipated operating ranges. This is where SAT (Site Acceptance Test) overlaps with qualification — many vendors' SAT scripts double as OQ protocols, executed by the customer's validation engineer with the vendor's commissioning engineer in attendance.

Typical OQ scope

• Functional testing of every operating mode (auto, manual, recipe, CIP) at the low, nominal and high parameter extremes — temperature, pressure, speed, flow, pH, dose volume, weighing accuracy.
• Alarm testing — every alarm trip-point challenged; correct response (alarm, log, interlock, shutdown) verified.
• Safety testing — every interlock, emergency stop and guard exercised; recovery verified.
• User-level testing — supervisor, operator, maintenance, admin roles execute their permitted operations; non-permitted operations are blocked.
• Recipe / parameter testing — write, save, recall, edit-with-reason, approve-with-e-signature workflows for parameter sets.
• Data and audit trail — events generated by OQ test cases are present, attributable, timestamped, immutable in the audit log.
• Performance under stress — repeated cycles at extremes; equipment recovery from power loss, network loss, sensor failure.

PQ verifies that the equipment, in the actual production environment, with actual personnel and actual procedures, consistently produces output that meets the predetermined specifications. This is where qualification of the equipment meets validation of the process — and where the FDA's 2011 guidance uses 'Process Performance Qualification' (PPQ) to be explicit about that union.

The classic PQ design is three consecutive successful runs at production scale (the 'three batches' default), using approved production materials, executed by trained production personnel under the released SOP. The three batches are evaluated against the predetermined acceptance criteria — product specifications, in-process control limits, environmental data, microbial limits, yield, cycle time, deviation count, intra- and inter-batch variability.

The 'three batches' default has been criticised since at least the 2008 ICH Q8/Q9/Q10 wave for being arbitrary. The 2011 FDA guidance allows risk- and statistics-based justification for fewer or more — a continuous process with strong in-line PAT might justify fewer; a complex multi-step biologic might require many more. Annex 15 §5.4 takes the same risk-based position.

PQ for computerised systems

For an MES, eBMR or QMS application, PQ executes business processes end-to-end with real users on the production configuration. A typical PQ for a Part-11 eBMR system runs through: create MMR, two-person approval, release WO, execute every step at the kiosk with deviation simulation, close WO, render BMR PDF, verify audit trail, verify e-signature manifest. Each business process becomes a PQ test case.

Equipment qualification (DQ/IQ/OQ) demonstrates the equipment is fit for purpose. Process validation (PQ/PV/PPQ) demonstrates the process executed on that equipment delivers a conforming product. The boundary is fuzzy because PQ depends on equipment performance and the equipment cannot really be qualified without exercising its intended process.

Practical convention: OQ runs on water-for-injection, placebo, blank media or sterile saline — generic, repeatable, non-product material that exercises the operating ranges. PQ runs on the actual product, with actual specifications. The transition from OQ to PQ is the moment material changes from 'engineering' to 'release-grade'.

Computerised system validation is the dominant IQ/OQ/PQ use case in modern pharma, devices and biologics. GAMP 5 walks through it explicitly. The mapping is approximately:

Qualification is not a one-time event. Annex 15 §6 and FDA's 2011 guidance both require ongoing assurance that the qualified state is maintained — Continued Process Verification (CPV) for processes, periodic review for systems. A change to the equipment, the software, the SOP, the operating range or the product specification triggers a documented impact assessment under change control, which decides whether re-IQ, re-OQ or re-PQ is needed.

Periodic review of computerised systems is an Annex 11 §11 obligation — at planned intervals, confirm the system is still validated, the configuration baseline matches reality, audit trail is being reviewed, and no out-of-process changes have occurred. The review interval is risk-based; high-impact systems typically run on a 12-month cycle.

• URS missing or post-dated to fit the equipment that was already bought. Annex 15 §3.1 finding.
• DQ skipped. Equipment that cannot meet URS bought and partially qualified before the gap is discovered.
• OQ tested only nominal parameters. Operating-range extremes never exercised; real production drift in PQ.
• OQ done by the vendor with the customer signing without review. FDA finding on independence and oversight.
• PQ used as 'big OQ'. Test cases are unit-level, not business-process-level. Inspection finding on process performance.
• Three-batch PQ accepted without statistical justification of variability. CPV later reveals process is not in control.
• Change after qualification not impact-assessed. Software upgrade, parameter change, role permission change — system effectively unqualified.
• Periodic review skipped or rolled into a perpetual 'next quarter'. Annex 11 §11 finding.
• Audit-trail review during OQ done by the validation engineer instead of by Quality. Independence finding.

V5's role in the customer's qualification programme is to provide validatable building blocks, a runnable validation pack and a system architecture that does not collapse under change-control scrutiny.

• Configuration baselines are exportable as machine-readable snapshots — the qualified configuration of MMR templates, role-permission matrix, workflow definitions, kiosk module set per industry profile.
• Audit trail is on every regulated table with reason-for-change captured at write time — Annex 11 §9 satisfied by the data layer.
• Two-person e-signatures are enforced where 211.186 / 111.205 / 820.40 require them; Quality-Unit independence is enforced by role, not policy.
• The shipped validation pack covers URS, FRS, IQ, OQ and PQ scripts aligned to GAMP 5 Category 4/5 expectations. Customers extend, sign and own it.
• Periodic review is supported by a per-tenant configuration-diff report — what changed since last review, who approved, with reason.
• Release notes are written to support customer impact-assessment under change control — every release lists user-visible changes, regulated-process changes and any configuration-baseline impact.