Web of Pharma · Digital Quality & Validation

IQ, OQ, and PQ for Computerized Systems

A practical GMP guide to planning, executing, and documenting qualification evidence across the computerized system lifecycle.

A risk-based guide for pharmaceutical QA, IT, validation, QC, and manufacturing teams

Computerized System Validation IQ · OQ · PQ GMP Data Integrity Risk-Based Testing

Quick answer: What do IQ, OQ, and PQ mean for computerized systems?

IQ documents that the system and its supporting components are installed and configured as approved. OQ demonstrates that specified functions and controls work across defined operating conditions. PQ provides evidence that the complete system supports its intended GMP workflows reliably in the actual or representative operating environment. These stages are a useful way to organize evidence, but regulations do not universally require three separate documents titled IQ, OQ, and PQ for every software system. The scope and depth should follow intended use, system risk, and applicable rules.

IQ checks the installed baselineConfirm identities, versions, configuration, infrastructure, and controlled setup.

OQ challenges system functionsTest critical requirements, boundaries, permissions, records, interfaces, and failure handling.

PQ follows real workflowsShow that trained users can complete intended tasks consistently with usable evidence.

Risk sets the effortPrioritize functions that can affect patient safety, product quality, or data integrity.

IQ, OQ, and PQ are familiar terms in pharmaceutical qualification, but applying them to software requires more than checking whether an application starts. A computerized system may include software, configured workflows, infrastructure, interfaces, user permissions, electronic records, and operating procedures. The qualification plan should explain how these pieces work together for the regulated process.

Why qualification matters for computerized systems

Pharmaceutical companies use computerized systems to create, process, review, approve, transfer, and retain information used in GMP decisions. A failure can do more than interrupt work: it may cause an incorrect calculation, hide a failed result, assign an approval to the wrong person, or make required records unavailable. Qualification and validation provide documented confidence that the system is fit for its intended use and remains controlled.

The governing principles are expressed through applicable cGMP requirements, the quality system, and jurisdiction-specific rules. In the United States, firms assess relevant requirements such as 21 CFR 211.68 for automatic, mechanical, and electronic equipment and, where applicable, 21 CFR Part 11 for electronic records and electronic signatures. In the EU, EudraLex Volume 4 Annex 11 addresses computerized systems used in GMP activities.

Those requirements focus on control, reliability, validation, and records. They do not create a universal rule that every application must have three stand-alone protocols called IQ, OQ, and PQ. FDA’s Q7A guidance for active pharmaceutical ingredients describes DQ, IQ, OQ, and PQ and notes that qualification activities may be conducted individually or in combination. Use those definitions carefully: Q7A is an API GMP guidance, while a site must determine the requirements that apply to its own products, operations, and markets.

Regulatory status note: As of October 2026, the European Commission’s EudraLex Volume 4 page lists Annex 11 as the January 2011 revision. A revised Annex 11 draft was published for consultation in 2025, and the consultation is closed; a consultation draft should not be presented as the operative final text unless it is formally adopted and published.

IQ, OQ, and PQ at a glance

Stage	Main question	Computerized-system evidence may include	Typical decision
IQ Installation Qualification	Is the approved system baseline installed and identified?	System name and version, architecture, environment, configured components, access setup, infrastructure evidence, installation records, and approved configuration.	Installation and baseline match approved requirements and design.
OQ Operational Qualification	Do specified functions and controls operate as intended?	Requirement-based tests, role and permission checks, audit-trail behavior, calculations, interfaces, error handling, alarms, security controls, and backup/restore tests where in scope.	Critical functions pass predefined tests or deviations are resolved and justified.
PQ Performance Qualification	Does the system support intended workflows in its operating context?	End-to-end GMP scenarios, representative data, trained users, routine procedures, connected systems, review/approval flows, and evidence that records remain usable.	The system is suitable for controlled routine use within the approved scope.

Installation Qualification (IQ) for computerized systems

IQ verifies that the system baseline is installed or provisioned as approved and that its identity is clear. For a traditional on-premises system, this may cover servers, operating systems, application versions, databases, network components, and controlled configuration. For a hosted or SaaS platform, some infrastructure evidence may be supplied by the provider, while the regulated company verifies its tenant, enabled modules, settings, interfaces, and responsibilities.

What to verify during IQ

• System identity: application name, supplier, version or release, environment, intended site, and system owner.
• Approved design: traceability to the DQ, URS, architecture, and configuration decisions.
• Installation or provisioning: evidence that required software, hardware, database, interfaces, and supporting services are present.
• Configuration baseline: enabled modules, controlled settings, time zone and time source, languages, workflows, and relevant defaults.
• Security setup: identity management, role model, administrator access, password or authentication controls, and segregation of duties as applicable.
• Data and infrastructure controls: backup responsibilities, restore arrangements, hosting location, retention expectations, and continuity evidence appropriate to risk.
• Documentation: supplier manuals, release notes, configuration records, certificates, installation records, and approved deviations.

IQ is not a second full software test. Its purpose is to establish a trustworthy and reproducible baseline so OQ and PQ results can be tied to the exact system evaluated. Changes to that baseline should later be assessed through change control.

Operational Qualification (OQ) for computerized systems

OQ challenges the system’s critical functions and controls against approved requirements. Testing should be derived from a documented risk assessment and traceable to the URS and other approved specifications. The protocol defines test conditions, expected results, acceptance criteria, evidence to capture, and how unexpected results will be handled.

OQ tests often cover

• Correct processing of representative inputs, calculations, limits, and decision rules.
• Required behavior at boundary values, invalid inputs, missing data, and interrupted transactions.
• User roles, permissions, approval sequences, access restrictions, and account lifecycle controls.
• Creation, modification, review, retrieval, and retention of regulated records.
• Audit-trail behavior and electronic-signature controls when those features are used for regulated records.
• Interfaces and data transfers, including completeness and accuracy checks at relevant boundaries.
• Alarms, error messages, exception handling, and recovery after failures.
• Backup and restore or contingency controls where the system’s risk assessment requires verification.

Not every test needs the same level of formality. High-risk functions should have strong, objective evidence; low-risk features may need less testing when a documented rationale supports that decision. A passed test should show what was tested, which version was used, the actual result, who executed and reviewed it, and whether deviations affect release.

Performance Qualification (PQ) for computerized systems

PQ evaluates whether the system works as intended within the business process and operating environment. It often brings together qualified infrastructure, validated application functions, approved configuration, connected systems, procedures, and trained users. PQ should focus on end-to-end tasks that matter to GMP decisions rather than repeat every OQ test.

For example, a laboratory information management system may be challenged with a representative workflow: create a sample, assign a test, capture or import results, apply specification rules, review the record, investigate an exception, and approve the result using authorized roles. The test should show that the complete process produces the expected record and that review evidence is retained and retrievable.

User acceptance testing can contribute to PQ when its scope, protocol, controls, and evidence meet the approved validation plan. UAT by itself is not automatically PQ, and PQ is not automatically a production trial. Define the relationship in the validation plan so reviewers can see what each activity proves.

How DQ, IQ, OQ, and PQ fit together

DQ confirms that the proposed solution is suitable for intended use before the system is built, purchased, configured, or deployed. IQ establishes the approved baseline. OQ challenges functions and controls. PQ confirms the system’s fit within its intended workflows. The IQ, OQ, and PQ labels help organize evidence, but phase boundaries may be combined where justified and traceability remains clear.

A practical computerized-system lifecycle may look like this:

1. Define intended use, system boundary, owners, users, records, interfaces, and regulated decisions.
2. Assess GxP impact and risk to patient safety, product quality, and data integrity.
3. Document critical user requirements and acceptance criteria.
4. Assess supplier capability, service responsibilities, and available evidence.
5. Review the design and configuration, then establish the controlled installation baseline.
6. Execute risk-based OQ and end-to-end PQ activities with traceable evidence.
7. Resolve deviations, assess residual risk, and approve a validation summary and release decision.
8. Maintain the validated state through access management, backups, incident handling, change control, periodic review, and retirement planning.

This lifecycle aligns with broader computerized system validation practice and the site’s SOP framework.

Risk-based acceptance criteria and traceability

Acceptance criteria should state the expected outcome in measurable or observable terms. “System works correctly” is too vague. A stronger criterion might say that a user without the required role cannot approve a result, that a changed result retains the original value and change history, or that a failed transfer is flagged and reconciled before release use.

Traceability connects each critical requirement to its risk rationale, control, test, result, deviation (if any), and final disposition. This helps reviewers see whether the test strategy covers the risks that matter. Maintain data integrity in accordance with ALCOA+ principles: records should remain attributable, legible, contemporaneous, original, accurate, complete, consistent, enduring, and available as applicable.

Example: electronic batch-record workflow

IQ: confirm the approved software release, configured plant and recipe, user roles, time settings, and required interfaces are present in the controlled environment.

OQ: test that a critical parameter outside its limit triggers the required hold or exception, that only authorized roles can release it, and that an electronic approval is linked to the record.

PQ: have trained users execute a representative batch-record workflow from initiation through review and disposition, confirming the record is complete and retrievable under routine procedures.

Supplier evidence, cloud systems, and shared responsibility

Supplier documentation can reduce unnecessary duplicate testing, but it does not transfer the manufacturer’s responsibility for the system’s GMP use. Assess what the supplier actually provides: development and release controls, testing summaries, infrastructure qualification, security and access controls, backup and recovery, incident communication, change notifications, and data export or retention capabilities.

For cloud and SaaS systems, document the boundary between provider controls and customer controls. The provider may operate the platform infrastructure, while the pharmaceutical company remains responsible for intended use, tenant configuration, role assignment, approved workflows, data governance, procedures, and decisions about records. Verify that service agreements and technical controls support the quality agreement and continuity needs.

Common IQ OQ PQ mistakes to avoid

• Using templates without tailoring: generic scripts may not test the real GMP workflow or system configuration.
• Testing only the happy path: errors, limits, access restrictions, interfaces, recovery, and exceptions can be the highest-risk behaviors.
• Calling every test PQ: identify whether a test proves installation, function, or end-to-end performance.
• Repeating vendor tests blindly: review vendor evidence, assess relevance, and add site testing for configuration and intended use.
• Ignoring records and audit trails: assess completeness, attribution, reviewability, retention, and retrieval—not just screen behavior.
• Releasing with unresolved deviations: document impact, correction or mitigation, retest needs, residual risk, and authorized disposition.
• Treating go-live as the end: changes, incidents, suppliers, periodic review, and retirement can affect validated state.

When an unexpected result occurs, document and investigate it under the quality system. Link corrective and preventive actions to the appropriate CAPA process when warranted.

What should the qualification package contain?

• System description, intended use, boundaries, interfaces, owners, and GxP impact assessment.
• Risk assessment and validation plan with rationale for the selected IQ/OQ/PQ scope.
• Approved requirements and design/configuration documentation.
• Supplier assessment and referenced vendor evidence.
• Installation or provisioning records and controlled baseline information.
• Approved test protocols, traceability matrix, raw test evidence, and execution records.
• Deviation records, investigations, retests, and residual-risk decisions.
• Training, operating procedures, access controls, backup/restore or continuity evidence, and release approval.
• Validation summary report and post-release lifecycle controls.

Records should be controlled and attributable to the people, dates, system versions, and decisions involved. This supports inspection readiness and consistent operation under CAPA, change control, and the wider quality system.

Frequently asked questions

1. What is IQ in computerized system validation?

Installation Qualification documents that a computerized system and its supporting components are installed or provisioned in line with approved requirements, design, and configuration.

2. What is OQ for pharmaceutical software?

Operational Qualification tests whether specified software functions and controls work as intended under defined conditions, including critical limits, roles, records, interfaces, and error handling.

3. What is PQ for a computerized system?

Performance Qualification demonstrates that the complete system supports its intended GMP workflows reliably in its actual or representative operating environment with trained users and approved procedures.

4. Are IQ, OQ, and PQ mandatory for every computerized system?

No single universal rule requires three separate documents with these exact titles for every system. Applicable GMP rules require appropriate controls and validation; the documented approach should be justified by intended use and risk.

5. Can IQ, OQ, and PQ be combined?

Yes, where the approach is justified, approved, and traceable. FDA’s Q7A guidance describes qualification activities as individually or jointly conducted, but firms must apply requirements relevant to their product and jurisdiction.

6. Does vendor testing replace site qualification?

Not automatically. Supplier evidence can support the validation package when its scope and quality are assessed, but the site must verify its own configuration, intended use, workflows, access, interfaces, and local procedures.

7. Is user acceptance testing the same as PQ?

No. UAT may contribute to PQ if it follows an approved, controlled, risk-based protocol and produces suitable evidence. The validation plan should explain what each test proves.

8. How does IQ/OQ/PQ apply to SaaS systems?

For SaaS, provider evidence may cover platform infrastructure and release controls, while the customer verifies tenant setup, configuration, roles, workflows, records, interfaces, and shared responsibilities.

9. What is the difference between OQ and PQ?

OQ challenges functions and controls against requirements; PQ demonstrates that end-to-end workflows perform effectively in the intended operating context.

10. When should a computerized system be requalified?

Assess changes, incidents, upgrades, infrastructure or supplier changes, recurring errors, and periodic-review findings for impact. Perform targeted regression testing or broader requalification when risk and evidence show it is needed.

Conclusion

IQ, OQ, and PQ provide a clear way to organize qualification evidence for computerized systems: establish the approved baseline, challenge critical functions, and demonstrate performance in intended workflows. Their value comes from risk-based scope, traceable requirements, meaningful acceptance criteria, credible evidence, and lifecycle controls—not from producing three documents as a formality. Connect your approach to the applicable GMP requirements, computerized system validation program, and controlled procedures.

Authoritative references

• European Commission: EudraLex Volume 4, including Annex 11 and Annex 15
• European Commission: Annex 11, Computerised Systems (January 2011)
• European Commission: 2025 consultation on revised Chapter 4, Annex 11, and new Annex 22
• FDA: Q7A Good Manufacturing Practice Guidance for Active Pharmaceutical Ingredients, sections 5.4 and 12.3
• FDA: Part 11, Electronic Records; Electronic Signatures—Scope and Application
• Electronic Code of Federal Regulations: 21 CFR Part 11
• Electronic Code of Federal Regulations: 21 CFR 211.68, Automatic, Mechanical, and Electronic Equipment

Editorial note: This article is an educational overview, not a substitute for a site-specific regulatory assessment. Confirm current requirements for the product, process, market, and system in scope.