In pharma, medical devices, and clinical settings, equipment that drifts even slightly outside its validated parameters can produce defective products. And defective products in these industries don't just mean returns or refunds. They mean patient safety events, FDA warning letters, consent decree risk, and product recalls that can cost tens of millions.
Equipment validation through IQ, OQ, PQ is how organizations prove, with documented evidence, that their production systems are under control. The FDA expects it. ISO 13485 requires it. And auditors will look for gaps.
If you’re planning a validation project, be sure to grab our free guide. Inside, you’ll find seven essentials to building an efficient and effective validation team along with expert insights from staffing professionals who routinely help life science organizations build successful project teams.
What are IQ, OQ and PQ?
IQ, OQ and PQ protocols are methods for demonstrating that equipment being used or installed will offer a high degree of quality assurance, such that production processes will consistently manufacture products that meet quality requirements.
Since these concepts are complex, it’s best to understand them individually.
Installation Qualification (IQ)
Before any equipment can be operationally tested, it first needs to pass Design Qualification (DQ), which documents that the proposed design can meet its intended requirements. IQ picks up after DQ.
IQ answers one question: Was this equipment installed correctly?
That means verifying that the physical unit or software system has been set up according to the manufacturer's specifications. For hardware, this includes confirming adequate floor space, proper environmental conditions, correct power supply, and no physical damage to the unit. For software, IQ covers things like verifying folder structures, checking minimum system requirements, and confirming correct installation pathways.
The FDA defines IQ's goal as documenting that the "system has the necessary prerequisite conditions to function as expected."
Any CGMP requirements relevant to the IQ and the methodology used must be documented in the Validation Master Plan (VMP). Re-qualification is required after major maintenance, modifications, or as part of routine quality assurance.
What IQ typically covers
A successful IQ usually addresses:
|
IQ documentation requirements
Three essential documents here:
- The IQ Protocol is the planning document. It defines the scope, methodology, and pass/fail criteria. It should include equipment identification details (model, serial number, manufacturer), a list of systems to be qualified, installation requirements per manufacturer specs, environmental requirements, and a verification checklist.
- The IQ Checklist translates the protocol into actionable steps, covering physical installation, electrical connections, calibration, software, and environmental conditions.
- The IQ Report documents what happened during execution. It summarizes findings, observations, and results, and states clearly whether the installation met the predefined criteria.
Writing better IQ protocols
In our experience, most IQ protocols are adequate. Few are good. Here's where teams leave value on the table all the time.
Operational Qualification (OQ)
OQ begins only after IQ is complete and all IQ protocols have been met. Its purpose is to determine whether equipment performance is consistent with user requirement specifications within the manufacturer's operating ranges.
In practice, OQ means identifying every equipment feature that can affect product quality and testing it systematically.
OQ functions as a detailed review of hardware or software startup, operation, maintenance, cleaning, and safety procedures. Every unit must be shown to be operating within its specified limits.
What OQ typically tests
OQ test parameters vary by equipment type, but common items include:
- Temperature control and distribution
- Servo motors and air flaps
- Temperature protection systems
- Card readers and access systems
- Pressure and vacuum controllers
- Display units and signaling LEDs
- CO2 controls
- Humidity measurement and control
- Fan and fan-speed controllers
Signals of a successful OQ
A few indicators that an OQ went well:
All operational tests met or exceeded the predefined acceptance criteria. No significant deviations or nonconformities occurred during testing. The equipment's built-in error detection and handling mechanisms responded correctly to simulated errors. Where applicable, the equipment integrated with other systems without compatibility issues. Operators who interacted with the equipment during OQ provided positive feedback on usability and function. And the documentation was complete enough to support moving into PQ.
OQ documentation requirements
The OQ Protocol should define objectives, scope, methodology, and acceptance criteria. The objectives state what the OQ is testing. The scope identifies the specific equipment, systems, and processes included. The methodology describes step-by-step test procedures. And the acceptance criteria specify measurable standards based on manufacturer specs, regulatory requirements, and user needs.
OQ Test Scripts and Checklists provide detailed instructions for executing each test, including steps to follow, observations and measurements to record, and expected outcomes.
The OQ Report documents everything that happened during testing: methodology used, results of each test, deviations from protocol (with impact analysis and corrective actions), and a summary statement on whether the equipment passed.
SOPs relevant to the equipment should be referenced in the OQ documentation, including operating procedures, maintenance and calibration procedures, and deviation-handling procedures.
Calibration and Maintenance Records prove that the equipment was properly calibrated and maintained before and during OQ. Without these, test results can't be considered reliable.
A Traceability Matrix connects the requirements in the DQ and user requirement specifications (URS) to the tests conducted during OQ. This document is how you prove that every operational parameter has been tested against a requirement.
Writing better OQ protocols
This is where many teams underinvest. A mediocre OQ protocol can produce a passing result that still leaves gaps an auditor or a production failure will find later.
Test the full operating range. Don't just test at nominal conditions. Run tests at the upper and lower limits of the equipment's operational range. For a tablet press, that means testing at the lowest and highest speed settings to confirm that tablet weight and hardness stay within spec across the entire range. Equipment that performs at the midpoint but drifts at the edges isn't truly qualified.
Simulate failure modes on purpose. Create controlled failure scenarios to verify that the equipment's error detection and handling systems actually work. If the equipment is supposed to shut down when temperature exceeds a threshold, prove it. This is the kind of testing that separates a protocol written to pass from a protocol written to protect production.
Test interoperability with connected systems. If the equipment communicates with a LIMS, an ERP system, or other instruments, test those connections during OQ. For a LIMS integration, that means verifying data transmission from analytical equipment to confirm correct data exchange and parsing. Compatibility failures discovered during production are significantly more expensive than discovering them during OQ.
Vary environmental conditions. Temperature and humidity in a production environment are rarely constant. Test the equipment under the range of conditions it will actually encounter. If the facility experiences seasonal temperature swings, factor that into your OQ test plan.
Verify data integrity. In regulated industries, data integrity is a top audit focus. Test whether the equipment records and reports data accurately and securely. Define user roles (operator, supervisor, maintenance), then attempt actions outside each role's access level. Can an operator-level login change critical process parameters? If yes, you have a data integrity problem to fix before PQ.
Run sequential operation tests. Production equipment rarely performs a single function in isolation. Design tests that require the equipment to operate through its full sequence, reflecting actual use in a production cycle. This verifies correct order, timing, and handoffs between process steps.
Load test properly. Run OQ tests under different load conditions, including maximum capacity. Equipment that performs at half capacity but can't sustain quality at full load is a production risk hiding in plain sight.
Document the "why" behind each test. Don't just list test steps. Explain why each test is included, how it connects to operational reliability, and what risk it addresses. This context helps future teams understand the protocol's intent and makes regulatory review smoother.
Involve multiple departments. Quality, engineering, production, and IT should all contribute to the OQ test plan. Each group brings a different perspective on what could go wrong and what needs to be verified.
Ensure that all individuals involved in executing the IQ protocol are trained on the equipment and the importance of thorough and accurate documentation practices. This training should emphasize the role of documentation in regulatory compliance and quality assurance.
Operational Qualification (OQ)
Operational qualification (OQ) is performed after meeting each protocol of IQ. OQ’s purpose is to determine that equipment performance is consistent with the user requirement specification within the manufacturer-specified operating ranges. In action, this means identifying and inspecting equipment features that can impact final product quality.
During OQ, all items in the test plan are tested and their performance is thoroughly documented. Since this is a prerequisite for acceptance of equipment and the facility, it can only be conducted once the IQ is run.
Read also: 5 Steps to Creating an Effective Life Science Validation Team
In general, OQ serves as a detailed review of hardware or software startup, operation, maintenance, cleaning, and safety procedures (if and where they’re applicable). Every unit of hardware and software must be shown to be operating within the specified limits.
What makes OQ successful?
As we explained above, the action items of OQ are identifying and inspecting the components of equipment that impact product quality and ensuring they’re operating within specific limits.
These often include (but, again, are in no way limited to) the following:
- Temperature control and variations
- Servo motors and air flaps
- Temperature protection systems
- Card readers and access systems
- Pressure and vacuum controllers
- Temperature distribution
- Display units and signaling LEDs
- CO2 controls
- Humidity-measuring and control
- Fan and fan-speed controllers
Here are some indicative signals of a successful OQ:
- All operational tests meet or exceed the predefined acceptance criteria detailed in the OQ protocol. This is the most direct signal of success, indicating that the equipment performs reliably within its operational range.
- No significant deviations or non-conformities during testing suggest that the equipment operates correctly and consistently. Minor deviations are addressed and resolved without impacting the equipment’s ability to meet its intended use.
- The equipment's built-in error detection and handling mechanisms function as expected, correctly identifying and responding to simulated errors or failures. This capability is crucial for maintaining operation integrity under adverse conditions.
- If applicable, the equipment seamlessly integrates with other systems or processes, without any compatibility issues or disruptions. This indicates that the equipment can be incorporated into the broader operational workflow efficiently.
- Feedback from operators and end-users who interact with the equipment during the OQ phase is positive, indicating that the equipment is user-friendly and performs its intended functions effectively.
- The successful completion of OQ, with all criteria met and documented, indicates the equipment is ready to proceed to the next phase of qualification, PQ, where it will be tested under actual production conditions.
Essential OQ documentation
- The OQ Protocol: The OQ protocol is a comprehensive document that outlines the objectives, scope, methodology, and criteria for conducting the OQ. It should include:
- Objectives: Clearly define what the OQ aims to achieve, including specific operational parameters and functions to be tested.
- Scope: Detail the equipment, systems, and processes included in the OQ.
- Methodology: Describe the step-by-step procedures for conducting the operational tests, including any specific conditions or setups required.
- Acceptance Criteria: Specify the measurable criteria that the equipment must meet to pass each test. These criteria should be based on the manufacturer’s specifications, regulatory requirements, and user needs.
- OQ Test Scripts/Checklists: These are detailed instructions or checklists used to conduct the operational tests outlined in the OQ protocol. They include:
- Specific steps to execute each test.
- Required observations and measurements to be recorded.
- Expected outcomes based on the acceptance criteria.
- OQ Report: The OQ report documents the execution and outcomes of the OQ testing. It includes:
- A brief overview of the OQ objectives and scope.
- A summary of the testing methodology used.
- Detailed results of each test, including any measurements or observations made. This section should clearly indicate whether the equipment met the defined acceptance criteria.
- Any deviations from the protocol, including unexpected results or failures, should be documented along with an analysis of their impact and any corrective actions taken.
- A summary of the OQ findings, stating whether the equipment has successfully passed the operational qualification based on the predefined criteria.
- SOPs: While SOPs are not unique to the OQ phase, they play a crucial role in ensuring that the equipment is operated correctly and consistently for OQ testing. Relevant SOPs should be referenced in the OQ documentation, including:
- Operating procedures for the equipment.
- Maintenance and calibration procedures.
- Procedures for handling and documenting deviations
- Calibration and Maintenance Records: Documentation proving that the equipment was properly calibrated and maintained before and during the OQ tests is essential. These records help validate the accuracy and reliability of the test results.
- Traceability Matrix: A traceability matrix connects the requirements specified in the DQ and user requirement specifications (URS) to the tests conducted during OQ. This document ensures that all necessary operational parameters have been tested and validated against the requirements.
Remember to clearly explain why each test is included, its relevance to operational reliability, and how it addresses potential risks or compliance requirements. Involve representatives from quality, engineering, production, and IT to ensure all perspectives are considered in the test plan, enhancing its comprehensiveness and applicability. Lastly, design the protocol to include a process for reviewing test results and incorporating feedback into the protocol or operational procedures as necessary.
Performance Qualification (PQ)
The final step of qualifying equipment is PQ. In this phase, the qualification and validation team verifies and documents that the user requirements are verified as being met. These user requirements should include the normal operating range required (as defined and signed off on by QA and verified in the DQ). Once you've qualified the equipment, you can develop each process required for each product. Then, once each process is fully developed, it can be validated.
Instead of testing components and instruments individually, PQ tests them all as a partial or overall process.
Before they start qualifying, however, the team must create a detailed test plan based on the process description. It’s important to note that the qualification's quality largely depends on the test plan's quality. This is one area where a third-party specialist can (and often should) be brought in to ensure thoroughness and accuracy.
The Process Performance Qualification (PPQ) protocol is a fundamental component of process validation and qualification. Its purpose is to ensure ongoing product quality by documenting performance over a period of time for certain processes.
FDA Criteria for PQ and PPQ Protocols
In its guidance, “Process Validation: General Principles and Practices,” the FDA officially defines the PQ stage into its two elements:
- Design of the facility and qualification of the equipment and utilities
- Process Performance Qualification (PPQ)
During the second stage, the FDA states in its guidance that “CGMP-compliant procedures must be followed,” adding that “successful completion of Stage 2 is necessary before commercial distribution.”
The FDA guidance recommends including the following elements as part of PQ and PPQ protocols:
- Manufacturing conditions such as equipment limits, operating parameters, and component inputs
- A thorough list of the data that should be recorded or analyzed during tests, calibration, and validation
- Tests to ensure consistent quality throughout production
- A sampling plan detailing the sampling methods used during and in between production batches
- Analysis methodology for making data, scientific and risk-oriented decisions based on statistical data
- Definitions for variability limits and contingency plans for handling non-conformance
- Approval of the PPQ protocol by relevant departments, namely the Quality Unit.
More details on specific FDA expectations for PQ and PPQ can be found in the guidance document here.
Overcoming One of the Biggest Challenges to Achieving IQ, OQ, PQ Success
While the basics of IQ, OQ, PQ are critically important to understand and implement, it’s also critical to acknowledge the challenges teams encounter when doing this work in the field.
Trying to address all—or even most—of these challenges would be too ambitious for a guide like this. So instead, we asked one of our own validation experts to identify and unpack the one challenge he sees and solves most often: navigating the conflict between business goals and the deadlines attached to them—with everything needed to build a complete technical file.
Devin Mack has been steeped in product development, R&D, quality, regulatory, and manufacturing work for more than 28 years. Part of his work as a consultant involves helping life science companies align their quality management systems—including risk management and validation testing methods and procedures—between worldwide facilities, customers, and third-party vendors. Having encountered countless IQ, OQ, PQ challenges, he cites requirements gathering at the outset of a project to be among the most common, and most consequential, challenges, making it also the most impactful to handle proactively.
Here’s Devin on the broader challenge of proper planning that can have a downstream impact on activities including IQ, OQ, PQ.
“I think the crux of the matter is, you know, companies will go through their product realization process, and then they get to design transfer, and they start trying to get their technical files together. And then they realize, ‘Oh, we don't have validated systems. We didn't, validate any processes, we didn't validate the customer requirements. And further, beyond that, we don't really have a true understanding of what the requirements are.’
So in the end, it routes back to not having proper requirements set at the outset. And then due to [what amounts to] laziness, the rush to get stuff done, nobody takes the time to dot the I's and cross the T's making sure that the validation and verification goals match up with those design inputs and user needs.
So, things get lost and confused because of the rush to meet deadlines. Or [teams] start skipping steps of documentation and don’t have a true understanding of their operational window and performance window. That's your OQ and PQ. And then, why bother with the proper paperwork for your equipment, and that's the IQ. So, it all comes down to the conflict between business goals, deadlines, and the mere misunderstanding of what's actually, you know, one of the must-haves to get your technical file buttoned up.
I think a lot of the ‘business’ sides of companies don’t have a full understanding of what they’re getting into. Let's say [a company] is new to [the] medical device [space]. They didn't plan for all the properly proposed testing or the time to develop the documentation to understand how well is this thing performing compared to what we're claiming it to do. And maybe they think that they can rely on predicate devices or other devices that are already out there. In the end, they're going to find that they can't, they can't fully rely upon somebody. They actually have to get the testing done on their particular products.”
— Devin Mack, Life Science Consultant
One of the main drivers of this bigger planning problem, Devin says, is a decades-long transition of influence from the engineering department over to the commercial team.
The differing priorities between these functions can create tension that’s often uncomfortable to acknowledge, let alone confront. But as Devin explains, changes in regulatory pressures are encouraging at least some re-balancing.
But then that slowly transitioned. You no longer really have VPs of engineering anywhere these days. It's very driven by commercial, and a lot of companies have found themselves writing justifications or rationale to avoid the amount of testing that they would have done 30 years ago.
But now, I think that's changing. With the new European Medical Device Regulations coming into play, a lot of companies are pretty much faced with, ‘okay, we have, we actually do have to go back and test more than what we thought.’ It might not be to the extreme of 30 years ago, but it's probably halfway there as far as companies having to show actual data about how their products perform and show that they have control over their product realization process. So that's where, you know, IQ, OQ, OQ is pretty hot now.”
— Devin Mack, Life Science Consultant
When helping teams resolve this tension, Devin says his advice typically lands on a few points depending on the situation:
- Challenge any assumptions being made early in the product realization process—especially those that justify omitting certain activities from work plans.
- Devote ample time to, and be thoughtful about, laying out the full set of requirements for a given product with input from every impacted department.
- Acknowledge that few decisions can ever be responsibly made in a silo, especially early on. Don’t presume that a team need only be involved later on in the process.
— Devin Mack, Life Science Consultant
Measuring IQ, OQ, PQ Success as a Function of Quality by Design
Like other critical steps in the lifecycle of a product, Devin suggests the effectiveness of qualification drives down to the approach of quality by design—doing things in ways that have proven to be effective time and again. Following this philosophy means, in this context, understanding your customers by identifying and human factor requirements and making them actionable design inputs.
What do customers need and want—and how can a team diagram those requirements so they can be interpreted at an engineering level? Genuine success can really only be measured by meeting these kinds of requirements, which underscores just how important identifying those requirements is early in the design process.
Diagramming that out, on your own, you have several ways of doing that. You have your value chain analysis. You have your Kano diagram, you have customer surveys. [All of these tools help you] interpret [requirements] at an engineering level. If you've met what the customer wants, then that's what success is. If you've met the expected lifetime that you have chosen for that device to have, then that is what success is.
If your requirements are properly set, so that your acceptance criteria outlined in your IQ, OQ, PQ are met, then that is what success is. But again, if they're vague and unclear, companies will struggle with not understanding what success is.”
— Devin Mack, Life Science Consultant
An Effective, Cost-Efficient Model for Accessing Qualification & Validation Services
For most organizations, equipment qualification and validation are not a constant need, so performing it in-house is seldom advantageous—sometimes outright infeasible.
Rather than filling a traditional full-time role, many life science organizations work with resourcing firms that can locate and place qualified professionals through a flexible contract staffing/staff augmentation model.
This arrangement brings a number of advantages to quality departments and hiring managers:
- Providing access to qualified personnel in an increasingly competitive labor environment
- Freeing up time and attention within your internal teams
- Reducing the costs of recruiting, screening, and onboarding staff
Unlike traditional full-time hiring, a flexible contract staffing model combined with a large, global staff of qualified personnel enables better adjustment with cyclical or project-based demand while infusing new skills and experiences into the team.
Learn more about this, and other engagement models we utilize to help thousands of life science companies get the QA, RA, Clinical Operations, Qualification, and Validation, and Manufacturing and Engineering resource and project support they need—where and when they need it:
Qualification & Validation Services:
Want to learn more about building an effective qualification and validation team? Grab our free white paper below. Need a life science specialist or team to support a current or upcoming project? Submit the form below to tell us a little about yourself and your project or resource needs. We'll follow up within one business day.
