Process Validation for Medical Devices: IQ, OQ and PQ Explained

Process validation is how a medical device manufacturer proves that a process will consistently produce a product that meets its specification, when the result cannot be fully confirmed by testing the finished product alone. Sterilisation, sealing, welding, moulding, cleaning and software-driven processes are classic examples. This guide explains when validation is required, how IQ, OQ and PQ fit together, and what auditors look for.

When process validation is required

ISO 13485:2016 clause 7.5.6 requires validation of any production or service process whose output cannot be, or is not, verified by subsequent monitoring or measurement, so that deficiencies appear only after the product is in use. FDA applies the same principle: under the QMSR, which incorporates ISO 13485, process validation sits in clause 7.5.6, replacing the former 21 CFR 820.75. The Global Harmonization Task Force guidance document Process Validation Guidance (GHTF/SG3/N99-10:2004) remains the most widely used reference for the practical approach.

A simple decision test helps. Ask: can every unit be fully inspected or tested, non-destructively, to prove it meets specification? If yes, you may verify instead. If testing is destructive (a seal strength test, a sterility test) or cannot reveal the defect (a sterilisation cycle, a weld inside a closed part), you validate the process.

The validation lifecycle: IQ, OQ and PQ

Stage	Question answered	Typical content
Installation Qualification (IQ)	Is the equipment installed correctly?	Equipment identification, utilities, calibration, software versions, documentation, safety checks
Operational Qualification (OQ)	Does it work across its operating range?	Challenge of upper and lower process limits, alarms, worst-case settings, process window
Performance Qualification (PQ)	Does it consistently make conforming product under normal production conditions?	Multiple runs with production-equivalent materials, trained operators, final specification checks

Before IQ, write a validation master plan or protocol that states scope, responsibilities, acceptance criteria, sampling rationale and what happens on a failure. Approve it before executing it. A protocol written after the data is collected is one of the quickest ways to a finding.

Setting acceptance criteria and sample sizes

Acceptance criteria come from the product specification and the risk file, not from what the process happens to achieve. Higher-severity failures justify tighter criteria and larger samples. Statistical rationale should be documented: confidence and reliability levels for attribute data, or process capability indices (Cpk, Ppk) for variable data. Our guide to sampling plan generation shows how to calculate defensible sample sizes.

The number of PQ runs is not fixed by regulation. Three consecutive runs is a common convention, but the right number depends on process variability, risk and prior knowledge, and it must be justified. For processes with high risk or high variability, expect more.

Worst case and the process window

OQ should challenge the process at its edges: highest and lowest temperature, time, pressure, speed and so on, in combinations that stress the product. The knowledge from OQ defines the validated operating window. PQ then runs at nominal or near-nominal settings under realistic production conditions. If production later operates outside the validated window, revalidation or a documented rationale is needed.

Special processes worth knowing

• Sterilisation: validated under ISO 11135 (ethylene oxide), ISO 11137 (radiation) or ISO 17665 (moist heat), with bioburden, sterility assurance level and packaging considerations.
• Sterile barrier packaging and sealing: ISO 11607-1 and ISO 11607-2 cover materials, design and packaging process validation.
• Cleaning and cleanliness: residuals and particulates must be justified against biocompatibility and function.
• Software used in production or the quality system: validated on a risk basis. See our guide to computer software validation.

Maintaining the validated state

Validation is not a one-time event. Keep the process in control with calibration, preventive maintenance, process monitoring and change control. Triggers for revalidation include changes to equipment, materials, suppliers, software, process parameters, location, or a trend in nonconformances and complaints. Link process changes to the design change procedure and to CAPA when data shows drift.

Common findings and how to avoid them

• Protocol approved after execution, or acceptance criteria changed after seeing the data.
• OQ run only at nominal settings, so the process window is unproven.
• PQ run with engineers instead of the trained production operators.
• No rationale for sample sizes or number of runs.
• Outsourced processes validated by the supplier, with no review of the report by the manufacturer. You remain responsible.
• No periodic review or revalidation trigger defined.

Frequently asked questions

What is the difference between process verification and process validation?

Verification confirms that each product unit meets its specification by inspection or test. Validation establishes with documented evidence that a process will consistently produce conforming product, and is needed when verification alone cannot confirm the output.

How many PQ runs are required?

No regulation sets a fixed number. Three consecutive successful runs is common practice, but the number should be justified by risk, variability and existing process knowledge.

Can a supplier’s validation replace ours?

You can rely on a supplier’s validation only if you have reviewed it, it covers your product and specification, and your purchasing controls require them to maintain it. You remain accountable for the outcome.

Do manufacturing software and spreadsheets need validation?

Yes, when they are used in production or the quality system and affect product quality or records. The depth should be proportionate to risk.

Standards and guidance are revised from time to time. Confirm the current edition of each document you cite.

Talk to the AptSkill team

Need help building a validation protocol or training your team? Send us a short message.