IQ, OQ and PQ Explained

What IQ, OQ, and PQ mean in CSV

In computer system validation (CSV), IQ, OQ, and PQ are not interchangeable labels — they answer different questions about whether a system is ready for regulated use. Together they form the executed evidence on the right side of the validation V-model: installation checks, functional challenges, and intended-use confirmation.

FDA's General Principles of Software Validation (GPSV, Document 938) describes validation as establishing documented evidence that software conforms to user needs and intended uses. IQ, OQ, and PQ are the qualification activities manufacturers use to build that evidence for automated systems affecting product quality, patient safety, or data integrity.

GXPLearn trains these concepts interactively: Module 09 executes a digital OQ protocol with deviation handling; Module 10 traces requirements through the V-model into test evidence. This page explains the qualification layers auditors and validation engineers reference daily.

FDA GPSV grounding

FDA GPSV §3.1.2 defines validation as establishing documented evidence that a system conforms to user needs and intended uses. §3.1.3 distinguishes verification (building the product right) from validation (building the right product) — IQ and OQ lean toward verification of installation and operation; PQ confirms performance in intended-use context.

§4.8 emphasises that validation is not complete until the system operates in accordance with intended use in the production environment. §5.2.6 discusses user site testing — confirming that vendor or developer testing is supplemented by site-specific evidence where production conditions differ.

§5.2.7 addresses when revalidation is required after changes. §6.1 and §6.2 cover validation planning and documentation expectations. These principles underpin how IQ, OQ, and PQ scope is justified — not as checkbox stages, but as risk-informed evidence layers.

IQ vs OQ vs PQ comparison

Installation Qualification (IQ)

IQ confirms the expected system components, software versions, configuration downloads, and environment are present before functional testing begins. In GXPLearn's V-model training, IQ maps to installation checks — controller, workstation, DeltaV version, module download, and network/environment verification.

A common audit finding is executing OQ against an unverified baseline: the configuration under test does not match the approved design revision. IQ evidence should link to the configuration baseline that OQ will challenge.

Risk-based approaches may accept vendor or platform installation evidence where site qualification and change control are robust — but the installed state under test must be identifiable and controlled.

Operational Qualification (OQ)

OQ demonstrates that configured functions behave as specified under controlled test conditions. In GXPLearn Module 09, learners execute protocol OQ-INT-001 against the BR-201 media addition interlock scenario: URS-14 requires automatic XV-101 closure when LI-101 exceeds 90%; URS-15 requires manual open commands to be rejected during high-level conditions.

OQ Step 1 verifies the automatic interlock (EV-OQ-001). OQ Step 2 challenges manual lockout (EV-OQ-002). When Step 2 fails — XV-101 opens manually while LI-101 remains above 90% — deviation DEV-OQ-INT-001 is raised. Root cause: control logic lacks continuous enforcement in manual mode. Change CHG-INT-015 corrects the permissive; targeted re-test EV-OQ-002R closes the deviation.

This workflow mirrors real validation practice: predefined steps, acceptance criteria, observed results, documented failures, impact assessment, controlled correction, and retest — not hiding failures or re-running without documentation.

Performance Qualification (PQ)

PQ confirms the system supports real operational use — often with approved procedures, representative batches, or site operating expectations. GPSV §4.8 states validation is not complete until the system operates in accordance with intended use in the production environment.

In GXPLearn's V-model content, PQ maps to intended-use confirmation: for example, Growth Hold maintaining controlled temperature during a representative batch run, with batch records, trend review, and alarm/event evidence.

OQ proves functions work in controlled conditions; PQ proves they support the process context users rely on. Skipping PQ where intended-use performance matters leaves a gap auditors question — especially when production conditions differ from OQ envelopes.

URS → IQ/OQ/PQ traceability

Each qualification layer should trace to requirements — not exist as isolated checklists. In the OQ-INT-001 case, the requirements traceability matrix links URS-14 to FRS-INT-014, risk RA-014, OQ Step 1, and evidence EV-OQ-001; URS-15 traces through FRS-INT-015, RA-015, OQ Step 2, and EV-OQ-002/002R.

Traceability gaps are a common audit finding: tests that do not map to requirements, deviations poorly classified, or retest scope after failures undocumented. Module 10 trains learners to build and review these links across specification and test layers.

A traceability matrix is not bureaucracy for its own sake — it lets reviewers verify every requirement has corresponding evidence and that tests address real intended-use risks.

User site testing (GPSV §5.2.6)

FDA GPSV §5.2.6 discusses user site testing — confirming that evidence from development or vendor testing is supplemented by site-specific qualification where production conditions, interfaces, or configuration differ.

IQ and OQ at the user site establish that the installed, configured system at your facility performs as intended — not only that the vendor's generic test package passed elsewhere. Site-specific interfaces, security settings, historian configuration, and procedure integration often require local evidence.

When leveraging vendor OQ scripts or platform evidence, critical review and gap assessment remain essential — especially for custom configuration, interfaces, and GxP-critical functions.

Risk-based qualification depth and CSA

Traditional CSV often emphasises comprehensive scripted IQ/OQ/PQ for GxP-critical systems. FDA's risk-based Computer Software Assurance (CSA) guidance reframes how assurance effort is proportioned — more rigor where process risk and GxP impact are high, leaner methods where appropriate.

IQ depth may leverage vendor evidence for standard platforms; OQ scripted depth should follow function criticality; PQ scope depends on intended use in production. Neither risk-based thinking nor CSA eliminates qualification — they inform how much and what type of evidence is needed.

See /csv-vs-csa for how CSV lifecycle structure and CSA proportioning coexist, and /what-is-csa for the FDA six-step assurance framework.

Practise IQ, OQ, and PQ in GXPLearn

Module 09 (CSV Validation) — execute OQ-INT-001, document deviation DEV-OQ-INT-001, assess impact, and close with targeted re-test evidence. Module 10 (V-Model) — trace URS through design to IQ, OQ, and PQ evidence layers with interactive exercises.

Modules 11–12 extend CSA assurance and CSV vs CSA comparison. Modules 20–24 provide capstone validation workspace scenarios integrating batch, operator, and evidence review context.

Start with free foundation Modules 01–03 for system and batch context, then explore /csv-csa-training for the guided CSV/CSA learning path.