IQ, OQ, and PQ are the three qualification phases that form the core of traditional computer system and equipment validation in GxP-regulated environments. Installation Qualification (IQ) confirms correct installation. Operational Qualification (OQ) verifies functional performance against design specifications. Performance Qualification (PQ) demonstrates consistent, reliable performance under representative production conditions. Together, they provide a structured, phased approach to generating documented evidence that a system is fit for its intended GxP use.
Installation Qualification verifies that a system has been installed correctly according to its design specifications and the vendor's requirements. For computerized systems, IQ checks include: software version verification, hardware configuration and inventory, network connectivity, operating environment (temperature, humidity, power supply for physical systems), security configuration, and confirmation that calibrated instruments or peripherals meet specifications. IQ documentation must be completed and approved before OQ testing begins, establishing that the system is properly installed and ready for operational testing.
Operational Qualification verifies that a system operates as designed across its specified operating range, independent of the actual production materials or processes. For software systems, OQ tests individual functions against functional and design specifications — confirming that each feature performs correctly under both normal and edge-case conditions. OQ protocols are written against specifications, not procedures, and typically test boundary conditions, error handling, and system behavior under stress. OQ must be completed successfully before PQ testing begins.
Performance Qualification demonstrates that a system consistently performs according to its intended purpose under actual or simulated production conditions. For computerized systems, PQ uses representative real-world workflows, data, and users to confirm that the system supports the business process it was implemented to enable. PQ is typically executed by end users rather than validation specialists and confirms not just technical function but operational fitness. Successful PQ completion marks the system as formally validated and ready for routine GxP use.
Yes. IQ, OQ, and PQ must be executed in sequence because each phase depends on the previous one. OQ cannot begin until IQ is approved — operational testing on an incorrectly installed system produces invalid results. PQ cannot begin until OQ is approved — performance under production conditions on an operationally unqualified system is meaningless. Phase approval, not just completion, is required before the next phase starts. Any significant IQ deviation discovered during OQ requires the IQ to be corrected and re-approved before OQ proceeds.
Each qualification protocol should contain: an objective stating what is being qualified and why; scope defining the system and phase boundaries; prerequisites listing what must be in place before testing begins; test steps with expected results for each; a space for actual results and pass/fail determination; a deviation handling procedure; and a conclusion section for overall assessment. Protocols must be approved before execution — never written during or after testing. Each test step requires a dated, initialed signature from the tester, and a reviewer signature for completed protocols.
Pre-execution approval of qualification protocols is a fundamental GxP requirement because it prevents retroactive justification of test results. If protocols are written during or after testing, expected results can be biased toward observed outcomes — destroying the evidentiary value of the qualification. Regulators and auditors treat post-execution protocol approval as a critical data integrity failure. Protocols should be approved by QA, the system owner, and relevant subject matter experts before a single test step is executed.
Deviations — test steps where actual results do not match expected results — must be documented at the time they occur, not retroactively. Each deviation requires: a precise description of what occurred, an immediate notation in the protocol, a formal deviation report, root cause investigation, impact assessment on the qualification, and documented resolution. Resolution options include: correcting the defect and retesting, amending the protocol with justification, or formally accepting the deviation with risk assessment. Deviations must be resolved before the phase report can be approved.
A Qualification Summary Report (or Validation Summary Report for the full validation lifecycle) documents the overall outcome of all qualification phases. It should include: references to approved protocols and their execution dates; a summary of all deviations and their resolutions; confirmation that all requirements were addressed; outstanding risks and accepted deviations; and a formal conclusion on whether the system achieved validated status. The report requires QA approval and becomes the primary audit reference document for the system's validated state.
FDA's CSA guidance does not mandate IQ/OQ/PQ as the required qualification structure. CSA requires risk-proportionate testing evidence but allows flexibility in how that evidence is organized and documented. For systems where the three-phase structure naturally fits the validation approach, it remains entirely appropriate. For simpler configurable SaaS systems, a combined or streamlined qualification approach may be more proportionate. The key CSA requirement is that the testing evidence demonstrates critical thinking about risk — not that it follows a specific documentary format.
For physical equipment, IQ/OQ/PQ follows the same phase structure but with equipment-specific content. IQ verifies installation per manufacturer specifications — physical location, utilities, calibration status of built-in instruments, and environmental conditions. OQ tests the equipment across its operating range using calibrated standards rather than production materials. PQ uses actual or representative production materials to demonstrate consistent performance in real conditions. Equipment qualification is typically governed by the same SOPs as computerized system validation, with calibration programs as a parallel but related control.
Requalification is required when a change affects validated functions in a way that the original qualification evidence no longer applies. Triggers include: significant software upgrades affecting GxP functions, hardware replacements affecting system performance, changes in the operating environment for physical equipment, configuration changes altering validated workflows, and relocation of equipment requiring installation re-verification. Not every change triggers full requalification — the change control impact assessment determines which phases must be repeated and at what scope, based on the nature and risk of the specific change.
Vendor-supplied IQ/OQ packages can be used as the basis for a company's qualification effort, but the company must review, approve, and execute them against their specific installation — not simply file the vendor documents. A vendor package provides the test structure and expected results; the company provides site-specific data, actual installation verification, and approved execution records. Under GAMP 5 Second Edition and CSA, vendor qualification documentation is explicitly encouraged as evidence to leverage, but it cannot substitute for site-executed and company-approved qualification records.
Electronic QMS validation requires particular attention to data integrity controls during qualification. OQ testing must specifically verify audit trail completeness, user access control enforcement, electronic signature binding, and prevention of unauthorized record modification — requirements stemming from 21 CFR Part 11. PQ should test actual quality workflows (deviation management, CAPA, change control) with real or representative users and data. Configuration qualification is critical: access levels, workflow routing, and notification settings all require documented verification against the approved configuration specification.
Scope definition for complex systems should follow the Functional Risk Assessment (FRA) outcome. GxP-critical functions identified in the FRA determine the OQ and PQ test scope — every critical function must have corresponding qualification evidence. Non-critical functions are out of scope for formal qualification testing, though they may be covered by user acceptance testing. The IQ scope covers all infrastructure components supporting critical functions. A well-defined scope prevents both under-testing of critical functions and over-testing of non-critical ones — the core efficiency goal of risk-based qualification.
For a mid-complexity enterprise system (LIMS, QMS, MES with 20–50 critical functions), a realistic IQ/OQ/PQ timeline runs 8–16 weeks from protocol authoring to approved Validation Summary Report. Protocol writing takes 3–5 weeks; review and approval adds 1–2 weeks; execution takes 2–4 weeks; deviation resolution and report writing adds 2–4 weeks. Compressed timelines using specialist resources and parallel workstreams can reduce this to 4–8 weeks for smaller systems. Underestimating documentation and approval time is the most common cause of validation timeline overruns.
No FDA regulation explicitly mandates the IQ/OQ/PQ terminology or format. The requirements derive from multiple sources: 21 CFR Part 211.68 requires that computerized systems used in drug manufacturing be fit for use; 21 CFR Part 11 requires validation of electronic record systems; and FDA's General Principles of Software Validation (2002) — now supplemented by the 2022 CSA guidance — describe the lifecycle validation expectation. IQ/OQ/PQ emerged as industry best practice to satisfy these requirements and has become the de facto standard documented in SOPs globally.
Design Qualification (DQ) is sometimes added before IQ as the first phase of the qualification lifecycle. DQ verifies that the proposed design of a system — or for commercial software, the vendor's product specification — meets the user's requirements before procurement or build begins. DQ is most common for custom-built or configured systems where design choices need formal review before implementation. For commercial off-the-shelf software, DQ may consist of confirming the vendor's functional specification against the URS. While not always a formal protocol phase, DQ thinking — confirming requirements alignment before implementation — is implicit in good validation practice.
LIMS validation via IQ/OQ/PQ is a common and well-defined activity. IQ verifies the LIMS installation: server/database environment, network configuration, software version, integration connectivity, and security settings. OQ tests LIMS functions against specifications: sample login, result entry, instrument interfaces, approval workflows, report generation, and audit trail capture. PQ uses representative laboratory workflows and actual or surrogate samples to confirm the LIMS supports GxP sample management and result reporting in production conditions. Chromatography data system (CDS) integrations require separate but coordinated qualification.
For cloud-hosted and SaaS systems, traditional IQ activities shift significantly: the vendor's infrastructure certification (SOC 2, ISO 27001) and hosting documentation serve as IQ evidence rather than a company-executed installation check. The company's IQ focuses on account configuration, user provisioning, and integration verification. OQ and PQ remain the company's direct responsibility and are executed against their specific configuration and workflows. The key adaptation is that IQ evidence is predominantly vendor-supplied and vendor-maintained — the company reviews and approves it rather than generating it independently.