Equipment qualification goes wrong in a way software validation rarely does: the stages get executed in the right order and nobody can say what any of them proved. Four protocols are signed, the package is complete, and the question “what does your OQ demonstrate that your IQ did not?” produces a pause.
Annex 15 of the EU GMP Guide is the binding expectation here, and it is shorter and less prescriptive than the industry's habits around it. Each stage answers a different question. Knowing which is which is most of the discipline, because it tells you what belongs in each protocol and — more usefully — what does not.
This is how we structure equipment qualification software.
Design qualification: did we specify the right thing?
DQ confirms that the proposed design meets the user requirements and the applicable regulatory expectations — before anything is bought or built. It is the cheapest stage and the one most often skipped, usually because the equipment has already been ordered by the time Quality is involved.
The thing DQ catches is a specification error, and a specification error found at DQ is a conversation. The same error found at PQ is a capital decision. If a vessel cannot achieve the required mixing time, or a washer cannot reach the required temperature with the load you actually run, that is knowable from the design and the supplier's data.
DQ is required where equipment is specified for you rather than taken off the shelf. For a standard catalogue item it collapses into the requirements and supplier selection record, and forcing a separate DQ protocol for a laboratory oven produces paperwork rather than assurance.
Installation qualification: is it what we ordered, installed where we said?
IQ verifies that the equipment as delivered matches the specification, and that its installation and supporting utilities match what was designed. Identity, completeness, calibration status of the instrumentation, utility connections, documentation and spares.
The failure mode is treating IQ as an inventory exercise. A checklist confirming that the serial number matches the purchase order is necessary and tells you very little. What matters is whether the installed configuration can support what you are about to claim in OQ — correct materials of construction, drainability, the instrument ranges you need to measure the parameters you care about, and accessibility for the cleaning and maintenance the process will require.
Calibration belongs here as a prerequisite rather than a parallel activity. An OQ result produced by an uncalibrated instrument is not a result, and this is one of the more common findings we see. Calibration as a qualification prerequisite
Operational qualification: does it work across its range?
OQ demonstrates that the equipment functions as specified throughout its intended operating range — including at the limits, which is where OQ earns its keep and where most protocols are thinnest.
Test at the boundaries rather than in the comfortable middle. The lowest and highest setpoint you intend to use, not a nominal value. Alarm and interlock behaviour, proven by provoking the condition rather than by inspecting a configuration screen. Failure and recovery: what the equipment does on power loss, on utility interruption, on an out-of-range sensor. Those are the paths that exist because something went wrong, and therefore the paths most likely to be examined.
OQ is still equipment-centred rather than product-centred. You are establishing the operating envelope, not yet demonstrating that your process works inside it.
Performance qualification: does it work for our process?
PQ demonstrates performance with the actual process, the actual materials and the people who will run it. It is where the equipment stops being the subject and becomes the instrument.
The boundary between OQ and PQ is where most packages blur, and the test is straightforward: if the test would be identical for any user of this equipment, it is OQ. If it depends on your product, your load pattern, your recipe or your SOPs, it is PQ.
Worst case matters more here than typical case. The heaviest load, the most difficult product, the shortest cycle you intend to run. A PQ performed on the easiest case establishes that the easiest case works.
What Annex 15 permits that teams do not use
Annex 15 is more accommodating than common practice, and two provisions are routinely left on the table.
First, it takes a lifecycle and risk-based position rather than mandating uniform depth. The extent of qualification should follow the risk the equipment carries, which means a nitrogen generator and a sterilising autoclave do not warrant the same treatment, and treating them alike takes effort from the one that matters.
Second, it allows supplier testing — factory and site acceptance testing — to support qualification rather than requiring you to repeat it. Re-proving in IQ what a supplier demonstrated at FAT, with you in the room, is duplicated effort. The requirement is that you review and accept it, and record why it is adequate. leveraging commissioning covers how much is actually available this way, because for equipment it is usually the largest single reduction in the package.
Keeping equipment qualified
Qualification is a state rather than a project, and equipment drifts out of it for ordinary reasons: a modification, a replaced component, a change in what you run on it, a maintenance regime that quietly relaxed.
What matters is deciding in advance what triggers a requalification and what does not, so the judgement is made before the pressure rather than during it. An undefined trigger means every change becomes a debate, and debates under schedule pressure resolve towards doing nothing. What triggers requalification
equipment qualification software is the practice, and book a demo if you want an existing qualification package reviewed rather than rebuilt.
Where to go next
Explore GxP Copilot for AI-native validation, TraceDraft for source-traceable clinical documentation, or book a demo to see either on your own data.