Computer System Validation 101: What IQ, OQ and PQ Actually Mean
A plain-language breakdown of the three checks every validated system has to pass — and why skipping one is a common audit finding.
Computer System Validation 101: What IQ, OQ and PQ Actually Mean
A plain-language breakdown of the three checks every validated system has to pass — and why skipping one is a common audit finding.
Why validation gets split into three checks
If you work in pharmaceutical manufacturing, a lab, or any GxP-regulated environment, you've heard "the system needs to be validated" more times than you can count. What that actually requires is three distinct, sequential checks — and treating them as one blob of paperwork is one of the most common reasons validation packages get flagged during an inspection.
Installation Qualification (IQ)
IQ answers one question: was the system installed correctly? This means verifying the hardware, software versions, network configuration and environment match what was specified — before anyone tests whether it actually works. Skipping IQ and jumping straight to functional testing is like skipping the foundation inspection and going straight to painting the walls.
Operational Qualification (OQ)
OQ tests whether the system operates the way it's supposed to, across its full range of intended use — not just the happy path. This includes boundary conditions, error handling, security/access controls, and alarm or notification behavior. A system that works perfectly when you enter valid data but fails silently on invalid data has not passed OQ, even if nobody has actually noticed yet.
Performance Qualification (PQ)
PQ confirms the system performs consistently under real, day-to-day production conditions — real users, real data volumes, real workflows — rather than a clean, sandboxed test script. This is the stage that catches issues IQ and OQ structurally can't: things that only show up under actual load or with the messiness of real operators.
Why the order matters
Each stage depends on the one before it: you can't meaningfully test operation (OQ) on a system that wasn't confirmed to be installed correctly (IQ), and you can't validate real-world performance (PQ) on a system whose operational behavior was never verified. Auditors look for this chain of evidence specifically — not just three documents, but three documents that logically build on each other with clear traceability back to the original requirements.
