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.
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.
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.
A successful IQ usually addresses:
|
Three essential documents here:
In our experience, most IQ protocols are adequate. Few are good. Here's where teams leave value on the table all the time.
|
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.
OQ test parameters vary by equipment type, but common items include:
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.
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.
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.
Best practices for writing IQ protocolsHere are several nuanced strategies that are often overlooked.
|
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) 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.
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:
Here are some indicative signals of a successful OQ:
Best practices for writing OQ protocolsHere are several nuanced strategies that are often overlooked.
|
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.
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:
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:
More details on specific FDA expectations for PQ and PPQ can be found in the guidance document here.
Best practices for writing PQ and PPQ protocolsHere are several nuanced strategies that are often overlooked.
|
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.
“I've been an engineer for 30 years. I've seen the transition from when I was a young engineer and it was all about testing; understanding every possible question that the engineers thought of. You had VPs of engineering that were part of the management team. 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:
“The advice—the ideal world is, you plan to set your requirements, you make sure your requirements align well with your design, inputs, and outputs. It should be smooth sailing from there; making sure everybody's involved early on, including manufacturing. But a lot of companies don't fully understand that or they didn't fully guage the budget to allow for that properly, so they find themselves in a bind. 'What is the minimum we have to do?' is the approach they tend to take.”
— Devin Mack, Life Science Consultant
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.
“How do you know you've met success? It's by doing things in a proven way. And you know, a big part of that is understanding your customer. So then you get into human factors. You hear user experience and human factors requirements. And then, again, it all comes back to setting proper requirements—having a good understanding of what your customer needs are and what your customer wants. 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
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:
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.