The IQ/OQ/PQ framework — installation qualification, operational qualification, and performance qualification — is the standard structure for executing that validation. FDA’s 21 CFR Part 11, EU Annex 11, and ISO 13485 Section 7.6 all require that computerized systems be validated, and all expect the IQ/OQ/PQ approach as the documented evidence of that validation.

FDA’s 2022 Computer Software Assurance (CSA) guidance updated the agency’s thinking: it shifted the emphasis from documentation volume toward risk-based testing that focuses validation effort on the system functions that matter most for patient safety and product quality. This guide explains the IQ/OQ/PQ framework, how CSA changes the approach, and what executing each protocol actually requires.

Why computer system validation matters

A computerized system that is not validated is a compliance liability on multiple fronts. Under 21 CFR Part 11, electronic records generated by an unvalidated system may not be accepted as equivalent to paper records. Under 21 CFR Part 820 (QMSR) and ISO 13485, using unvalidated software for quality-critical functions — document control, CAPA management, complaint handling — is itself a nonconformance. Under 21 CFR 211.68, pharmaceutical manufacturers must validate computer systems used in drug manufacturing and testing.

FDA warning letters and 483 observations for computer system validation failures are consistent: the most common findings are no validation at all, validation completed after the system went live, or validation protocols that were never fully executed.

The risk-based approach: GAMP 5 and FDA’s CSA guidance

GAMP 5 (Good Automated Manufacturing Practice, 5th edition) from ISPE is the industry-standard framework for risk-based computer system validation. It categorizes software by type — infrastructure software, non-configured commercial software, configured commercial software, custom software — and scales the validation effort to the category and the system’s impact on regulated activities.

FDA’s 2022 CSA guidance aligned with this risk-based philosophy. CSA distinguishes between “verification activities” (the technical testing that confirms the system works) and “documentation” (the records that demonstrate compliance). CSA’s message is that documentation should support verification, not replace it — validation time should be spent on testing functions that matter, not on scripted testing of vendor-provided features that have already been verified by the vendor.

In practice, the IQ/OQ/PQ structure remains the standard. What changes under CSA is the depth and formality of documentation relative to the system’s risk level. A low-risk infrastructure tool may require a streamlined validation package. A high-risk system used for GMP batch release or CAPA management requires more thorough testing and more comprehensive records.

The Validation Master Plan

Before executing individual IQ/OQ/PQ protocols, a Validation Master Plan (VMP) or equivalent planning document must define the overall approach. The VMP establishes:

• The scope of systems subject to validation
• The risk classification criteria used to determine validation depth
• The organization’s overall validation lifecycle policy
• Roles and responsibilities for validation activities
• The standard format for validation protocols and reports
• The change control and periodic review requirements for validated systems

Individual system validations reference the VMP. They do not need to re-establish the policy each time — they simply document how the policy is applied to the specific system being validated.

User Requirements Specification (URS)

Every computer system validation begins with a User Requirements Specification. The URS defines what the system must do — in business and regulatory terms — before any technical design decisions are made. It is the benchmark against which the system is tested in OQ and PQ.

A well-written URS distinguishes between requirements (what the system must do) and implementation details (how it does it). Requirements must be testable — vague requirements like “the system must be easy to use” cannot be validated. Specific requirements like “the system must require a reason for change whenever a document is revised” can be tested and confirmed.

The URS must capture 21 CFR Part 11 requirements explicitly: unique user IDs, password controls, audit trail with user identity, timestamp, and original/changed values, electronic signature binding, and system access controls. These are regulatory requirements, not vendor-optional features.

Installation Qualification (IQ)

IQ documents that the system has been installed correctly and that the installation environment meets the prerequisites for the system to function as specified. IQ is primarily a verification activity — it confirms facts about the installed state rather than testing system behavior.

What IQ covers

• Software version verification: confirm the installed version matches the validated and approved version
• Hardware inventory and specification check: confirm servers, workstations, and network infrastructure meet minimum requirements
• Operating system and database version confirmation
• Security configuration: user authentication settings, password policy settings, network security controls
• Data backup and recovery procedures are in place and documented
• System documentation inventory: vendor IQ documentation, configuration specifications, system architecture diagrams
• Access control setup: confirm that the system’s user roles and permissions structure is installed as configured

IQ does not test whether the system works — it confirms that the foundation is in place for OQ testing to proceed. IQ failures typically involve missing documentation, version mismatches, or infrastructure components that do not meet specifications.

Operational Qualification (OQ)

OQ tests that the system functions as designed across its specified operating range and under both normal and boundary conditions. OQ verifies functional requirements from the URS — it tests the system’s behavior, not just its installation state.

OQ test design principles

Under FDA’s CSA guidance, OQ tests should focus on the system functions that carry the highest regulatory risk. For an eQMS, that means the CAPA workflow, the document approval chain, the electronic signature function, the audit trail, and the access control enforcement. It does not mean testing every dropdown menu and every report format.

Each OQ test script must include:

• The specific function being tested, linked to the URS requirement it verifies
• The preconditions (test data, user role, system state) before the test is executed
• The step-by-step test procedure
• The expected result, defined before the test is executed
• Space for the actual result and a pass/fail determination
• Tester identification and date, captured at the time of execution

OQ tests must include negative testing — attempts to perform actions that should be blocked by the system. An audit trail test that only confirms audit trail entries are created when records change does not test whether the audit trail can be modified or deleted. Negative testing closes that gap.

Key OQ areas for regulated systems

• Audit trail: Verify that every create, modify, and delete action on regulated records generates a timestamped, user-attributed audit trail entry. Verify that the original value is retained and visible. Verify that audit trail entries cannot be modified or deleted by any user, including administrators.
• Electronic signatures: Verify that signature prompts require password re-entry. Verify that the signed record links the signer’s identity, meaning, and timestamp. Verify that signatures cannot be applied to a different record or transferred.
• Access control: Verify that users can only access and modify records consistent with their assigned role. Verify that unauthorized actions are blocked and generate an error, not a silent failure.
• Workflow enforcement: Verify that controlled workflows (document approval, CAPA closure, deviation escalation) cannot be bypassed — that no user can skip a required step.

Performance Qualification (PQ)

PQ confirms that the validated system performs correctly in its actual production environment, with real users, real data, and real workloads. It bridges the gap between the controlled OQ environment and routine use.

PQ is often structured as user acceptance testing (UAT). It uses test scenarios drawn from actual business processes — not abstract functional tests, but real workflows executed by the people who will use the system daily. A PQ scenario for an eQMS might be: “A quality manager initiates a CAPA from a deviation record, assigns tasks to two corrective action owners, approves the corrective actions, and closes the CAPA. Verify that all workflow steps are enforced, that audit trail entries are generated at each step, and that the closed CAPA is locked against further modification.”

PQ test cases should cover the highest-volume and highest-risk processes. Edge cases and unusual scenarios are addressed in OQ. PQ focuses on confirming that the system supports the business processes it was implemented to replace or support.

Validation report and system release

Following IQ, OQ, and PQ execution, a Validation Summary Report documents the test results, any deviations encountered, the disposition of those deviations, and a formal conclusion that the system is validated and released for use. The report must be approved before the system goes live in production use.

Deviations from test scripts — unexpected results, failed tests, scope changes — must be documented as they occur and resolved through a formal deviation management process. A deviation that is discovered, silently corrected, and not recorded in the validation record is a data integrity failure, not a technical issue.

Change control and periodic review for validated systems

Validation does not end at system release. Validated systems must be controlled through a change management process that evaluates the impact of any change — software updates, configuration changes, new user role definitions, infrastructure changes — on the validated state. Changes that could affect validated functions require re-validation of the affected areas before implementation.

Periodic review is a separate requirement: at defined intervals (typically annually or biennially), the validated state of each system must be confirmed. The review assesses whether the system continues to be used as intended, whether any uncontrolled changes have occurred, whether there are outstanding deviations or open nonconformances, and whether the validation documentation remains current and complete.

Validation of a pre-validated eQMS platform

Many regulated companies use commercial off-the-shelf (COTS) eQMS platforms that are supplied with a vendor validation package — also called a pre-validation package, vendor qualification package, or Installation Qualification package from the vendor. This package documents the vendor’s own testing of the software’s standard functions.

A vendor validation package does not replace the customer’s validation obligation. The customer must still execute IQ to confirm correct installation in their specific environment, OQ to confirm that the configured system meets their specific URS requirements, and PQ to confirm that the system supports their specific business processes. The vendor package reduces the customer’s burden for testing standard vendor-provided functionality, but it does not cover the customer’s unique configuration or their specific regulatory requirements.

Cloudtheapp provides a complete validation package with every platform update, covering IQ documentation and standard functional testing for all 60+ applications. Customer organizations execute their OQ and PQ against their specific configuration and business processes, with Cloudtheapp’s validation documentation serving as the IQ foundation. The platform is built and maintained in compliance with FDA 21 CFR Part 11 and 21 CFR Part 11 electronic records and signature requirements.

To see how Cloudtheapp’s pre-validated platform reduces your CSV burden while meeting FDA and ISO 13485 requirements, request a demo.

Summary

Computer system validation through IQ, OQ, and PQ is a regulatory requirement for any system used in quality-critical or GMP functions. IQ confirms correct installation. OQ tests that the system functions as specified, with particular depth on audit trail, electronic signatures, access control, and workflow enforcement. PQ confirms the system performs correctly in the actual production environment with real users and real processes. FDA’s CSA guidance directs validation effort toward risk-based testing rather than documentation volume. Change control and periodic review keep validated systems in a validated state. A pre-validated commercial platform reduces the CSV burden — but the customer’s OQ and PQ remain their responsibility.

This post created by and appeared first on Cloudtheapp