The IQ/OQ/PQ framework is built on a simple and sound premise: you qualify a system progressively, confirming at each stage that it is installed correctly, that it operates as designed, and that it performs consistently in actual use.
The framework assumes that what you qualify in OQ is the same system you put through PQ. It assumes continuity of configuration across phases.
In practice, that assumption frequently breaks.
How configuration drifts between qualification phases
The gap between IQ and OQ can be days or weeks. Between OQ and PQ, weeks or months. During that time, the system is not frozen. Engineers make adjustments. Vendors push software updates. Parameters are tuned during commissioning runs. Recipe files are revised.
Many of these changes are legitimate and expected. The problem is not that change happens — it is that the changes are rarely captured with the rigour required to understand their impact on the qualification programme.
A change to a PLC parameter between OQ and PQ may or may not affect the OQ results. A change to a vision system threshold may or may not require re-execution of vision qualification tests. Without a documented, comparative record of exactly what changed, the qualification team cannot make that assessment with confidence. They either assume nothing significant changed — taking on undocumented risk — or re-execute more broadly than necessary, taking on unnecessary schedule cost.
The audit exposure
Regulators conducting GMP inspections have become increasingly focused on configuration control as a component of data integrity. The question "how do you know the system running today is the same system that passed qualification?" is no longer a peripheral concern — it is a core inspection theme.
Inadequate root cause analysis for deviations, weak change control, and poor traceability between qualification phases are among the most consistent findings in pharmaceutical manufacturing inspections. All three are directly connected to the absence of rigorous configuration management across the IQ/OQ/PQ lifecycle.
A gap here does not only create regulatory risk. It creates operational risk: a system running on configuration assumptions that may no longer be valid, with no reliable way to detect when they drift — a pattern covered in configuration drift on the production line.
What rigorous configuration control looks like across phases
The principle is to treat each phase boundary as a configuration checkpoint. At IQ completion, capture a signed baseline of the as-installed state. At OQ completion, capture the as-tested state. Before PQ begins, compare the two automatically and document any changes.
Where changes occurred, the team can assess their qualification impact with evidence rather than assumption. Changes in scope for PQ are defensible and documented. Changes outside scope are visible and controlled.
The same logic extends forward. Periodic requalification — triggered by change control or calendar — begins from a known configuration state. The question is not "what might have changed?" but "here is exactly what changed — does it require requalification action?"
Continuous monitoring as the post-PQ layer
Qualification is not a one-time event. Systems run in production, and configurations drift. A recipe parameter is adjusted during a batch investigation. A SCADA tag is modified during a maintenance window. A vision threshold is tweaked to accommodate a new product variant.
In a system with continuous configuration monitoring, each of these changes is captured, attributed, and surfaced in real time. The deviation management process begins with a complete record of what changed, when, and on which system — not with an investigation into what might explain the anomaly.
That is the difference between a system that is qualified at a point in time and a system that is continuously in a qualified state — the through-line that links baseline-driven SAT to OT change management in production.