Web of Pharma · Qualification · Validation · GMP
IQ, OQ, PQ and DQ in Pharmaceutical Validation
A practical, audit-ready guide to Design Qualification, Installation Qualification, Operational Qualification, and Performance Qualification for pharmaceutical equipment, utilities, facilities, and computerized systems.
Featured image space
Upload a professional 16:9 pharmaceutical validation image here, then replace this placeholder with the image element after uploading it to Blogger.
answer
IQ, OQ, PQ, and DQ are linked qualification stages used to show that a pharmaceutical facility, utility, equipment item, process-support system, or computerized system is properly designed, correctly installed, operates within approved limits, and performs consistently for its intended use. DQ confirms the design is suitable; IQ verifies installation; OQ challenges operating functions and ranges; and PQ demonstrates reliable performance under routine, intended-use conditions.
Qualification is the evidence-based bridge between an approved design and dependable pharmaceutical performance. It turns engineering decisions into documented proof that an asset can support product quality, patient safety, data integrity, and a controlled manufacturing process.
In a regulated facility, a new tablet press, purified-water loop, HVAC system, sterilizer, filling line, laboratory instrument, warehouse monitoring system, or computerized application cannot be accepted only because it has been purchased and switched on. The organization must define intended use, identify critical aspects, verify installation, challenge operation, and confirm performance under approved conditions.
This article explains the full IQ OQ PQ DQ sequence in practical language. Use it with your site validation master plan, approved procedures, engineering standards, risk assessments, and applicable cGMP requirements. The depth of testing should be justified by intended use, product and patient risk, supplier evidence, system complexity, and the controls already established at the site.
What Are IQ, OQ, PQ, and DQ?
The four qualification stages answer different questions. Treating them as interchangeable creates gaps in evidence; treating them as isolated paperwork creates unnecessary duplication. A sound program connects each stage to the requirements and risks identified earlier in the lifecycle.
| Stage | Core question | Typical evidence | Approval outcome |
|---|---|---|---|
| DQ Design Qualification | Was the proposed design selected and specified for its intended pharmaceutical use? | URS traceability, design review, drawings, specifications, risk assessment, supplier evaluation | Design is approved for procurement or implementation. |
| IQ Installation Qualification | Was the approved equipment or system received and installed correctly? | Asset identity, components, utilities, materials, manuals, calibration, certificates, installation checks | Installation is complete and ready for controlled operation testing. |
| OQ Operational Qualification | Do functions, controls, alarms, interlocks, and operating ranges work as specified? | Functional tests, challenge conditions, alarm tests, set-point checks, software configuration, deviations | Operations are demonstrated within approved operating limits. |
| PQ Performance Qualification | Does the qualified asset perform consistently for its intended process or use? | Routine runs, approved materials, trained operators, process data, acceptance criteria, trend review | Performance is acceptable for release to routine use. |
The Qualification Lifecycle at a Glance
A lifecycle approach keeps requirements, risks, tests, and decisions connected from the first concept through retirement. The order below is a practical model; approved site procedures may use different names or combine activities.
Define intended use
State what the asset must do, what it can affect, and which quality attributes or data must remain controlled.
Identify critical aspects
Use quality risk management to determine critical parameters, functions, alarms, materials, utilities, and records.
Generate evidence
Execute approved protocols with trained personnel, calibrated instruments, controlled forms, and traceable results.
Review and release
Resolve deviations, verify acceptance criteria, approve the report, and define the asset’s routine-use status.
Design Qualification (DQ): Proving the Design Is Fit for Use
Design Qualification is a documented review that demonstrates the proposed design can meet the user’s requirements, intended process, quality risks, regulatory expectations, safety needs, and lifecycle support requirements. DQ should occur before the design is locked or procurement decisions become difficult to change.
What DQ should evaluate
Intended use
Product, process, batch size, operating environment, capacity, throughput, cleaning approach, and permitted materials are clearly defined.
Critical functions
Control loops, alarms, interlocks, recipes, data capture, access controls, and failure responses are specified before testing begins.
Materials and utilities
Product-contact materials, surface finishes, electrical supply, gases, water, drainage, ventilation, and environmental conditions are suitable.
Maintainability
Calibration, preventive maintenance, spare parts, cleaning access, safe intervention, and supplier support are considered in the design.
Data integrity
Users, audit trails, time controls, electronic signatures, backup, retrieval, and interfaces are addressed for computerized or hybrid systems.
Supplier evidence
Drawings, specifications, certificates, manuals, test records, and vendor quality evidence are assessed rather than accepted without review.
Typical DQ deliverables
- Approved user requirements and functional or design specifications.
- Design review minutes, decisions, open actions, and approval signatures.
- Traceability matrix linking requirements to design features and planned tests.
- Quality risk assessment identifying critical design and process aspects.
- Equipment drawings, P&IDs, layouts, material certificates, and utility requirements.
- Preliminary cleaning, calibration, maintenance, cybersecurity, backup, and data-retention strategy.
- Supplier assessment, technical agreement, and planned factory or site acceptance testing.
- Approved DQ report with unresolved risks assigned to owners and due dates.
For a deeper article in this series, see DQ and the related guidance on user requirements and design decisions.
Installation Qualification (IQ): Proving It Was Installed Correctly
Installation Qualification verifies and documents that the equipment, facility, utility, instrument, or system has been received and installed according to approved drawings, specifications, manufacturer instructions, and site requirements. IQ is not only a visual walk-through; it establishes an accurate baseline for later operation and performance tests.
IQ evidence should establish
- Correct asset name, model, serial number, tag number, location, and unique system identifier.
- All major components, product-contact parts, sensors, cables, panels, filters, and accessories are present and identified.
- Installation matches approved drawings, layouts, P&IDs, wiring diagrams, and configuration documents.
- Utilities such as power, compressed air, gases, water, drainage, exhaust, network, and environmental conditions meet requirements.
- Materials of construction, surface finish, elastomers, lubricants, and certificates are acceptable for intended use.
- Calibration status and calibration certificates are available for measuring and monitoring devices.
- Manufacturer manuals, software versions, licenses, backup media, spare parts, and maintenance instructions are controlled.
- Safety guards, emergency stops, labels, access controls, and required training or operating instructions are in place.
- Open installation deviations are assessed and do not prevent safe, controlled OQ execution.
See the companion article on IQ for a detailed installation checklist and report structure.
Operational Qualification (OQ): Challenging Functions and Limits
Operational Qualification demonstrates that the installed system operates as intended across approved operating ranges and challenge conditions. OQ should test functions that can affect product quality, patient safety, operator safety, process control, alarms, records, or system security.
Common OQ test categories
Normal operation
Start-up, shutdown, mode selection, recipe loading, parameter entry, sequence control, and routine user actions work as specified.
Operating ranges
Lower, nominal, upper, and justified worst-case settings are challenged for critical temperatures, speeds, pressures, times, flows, or capacities.
Alarms and interlocks
Limit alarms, door switches, emergency stops, access restrictions, permissives, and safe-state responses activate and recover correctly.
Power and communication
Recovery after power interruption, network loss, sensor fault, printer failure, or interrupted transaction is assessed where relevant.
Data and security
Unique users, roles, audit trails, electronic signatures, time stamps, reports, interfaces, and controlled configuration behave as approved.
Cleaning and changeover
Access, recipes, status controls, wash cycles, rinse endpoints, and changeover safeguards support the approved process.
OQ acceptance criteria
Acceptance criteria should be measurable, traceable to a requirement or risk control, and written before execution. “Works correctly” is too vague. A stronger criterion might specify an allowed range, response time, alarm state, recovery behavior, data field, or report content. Where a range or limit is not directly established by a regulation, the site should justify it using process knowledge, engineering capability, supplier information, historical performance, or risk assessment.
Testing outside routine conditions can be valuable, but it must be safe and scientifically justified. Do not create a challenge that could damage equipment, contaminate product, or create an uncontrolled GMP event.
See the companion article on OQ for functional testing, alarm challenges, and report expectations.
Performance Qualification (PQ): Proving Routine Performance
Performance Qualification provides documented evidence that a qualified asset or system performs consistently and effectively for its intended use under routine or simulated routine conditions. PQ connects the equipment to the process, approved materials, trained operators, defined environment, and actual acceptance criteria.
What makes PQ meaningful?
- Use approved procedures, trained operators, released or appropriately controlled materials, and routine support systems.
- Define the product, process, batch size, load pattern, recipe, environmental conditions, and sampling plan before execution.
- Measure critical quality and performance attributes rather than relying only on equipment display values.
- Use justified sampling and, where appropriate, challenge the most difficult or worst-case configuration.
- Trend results across runs or cycles and assess variability, drift, alarms, interventions, and unexplained differences.
- Document operator actions, line clearance, material status, equipment status, and any process interruptions.
- Evaluate deviations through the quality system before concluding that performance is acceptable.
- Define the routine monitoring, calibration, maintenance, requalification, and continued verification strategy after PQ.
See the companion article on PQ for routine-use testing, sampling logic, acceptance criteria, and continued verification.
IQ OQ PQ DQ Comparison: When Each Stage Applies
| Decision point | DQ | IQ | OQ | PQ |
|---|---|---|---|---|
| Primary focus | Design suitability | Correct installation | Functional operation | Routine performance |
| Typical timing | Before design freeze or procurement | After installation and document receipt | After IQ approval and before routine use | After successful OQ and process readiness |
| Typical conditions | Design documents and risk scenarios | As-installed condition | Normal, limit, alarm, and challenge conditions | Routine process, approved materials, trained people |
| Key question | Can this design meet the need? | Did we receive and install the right thing? | Does it work across its approved range? | Does it deliver consistent intended results? |
| Release decision | Proceed with implementation | Proceed to operation testing | Proceed to performance testing | Release for defined routine use |
How to Write a Strong Qualification Protocol
A protocol is the approved test plan. It should make execution repeatable and review objective. The protocol should be specific enough that a trained person can execute it without inventing test conditions or acceptance criteria at the time of testing.
Scope and objective
Identify the asset, system boundary, intended use, qualification stage, exclusions, and decision the protocol will support.
Responsibilities
Assign engineering, validation, production, QC, IT, maintenance, EHS, and QA responsibilities for preparation, execution, review, and approval.
Prerequisites
List approved drawings, calibration, utilities, training, cleaning, procedures, materials, software baseline, and safety checks needed before testing.
Test method
Define step sequence, instruments, settings, data to record, photographs or attachments, expected results, and handling of exceptions.
Acceptance criteria
Use objective limits, states, ranges, response times, calculations, or traceable requirements. Avoid subjective wording.
Deviation handling
Explain how an unexpected result is documented, contained, assessed, investigated, retested, and approved without overwriting the original evidence.
Minimum protocol-to-report traceability
- Each requirement or risk control maps to one or more planned tests.
- Each test has a unique identifier and a clear expected result.
- Raw observations, instrument IDs, calibration status, screenshots, printouts, and attachments are referenced.
- Any failed or repeated test remains visible with the reason, impact assessment, and approved conclusion.
- The final report summarizes execution, deviations, open actions, data review, and the justified qualification status.
Risk-Based Qualification and Critical Aspects
Risk-based qualification focuses effort where failure could affect product quality, patient safety, operator safety, regulatory compliance, or the reliability of data used for decisions. The goal is not to test everything equally; it is to make the rationale transparent and defensible.
| Risk question | Example critical aspect | Possible qualification response |
|---|---|---|
| Could the function change a critical quality attribute? | Mixing speed, sterilization temperature, fill volume, compression force | Challenge operating range, alarm limits, measurement accuracy, and process outcome. |
| Could failure create contamination or mix-up? | Airflow direction, cleaning cycle, line clearance, recipe selection | Test interlocks, status controls, cleaning access, recovery, and documented clearance. |
| Could a data failure hide a quality event? | Audit trail, electronic signature, historian, backup, user access | Test data creation, modification visibility, time sequence, access, retrieval, and restore. |
| Could an alarm be missed or incorrectly interpreted? | High-temperature alarm, low-pressure alarm, sensor failure | Challenge alarm activation, acknowledgement, escalation, safe state, and event recording. |
Link the risk assessment to your approved ALCOA controls when data are electronic or hybrid. A qualification test that passes physically but loses timestamps, audit trails, raw files, or user attribution is not a complete demonstration of fitness for use.
Example: Qualifying a Tablet Compression System
A tablet press illustrates how the four stages connect. The exact tests depend on the press design, product range, tooling, control system, and approved process requirements.
| Stage | Example activities | Evidence expected |
|---|---|---|
| DQ | Review capacity, compression-force control, tooling compatibility, dust extraction, guarding, cleaning access, recipe control, and data requirements. | URS traceability, design review, drawings, risk assessment, supplier documents, approved specifications. |
| IQ | Verify press identity, punches and dies, electrical and pneumatic connections, extraction, software version, calibration, manuals, and installation condition. | Asset list, certificates, photos or controlled attachments, calibration records, installation checklist, IQ report. |
| OQ | Challenge controls, speed, force limits, feeder operation, alarms, emergency stop, access interlocks, recipe permissions, audit trail, and recovery after interruption. | Executed functional tests, alarm results, configuration evidence, raw data, deviations, OQ report. |
| PQ | Run an approved product or justified surrogate under routine conditions; assess weight, hardness, thickness, friability, appearance, output, and process stability as applicable. | Batch or run records, IPC data, trend review, operator evidence, deviations, PQ report, routine monitoring plan. |
The example shows why DQ, IQ, OQ, and PQ are not four versions of the same checklist. DQ asks whether the press was selected and specified correctly; IQ confirms the installed asset; OQ challenges its functions; and PQ demonstrates that the press supports the intended manufacturing process.
Qualification Records, Data Integrity, and ALCOA
Qualification evidence is itself GMP data. It must be attributable, legible, contemporaneous, original, accurate, complete, consistent, enduring, and available. The record should allow a reviewer to reconstruct who performed each test, what was observed, which instrument or software version was used, and why the final conclusion was reached.
- Use controlled protocols and forms with document number, version, asset ID, and page control.
- Identify every executor and reviewer with individual credentials or compliant signatures.
- Record actual values and times at the point of activity; do not pre-fill results.
- Retain raw files, electronic records, metadata, audit trails, screenshots, printouts, and attachments required to interpret the result.
- Protect original records from deletion, overwrite, uncontrolled editing, or unapproved format conversion.
- Use controlled corrections that preserve the original entry and explain the reason.
- Verify calculations, units, instrument IDs, software versions, and acceptance decisions independently.
- Archive and retrieve the complete qualification package during its required retention period.
For broader data-integrity context, read the complete ALCOA guide. Data controls should be planned in DQ, verified in IQ/OQ, and confirmed during PQ—not added only after an audit observation.
Deviations, CAPA, and Qualification Release
A deviation during qualification does not automatically mean the asset fails. It means the approved plan encountered an unexpected condition that must be recorded and assessed. The final decision should be based on evidence, impact, root cause, corrective action, and the ability to demonstrate that the acceptance criteria remain satisfied.
Contain
Stop or control the activity when necessary, protect product and data, and preserve the original test evidence.
Assess impact
Determine whether the event affects the test, previous results, product, system state, safety, or the qualification conclusion.
Investigate cause
Use evidence-based investigation rather than assuming operator error, especially when design, configuration, supplier, or procedure factors exist.
Correct and prevent
Open CAPA when systemic action is needed, and verify the action’s effectiveness.
Retest with control
Repeat testing only through an approved rationale; never replace a failed result with a passing result or hide the first attempt.
Approve release
QA approves the qualification status only after open risks, deviations, actions, and report conclusions are adequately resolved.
An unresolved deviation may require a partial release, restricted use, additional testing, a change control, or a delayed qualification conclusion. The decision and its justification belong in the approved report.
Roles and Responsibilities
| Function | Typical responsibilities |
|---|---|
| System owner / user department | Defines intended use, process needs, users, routine monitoring, training, and acceptance of operational risks. |
| Engineering / maintenance | Provides design, installation, utilities, drawings, calibration, maintenance, supplier coordination, and technical troubleshooting. |
| Validation | Coordinates risk-based strategy, protocols, test execution, traceability, deviations, reports, and lifecycle status. |
| Production / QC / laboratory | Provides process or analytical expertise, trained operators, routine-use inputs, sampling, and performance data. |
| IT / automation / CSV | Controls infrastructure, accounts, configuration, interfaces, audit trails, backup, restore, cybersecurity, and system evidence. |
| Quality assurance | Approves plans, protocols, risk decisions, deviations, reports, change controls, and final qualification status. |
Common IQ, OQ, PQ, and DQ Mistakes
Starting with IQ too late
Purchasing or installing before requirements and risks are approved can make important design gaps expensive to correct.
Copying supplier tests
Vendor FAT or commissioning records may support qualification, but the site must assess scope, identity, execution, deviations, and intended use.
Testing only nominal settings
Nominal operation does not show how the system behaves at justified limits, alarms, interruptions, or worst-case configurations.
Using vague acceptance criteria
“Passes” or “works correctly” is difficult to review. Criteria should be measurable and linked to a requirement or risk.
Ignoring data functions
Electronic records, audit trails, signatures, interfaces, backups, and user access are part of the system when they support GMP decisions.
Confusing qualification with validation
Equipment qualification supports fitness for use; process validation, cleaning validation, analytical validation, and CSV may require additional evidence.
Final IQ OQ PQ DQ Readiness Checklist
Before approving a qualification package, the review team should be able to answer “yes” to the following questions or document a justified exception.
- Is the intended use, system boundary, product or process impact, and qualification strategy approved?
- Are requirements, design decisions, risks, and planned tests traceable from DQ through PQ?
- Are the asset identity, installed components, utilities, materials, drawings, manuals, and calibration records verified?
- Are OQ functions, operating ranges, alarms, interlocks, failure responses, and data controls tested with objective criteria?
- Does PQ use approved procedures, appropriate materials, trained personnel, representative conditions, and justified sampling?
- Are all raw data, attachments, audit trails, calculations, instrument IDs, and software versions retained and reviewable?
- Are deviations, failed tests, repeats, changes, and open actions visible, assessed, and approved?
- Is the post-qualification monitoring, calibration, maintenance, requalification, change control, and retirement plan defined?
- Has QA approved the final report and clearly stated the permitted routine-use status?
Key Takeaways
DQ prevents avoidable design gaps
Verify that the proposed design can meet intended use, quality, safety, data, and lifecycle requirements before it is locked.
IQ establishes the baseline
Confirm that the correct asset, components, utilities, documents, calibration, and configuration are installed and identified.
OQ challenges the system
Test functions, ranges, alarms, interlocks, failure responses, and critical electronic controls against measurable criteria.
PQ connects equipment to use
Demonstrate consistent performance with approved materials, trained operators, routine procedures, and representative conditions.
Evidence is the deliverable
A signed protocol is not enough. Raw data, deviations, calculations, traceability, and an approved report support the decision.
Risk determines depth
Use science and quality risk management to set scope, challenge conditions, sampling, and requalification expectations.
Conclusion
IQ, OQ, PQ, and DQ form a connected qualification framework for showing that pharmaceutical equipment, utilities, facilities, and computerized systems are fit for their intended use. DQ confirms that the design is suitable; IQ establishes that the approved design was installed correctly; OQ proves that critical functions operate across defined conditions; and PQ demonstrates reliable routine performance.
The strongest qualification programs are risk-based, traceable, and honest about unexpected results. They preserve raw evidence, connect engineering and quality decisions, and continue beyond the final report through calibration, maintenance, change control, periodic review, and continued verification. When the evidence is complete and retrievable, qualification becomes more than a compliance exercise—it becomes a practical control for product quality and patient safety.
Frequently Asked Questions
What do IQ, OQ, PQ, and DQ stand for?
DQ means Design Qualification, IQ means Installation Qualification, OQ means Operational Qualification, and PQ means Performance Qualification. Together they provide documented evidence that an asset is suitably designed, correctly installed, operationally controlled, and capable of consistent intended performance.
Which comes first, DQ or IQ?
DQ normally comes before IQ because the design should be reviewed and approved before installation. IQ then verifies that the approved equipment or system was received and installed as specified. Some projects may combine activities, but the rationale and traceability should be documented.
Can IQ and OQ be combined?
Yes, IQ and OQ may be combined when the system is simple, the scope is clear, and the combined protocol preserves installation and operational evidence. The decision should be justified by risk and approved in the validation strategy.
Is PQ the same as process validation?
No. PQ demonstrates that an equipment, utility, facility, or system performs consistently for its intended use. Process validation demonstrates that the manufacturing process can reproducibly deliver product meeting predefined quality attributes. The two activities may be linked but are not automatically interchangeable.
How many PQ runs are required?
There is no universal run count that fits every system. The number of runs or cycles should be justified using risk, process knowledge, variability, product range, equipment complexity, historical evidence, and regulatory commitments. The approved protocol should explain the rationale.
What is the difference between commissioning and qualification?
Commissioning is engineering work that confirms a system is built, installed, started, and functioning according to project requirements. Qualification is the documented GMP evidence that the system is fit for intended use. Commissioning records may support qualification after the site assesses their scope, integrity, and traceability.
What happens if an OQ test fails?
Record the failure as a deviation or exception, contain any risk, assess impact, investigate the cause, and determine whether correction, retest, change control, or CAPA is needed. The original failed result must remain visible; it should not be deleted or replaced by a passing repeat.
Does a supplier certificate replace IQ or OQ?
A supplier certificate or factory test can provide supporting evidence, but it does not automatically replace site qualification. The site must verify the supplier’s scope, asset identity, test conditions, raw evidence, deviations, and relevance to its intended use.
How does data integrity apply to qualification?
Qualification data must be attributable, legible, contemporaneous, original, accurate, complete, consistent, enduring, and available. This includes paper entries, instrument files, audit trails, electronic signatures, configuration records, calculations, screenshots, and final reports.
When is requalification required?
Requalification may be required after significant changes, relocation, major repair, software or configuration change, repeated failure, adverse trend, extended shutdown, or a periodic review conclusion. The trigger, scope, and timing should be defined by risk and the site procedure.
.webp)
