Types of Validation in Pharma: IQ, OQ, PQ, Process, Cleaning, and CSV Explained

Installation Qualification (IQ)

IQ verifies that equipment, systems, or instruments are installed correctly according to the manufacturer's specifications and your own design requirements. Think of it as confirming that everything is where it should be, connected how it should be connected, and configured to the right specifications. IQ typically covers physical installation checks (is the equipment level, are utilities connected correctly, are safety features in place), software installation verification (correct version installed, correct configuration settings applied, license activated), and documentation verification (manuals received, certificates of compliance on file, calibration certificates current). IQ is usually the most straightforward qualification stage, but teams still make mistakes — the most common being treating IQ as a checkbox exercise rather then documenting the actual as-installed state. Your IQ protocol should capture serial numbers, firmware versions, and configuration settings that you can refer back to if questions arise later.

Operational Qualification (OQ)

OQ demonstrates that equipment or systems operate as intended across their specified operating range. While IQ confirms "it is installed correctly," OQ confirms "it works correctly." OQ testing typically covers functional testing (does each function work as specified), boundary testing (does the system behave correctly at its upper and lower operating limits), alarm testing (do alarms and interlocks trigger at the correct setpoints), and negative testing (does the system reject invalid inputs or conditions appropriately). The operating range is the critical concept — you are not just testing that the system works at one point, you are testing that it works reliably across the full range of conditions it will encounter in production. For a temperature-controlled chamber, that means testing at the minimum, maximum, and nominal temperature settings. For a software system, that means testing with minimum and maximum data loads, concurrent users, and boundary input values.

Performance Qualification (PQ)

PQ verifies that equipment or systems perform consistently under actual or simulated production conditions. While OQ tests functional capability in a controlled setting, PQ tests real-world performance with actual process materials, actual operators, and actual production conditions. PQ is where theory meets reality. The system might pass OQ perfectly but fail PQ because the actual production environment introduces variables that were not present during OQ — humidity variations, vibration from adjacent equipment, operator handling patterns, or material lot-to-lot variability. PQ protocols typically require multiple consecutive successful runs (often three, though the number should be justified by risk assessment rather than arbitrary convention) to demonstrate consistent performance. The acceptance criteria should be derived from your process requirements and product specifications, not from the equipment manufacturer's capabilities.

Process Validation (PV)

Process validation is the collection of evidence that a manufacturing process consistently produces a product meeting its quality attributes and specifications. This is arguably the most important type of validation in pharma because it directly relates to patient safety — if your process is not validated, you cannot be confident that every batch you release meets its specifications.

The FDA's 2011 Process Validation Guidance introduced a three-stage lifecycle approach: Stage 1 (Process Design) involves understanding the process and defining critical process parameters; Stage 2 (Process Qualification) involves demonstrating the process performs as expected at commercial scale; Stage 3 (Continued Process Verification) involves ongoing monitoring to ensure the process remains in a state of control. The shift from the old "three consecutive batches and you're done" approach to a lifecycle model was significant because it acknowledged that validation is not a one-time event — it is an ongoing commitment to understanding and controlling your process. GxP Copilot supports the documentation and evidence management across all three stages, with Live RTM maintaining the relationship between process parameters, qualification protocols, and ongoing monitoring data.

Cleaning Validation

Cleaning validation demonstrates that your cleaning procedures effectively remove product residues, cleaning agents, and microbial contamination to acceptable levels. This is critical for multi-product facilities where the same equipment is used to manufacture different products — inadequate cleaning can lead to cross-contamination, which is a serious patient safety issue and a frequent FDA observation. Cleaning validation involves establishing acceptance criteria (typically based on toxicological data or the 10 ppm / 0.1% carryover limits), developing and validating analytical methods for detecting residues, running the cleaning process on equipment that has been deliberately soiled with worst-case product residues, and sampling surfaces and rinse water to demonstrate that residue levels are below acceptance criteria. The "worst-case" concept is important: you should validate cleaning using the product that is hardest to clean, the equipment configuration that is hardest to reach, and the longest hold time between cleaning and next use.

Computer System Validation (CSV) and Computer Software Assurance (CSA)

CSV — and its modern evolution, CSA — validates that computerised systems used in GxP activities are fit for their intended use and comply with regulatory requirements. This covers everything from LIMS and eQMS to MES, ERP, ELN, and any other software system that generates, processes, stores, or reports GxP data.

Traditional CSV follows a V-model approach: user requirements, functional specifications, design specifications, then IQ/OQ/PQ testing that maps back to each specification level. CSA services — formalised by the FDA in 2022 — takes a risk-based approach where the depth of testing is proportional to the risk each function poses to patient safety and product quality. Under CSA, low-risk functions may be verified through vendor documentation alone, while high-risk functions receive full scripted testing with documented evidence. GxP Copilot is built CSA-first: the AI Risk Assessment scores every requirement individually, and Test case generation calibrates test depth automatically based on that risk score. The result is validation that is more targeted, more efficient, and — because it focuses effort where risk is highest — actually more effective at catching the problems that matter.

How these validation types connect

These six types of validation are not independent activities — they connect and overlap in important ways. Your process validation depends on your equipment being qualified (IQ/OQ/PQ) and your computerised systems being validated (CSV/CSA). Your cleaning validation depends on your equipment qualification. Your CSV/CSA validation of a LIMS or MES needs to account for how those systems support your process validation and cleaning validation activities.

The practical implication: your validation master plan should map these connections explicitly, showing which validations depend on which others and ensuring that prerequisite validations are complete before dependent validations begin. Live RTM in GxP Copilot makes these cross-validation dependencies visible and traceable, so your team can see the full picture rather then working on each validation in isolation.