IQ, OQ, PQ explained: what each protocol has to prove and what it must not repeat

Installation qualification, operational qualification, performance qualification. Three protocols, three questions, and most of the confusion about them comes from one habit: testing the same thing three times and calling it rigour. This guide says what each protocol has to prove, what it verifies against, what belongs in it, what must not be repeated from the one before, and what an executed protocol has to contain when an inspector opens it.

What do IQ, OQ and PQ mean?

Each protocol answers one question about a system, and each question is asked of a different document:

Protocol	The question	Verifies against	Typical evidence
IQ · Installation qualification	Is it installed as designed?	The design package: DS, P&IDs, electrical and loop drawings, layout, I/O list, bill of materials, supplier documentation	Marked-up P&IDs and electrical drawings, as-built checks, serial numbers, materials, calibration certificates, loop checks, software versions
OQ · Operational qualification	Does it operate as specified?	The functional specification (FS)	Functions at set points and limits, alarms and interlocks, sequences, records, access
PQ · Performance qualification	Does it perform for its intended use, at its limits, repeatedly?	The user requirements specification (URS) and the process	Runs with product or a proven substitute at the rated throughput, at worst-case batch sizes and formats, across the process operating range, over consecutive runs that agree

The questions are not interchangeable. "Is the load cell wired to channel 3 of card 2?" is an IQ question. "Does the filler dose 5.0 mL at three set points?" is an OQ question. "Does the line deliver 30,000 vials a batch, at its rated speed, within specification, batch after batch?" is a PQ question. Put any of them in the wrong protocol and the protocol proves something nobody asked it to prove.

EU GMP Annex 15 (2015) defines the three in its glossary, and the definitions say where each one stops:

• IQ: documented verification that the facilities, systems and equipment, as installed or modified, comply with the approved design and the manufacturer's recommendations.
• OQ: documented verification that the facilities, systems and equipment, as installed or modified, perform as intended throughout the anticipated operating ranges.
• PQ: documented verification that systems and equipment can perform effectively and reproducibly based on the approved process method and product specification.

Sections 3.5, 3.6 and 3.7 of the same annex list what each should include. GAMP 5 (second edition) describes the same structure as specification and verification: every specification level has a verification activity at its own height. FDA's 2011 process validation guidance folds equipment qualification into stage 2, process qualification, and expects it done before process performance qualification runs. None of them asks for duplication.

How do IQ, OQ and PQ fit the V-model?

They are its right-hand leg. A system is specified down the left, from what the process needs (URS) to what the system does (FS) to how it is built (DS, with the P&IDs, electrical and loop drawings, layouts and I/O list that go with it), and verified up the right. Each protocol verifies the specification at its own height, and nothing else.

Follow one requirement through all three, the same vial filler used in the traceability guide:

• URS-001: fill volume 5.0 mL, ± 1.0 %.
• FS-003: gravimetric dosing; the pump is driven by the load-cell weight.
• DS-007: load cell WT-101, 0–20 g, 4–20 mA, analogue input card 2, channel 3.
• IQ verifies DS-007: WT-101 is the specified model, installed where the drawing says, wired to card 2 channel 3, scaled 0–20 g on the HMI, with a calibration certificate in date. The loop check is the evidence for the wiring and the scaling.
• OQ verifies FS-003: three set points, ten vials each, every vial within ± 1.0 %. The function works across its range.
• PQ verifies URS-001: three consecutive batches at the rated 300 vials per minute and the largest batch size, thirty vials sampled per batch, batch mean within ± 0.5 %, and the same result in all three. The process gets what it asked for, at the speed and size it will run at.

Notice what each one does not do. The IQ does not fill a vial. The OQ does not repeat the loop check. The PQ does not re-run the three set points; it runs the process at its limits. When a test sits at the wrong height, one of two things happens: it duplicates a test above or below it, or it verifies a document it was never traced to. Both are findings, and the second is the worse one, because an OQ test that "covers" a URS line directly means the FS was skipped and the requirement was never designed for.

What belongs in an IQ?

An IQ proves that what was delivered and installed is what the design package describes: the DS, the P&IDs, the electrical, pneumatic and loop drawings, the layout, the I/O list, the bill of materials and the supplier's documentation. Annex 15 §3.5 lists the content; in practice it comes to this:

• Installation against the design. Components, instruments, pipework, cabling and services checked against the P&IDs, the electrical and loop drawings, the layout and the DS. The P&IDs and the electrical drawings are marked up as built and signed during the walk-down; those marked-up drawings are IQ evidence, not a job for later.
• Identity. Model and serial number of every component that matters, against the DS and the purchase order.
• Materials of construction. Product-contact materials and surface finish, with certificates.
• Utilities and connections. Power, compressed air, water, network: connected as specified, with the specified ratings.
• Instrumentation. Each instrument tagged, installed, calibrated, and its loop checked at 0, 50 and 100 % of span against the I/O list. Calibration certificates filed, due dates recorded.
• Software and firmware. Versions of the PLC program, the HMI project and any package, against the DS. Backups taken.
• Documentation collected. Supplier manuals, operating instructions, maintenance requirements, spare-parts lists: the set that operations will need, listed and filed.

An IQ is a checklist with evidence, and most of its items are a comparison: specified value, observed value, match. It does not operate the system beyond what is needed to read a version or scale a signal.

What belongs in an OQ?

An OQ proves that the system does what the functional specification says, across the range it was specified for. Annex 15 §3.6 asks for tests "developed from the knowledge of processes, systems and equipment" and for tests at the upper and lower operating limits or worst-case conditions. In practice:

• Every function in the FS, at its set points. Dosing, mixing, heating, CIP sequence, recipe download: each one exercised and measured.
• Limits and worst cases. The function at the edges of its specified range, not only at the comfortable middle.
• Alarms and interlocks. Each one provoked, the reaction timed, the HMI message and the log entry checked.
• Sequences and states. Start, stop, hold, abort, power loss and recovery, where the FS specifies them.
• Records and data. Batch record content, audit trail, time stamps, user roles and access, where the system holds GMP data.
• Error handling. Invalid inputs, out-of-range values, a sensor fault: Annex 11 §4.7 names parameter limits, data limits and error handling as the things test scenarios must cover.

Annex 15 adds a consequence that is easy to miss: a successful OQ is what allows the operating and cleaning procedures, the training and the preventive maintenance plan to be finalised. The OQ is where the system becomes operable, not only tested.

What belongs in a PQ?

By the time the PQ starts, the OQ has shown that every function works, at its set points and at its limits. The PQ asks a different question: can the system deliver the process the URS described, at the rate and the quality it asked for, at the worst case it will meet, and do it again? Annex 15 defines it as the verification that the system "can perform effectively and reproducibly based on the approved process method and product specification", and §3.7 says how:

• Production materials, a qualified substitute or a simulated product proven to behave the same, under normal operating conditions. Water through a filler proves a pump; a viscous product at line speed proves a process.
• Capacity. The rated throughput the URS asked for, sustained over the run: 300 vials per minute for the whole batch, not for ten minutes with the line empty behind it. Quality attributes held at that rate.
• Worst case. The hardest case the process will see, chosen and justified in the protocol: the largest batch size (Annex 15 §3.7 names it), the longest campaign, the smallest format at the highest speed, the most viscous product, the extremes of the process operating range, the hold times. If the system performs there, it performs anywhere inside.
• Reproducibility. Consecutive runs that give the same result. Three is the convention; the number is justified from the risk and the data, not inherited.
• The operating range of the intended process, unless documented development data already covers it.
• Sampling at a frequency and a plan justified in the protocol, not chosen on the day.
• Results against the URS and the product specification, batch by batch and across the batches.

The PQ is written from the URS and from the process, not from the FS. Its acceptance criteria are the ones the process owner wrote on day one: output per batch, yield, cycle time, fill weight per batch, sterility assurance. For an aseptic process the PQ of the process is the media fill. Where a system is part of a manufacturing process, the PQ is often performed with, or as part of, process validation; Annex 15 allows it to be run in conjunction with the OQ or with process validation when that is appropriate, and FDA's 2011 guidance calls the combined run of facility, utilities, equipment and process the process performance qualification.

What each protocol must not repeat

The most common fault in a qualification package is not a missing test. It is the same test, run three times, with three results that do not quite agree. Repetition feels safe. It is not: when the IQ says the HMI is v2.4.1 and the OQ, run two weeks later, says v2.4.2, which one is the evidence?

The test that gets duplicated	Where it belongs	Why the repeat proves nothing new
Calibration certificates checked again in the OQ	IQ	Calibration is a property of the installed instrument, verified once, with a due date. The OQ relies on it; it does not re-prove it.
Loop check repeated as an OQ test	IQ	Wiring and scaling do not change between IQ and OQ. The OQ uses the signal to test a function.
Software version recorded in IQ, OQ and PQ	IQ	Record it once, at installation. Any later change is a change control, and the version it records is the one every later test ran against.
Alarm set points re-tested in the PQ with product	OQ	The alarm's reaction is a function; product does not change it. The PQ runs the process and records that no alarm fired, or what happened when one did.
Functional test at three set points re-run in the PQ	OQ	The PQ proves performance at the process set point with product, at rated throughput and worst case, over batches. Repeating the OQ grid with product is neither OQ nor PQ.
FAT tests re-executed on site in the OQ	FAT, leveraged	Annex 15 §3.4 allows tests done at the factory to stand if transport and installation cannot affect the result. Re-execute what they can affect; reference the rest.
A batch run in the IQ "to see it work"	PQ	Running product before the OQ proves nothing: the functions have not been verified, and the batch cannot be released.

The rule behind every row: a test verifies the level it belongs to, once, and the protocols above it rely on that result instead of repeating it. That is also what makes a traceability matrix readable. When every requirement is traced to one test at the right height, the matrix has no duplicates to reconcile.

How do you write acceptance criteria that can actually fail?

A test that cannot fail is not a test. "Fill volume is correct" passes whatever happens, because nobody wrote down what incorrect means. Every acceptance criterion has to be one of three things: a number with a tolerance, a range, or a state.

Three checks before a protocol is approved:

1. Can the executor write a result that fails it? If the expected result is "as per specification", the executor has to go and find the specification, and will not.
2. Does it name the specification it verifies? OQ-011 verifies FS-003. Without the link the test is an orphan, and the matrix will show it.
3. Is the method stated? Which instrument, which calibrator, which sample size. A PQ sampling plan chosen on the day is the finding Annex 15 §3.7 was written to prevent.

Annex 11 §4.7 says it in one line for computerised systems: test scenarios must cover parameter limits, data limits and error handling. A criterion that lives at the middle of the range, with valid data and no faults, has covered none of them.

What does an executed protocol have to contain?

A protocol is approved before execution and frozen at that version. The executed copy then has to hold everything an inspector needs to re-walk the test without the executor in the room:

• The released version. Which revision of the protocol was executed, approved by whom and when. A test executed against a draft is not evidence.
• Expected and observed, per step. The number the executor saw, not a tick. A tick is a claim; a value is data.
• Evidence. The printout, the screenshot, the calibration certificate, the photograph of the nameplate: attached to the step, named, dated.
• Discrepancies. A failed step is recorded as a discrepancy with an identifier, an assessment, a closure and, where needed, a re-test that names the first run. The first run stays on file. Overwriting a failed result is the one thing that turns a finding into a data-integrity observation.
• Signatures with a meaning. Who executed, who reviewed, when, and what the signature means. For electronic signatures, 21 CFR Part 11 §11.50 asks for the printed name, the date and time, and the meaning, on every signed record.
• The design revision. Which revision of the FS or DS the test verified. A requirement reworded after execution is a re-test question, and the record has to be able to answer it.

IQ, OQ and PQ side by side

	IQ	OQ	PQ
Question	Installed as designed?	Operates as specified?	Performs for its use, at its limits, repeatedly?
Verifies	The design package: DS, P&IDs, electrical and loop drawings, layout, I/O list, BOM	FS	URS and the process
Written from	The design package and the supplier documentation	The FS, function by function	The URS and the process
Executed with	No product; the system at rest or in service mode	No product, or water and placebo	Product or a proven substitute
Conditions	As installed	Set points, limits, worst cases, faults	Rated throughput, worst-case batch sizes and formats, the process operating range, consecutive runs
Typical criteria	Specified value equals observed value; drawing marked up as built; certificate present and in date	Value within tolerance; state reached within time; message and log entry present	Output and quality within specification at rated throughput and worst case, over n consecutive runs; sampling as justified
Relies on	FAT and SAT, where leveraged	The IQ	The OQ, and development data where it exists
Enables	The OQ	SOPs, training, maintenance plan (Annex 15 §3.6)	Release for use; process validation
Re-executed when	A component is replaced, software changes	A function or its limits change	The process or the product changes

Protocol skeletons you can copy

The three protocols share a frame and differ in their middle. The frame: purpose and scope, the specification verified and its revision, references, prerequisites, test sections, discrepancy handling, acceptance and approval. The middle is the test sections:

IQ · Installation against drawings, with the P&IDs and electrical drawings marked up as built · Component identity · Materials of construction · Utilities and connections · Instrumentation and calibration · Loop checks · Software and firmware · Documentation collected.

OQ · Functions at set points · Operating limits and worst cases · Alarms and interlocks · Sequences and states · Records, audit trail and access · Error handling.

PQ · Materials and substitutes · Capacity at rated throughput · Worst case: batch size, format, campaign length, operating range · Consecutive runs · Sampling plan · Results against the URS and the product specification.

Download: IQ, OQ and PQ protocol skeletons, on one page (PDF). The shared frame, the test sections of each protocol, the acceptance-criterion rule and the "do not repeat" list, in the order you write them. Print it, hand it to a supplier with the request for their protocols, or use it to review the ones they send. Download the skeletons

Keeping the three protocols honest through a project

• Write each protocol from its own document. IQ from the design package (DS, P&IDs, electrical and loop drawings, I/O list), OQ from the FS, PQ from the URS. A test that cannot name the specification it verifies does not go in.
• One test per thing, at its height. When a test appears in two protocols, keep the lower one and make the upper one reference it.
• Leverage what the factory proved. FAT and SAT results stand where transport and installation cannot change them (Annex 15 §3.4); the OQ references them and re-executes the rest.
• Approve, freeze, then execute. The released version is the one on the executed copy. Changes after release are a new revision and a decision about re-execution.
• Record values, raise discrepancies, keep the first run. A protocol with no discrepancies in it was either very good or never really executed.

This is how MGTrace is built: a protocol is a document on the V with its own rung, its tests trace to the specification they verify, a version is released before anyone executes it, each step records expected and observed with evidence attached, a failed step raises a discrepancy, and the signatures carry a meaning. The three protocols then read as three answers, not one answer three times. It is part of what validation software has to do; the discipline holds in any tool, and in paper, as long as each protocol stays at its own height.

Frequently asked questions

Are IQ, OQ and PQ mandatory?

In the EU, yes in substance: Annex 15 §3 describes the qualification stages for equipment, facilities, utilities and systems, and §3.5 to §3.7 say what IQ, OQ and PQ should include. The FDA does not use the three names in its regulations, but 21 CFR 211.63 and 211.68 require equipment to be suitable and verified, and the 2011 process validation guidance expects utilities and equipment to be qualified before process performance qualification. An inspector from either side will ask for the same evidence whatever the protocols are called.

Can IQ and OQ be combined into one protocol?

Yes. Annex 15 §3.6 says that OQ normally follows IQ but, depending on the complexity of the equipment, the two may be performed as a combined IOQ. Combining the protocol does not combine the questions: the IOQ still has an installation section verified against the DS and an operational section verified against the FS, and the installation checks are executed first.

Does every system need a PQ?

Not as a separate protocol. Annex 15 §3.7 allows the PQ to be performed in conjunction with the OQ or with process validation where that is appropriate. For a utility or an item of equipment with no product-specific performance, the OQ at its operating limits may be the last protocol; for a system that makes product, the PQ is usually the process validation batches. What every system needs is a documented decision about which, taken in the validation plan and not after the OQ.

What is the difference between OQ and PQ?

The OQ proves functions against the FS, without product, at set points and limits: does the filler dose 5.0 mL at three set points, does the alarm fire at 11.0 bar? The PQ proves performance against the URS, with product or a proven substitute: does the line deliver the batch the process asked for, at the rated throughput, at the largest batch size and the hardest format, with the same result run after run? The OQ exercises the system; the PQ runs the process at its limits and shows it can be repeated.

Can FAT results replace OQ tests?

Some of them. Annex 15 §3.4 allows tests performed at the factory to stand without repetition at IQ or OQ when it can be shown that the function is not affected by transport and installation. Software logic, recipe handling and HMI functions usually qualify; anything that depends on site utilities, site instruments or the installed loop does not. The OQ references the FAT test, its result and its date; it does not merely say "tested at FAT".

Who writes and who approves the protocols?

The supplier or the engineering team usually drafts the IQ and the OQ, since they wrote the DS and the FS; the process owner and validation write the PQ, since it comes from the URS. Quality approves all three before execution and the executed copies after. Whoever drafts them, each protocol names the document it verifies and the revision of it.

In short. IQ asks whether the system is installed as designed and verifies the design package: the DS, the P&IDs, the electrical and loop drawings, the I/O list. OQ asks whether it operates as specified and verifies the FS. PQ asks whether it performs for its use, at its limits and repeatedly, and verifies the URS. Write each from its own document, test each thing once at its height, write criteria that can fail, freeze the version before execution, and keep every observed value, discrepancy and signature. Three answers, not one answer three times.