Installation Qualification (IQ) Protocol: Structure, Evidence, and Deviation Handling

Most CASRAI pages that touch Installation Qualification treat it as one row in a bigger table — a line in a computer-system validation guide, or a stage inside a facility-qualification checklist. None of them walk through what an IQ protocol document itself actually has to contain, section by section, or how a real deviation gets classified once execution finds something that does not match the spec. This guide is that document-level view: what an IQ protocol proves, what has to be true before you execute it, what “as-built” verification actually checks, why software/firmware version capture belongs in IQ rather than OQ, and the risk-based logic behind whether a deviation gets a documented note or forces you to correct the installation and re-run the test.

What an IQ Protocol Has to Prove

Installation Qualification is the first of the three (sometimes four, with an optional Design Qualification stage first) qualification stages applied to regulated equipment, instruments, and facility systems — Installation, Operational, and Performance Qualification (IQ/OQ/PQ). See CASRAI’s IQ/OQ/PQ dictionary entry for how the three stages relate. IQ’s specific job is narrower than people often assume: it does not test whether the equipment works correctly under load (that is OQ) or whether it performs consistently under real conditions of use (that is PQ). IQ proves exactly one thing — that what was actually installed matches what was specified, ordered, and approved, in an environment that meets the conditions the equipment needs to operate in. Two widely cited frameworks describe a risk-based approach to this: ASTM E2500, the ASTM International guide for specification, design, and verification of pharmaceutical and biopharmaceutical manufacturing systems and equipment, and ISPE’s Baseline Guide on Commissioning and Qualification, both of which scope the depth of IQ testing to the actual risk the system poses to product quality, patient safety, or data integrity rather than applying uniform rigor to every component regardless of criticality.

Prerequisites Before IQ Execution Starts

An IQ protocol is not something you write as you go. Before execution begins, four things need to already be in place:

• An approved specification to test against — a User Requirements Specification (URS), purchase order, or design specification the installation can be objectively checked against. For custom or high-risk equipment, this is usually preceded by a Design Qualification (DQ) stage that formally confirms the design itself meets the URS before anything is built or purchased.
• An approved protocol — the IQ protocol document itself, with its test steps, acceptance criteria, and forms, reviewed and signed off by quality assurance before execution starts. Testing against an unapproved protocol is a common audit finding in its own right.
• Calibrated verification tools — any instrument used to verify the installation (a multimeter, a thermometer, a pressure gauge) has to carry current calibration itself, or the verification it produces is not defensible evidence.
• Trained execution personnel — the people signing test steps need documented training on the protocol and, where relevant, on the equipment itself.

As-Built Verification

This is the core of IQ, and the part a generic checklist tends to compress into a single line item. As-built verification means documenting what was actually installed, not what was ordered, and comparing the two directly:

• Component identification — model numbers, serial numbers, and part numbers of the installed unit and any sub-components, checked against the purchase order and specification.
• Physical installation — for facility-adjacent equipment, this extends to drawings: piping and instrumentation diagrams (P&IDs), wiring schedules, and as-built architectural drawings, verified against what is physically present, not just against what the original design called for. Design changes made during installation are common and have to be captured, not silently absorbed.
• Component-level calibration status — where the equipment itself contains measuring instruments (a built-in thermocouple, a pressure transducer), those components’ own calibration certificates are collected as IQ evidence, distinct from the calibration of the external tools used to verify the installation.

The output of this section is a documented, traceable answer to “is this the thing we specified, installed the way we specified it?” — not an assumption based on the vendor’s delivery paperwork.

Utilities and Environment Verification

IQ also confirms that the environment the equipment sits in meets its specified requirements: electrical supply (voltage, phase, amperage), water quality and pressure, compressed gas supply, and HVAC conditions where the equipment’s function depends on them (temperature, humidity, or, for a controlled space, cleanroom particle classification under facility qualification’s broader remit). This is a static, at-rest check — confirming the utility is present, connected, and within the specified range at the point of installation — not a dynamic performance test. Dynamic behavior under actual operating load is OQ’s job, not IQ’s; keeping that boundary explicit in the protocol avoids the common drift where IQ testers start running functional checks that belong in the next stage.

Software and Firmware Version Capture

For any computerized or firmware-controlled equipment — which by now is nearly all regulated lab and manufacturing equipment — IQ is also where the software and firmware baseline gets captured, not OQ. The protocol records the exact version number of every software component and firmware build present at installation, along with the configuration settings applied (user roles, security settings, interface parameters). This baseline matters beyond the qualification event itself: once it is documented, any future version change becomes a visible, controlled change-control event rather than invisible drift, which is exactly the audit-trail and configuration-control expectation underneath 21 CFR Part 11 and GAMP 5’s risk-based computer system validation approach (see CASRAI’s Computer System Validation guide for the fuller GAMP 5/CSV lifecycle, and the 21 CFR Part 11 dictionary entry for the electronic-records requirements this baseline supports).

The Documentation Package

A complete IQ protocol assembles, at minimum: the approved protocol with executed test steps and initials/signatures for each; component identification records; calibration certificates for both the verification tools and any embedded instrumentation; the vendor’s installation or Site Acceptance Testing (SAT) report, if one exists, referenced as supporting evidence rather than substituted for independent verification; training records for the personnel who executed it; and any deviation records raised during execution, with their resolution. All of this rolls up into a single signed IQ report or summary, which is the artifact QA reviews before authorizing OQ to begin.

Deviation Handling: Re-Execution vs. a Documented Note

This is the part most IQ guidance skips past, and it is where a risk-based, ASTM E2500-style approach actually earns its keep. Not every mismatch between what was specified and what was found is the same kind of problem, and treating them identically — either accepting everything with a shrug, or re-executing every failed step regardless of severity — is itself a quality-system weakness an auditor will flag. The distinction usually comes down to whether the deviation affects fitness for use:

• Deviations that require correction and re-execution of the affected test step are ones that touch a function the equipment actually needs: a utility outside specified tolerance, a component substituted for one that changes performance characteristics, a software version that does not match the approved baseline, or a wiring/piping discrepancy that could affect a safety-critical or data-integrity-relevant function. These have to be corrected first, then the specific test step re-executed and re-signed — not overwritten in place.
• Deviations that can be closed with a documented note or justification are administrative or cosmetic: a label using an old part-number format that is still traceable, a drawing revision number that lags the physical installation by a documented, approved engineering change, a minor discrepancy in paperwork sequencing that does not affect what was actually verified. These are logged, reviewed, and formally accepted by QA with a written rationale — not silently ignored, and not treated as equivalent to a functional failure.

The determining question a protocol reviewer should be able to answer for any deviation is: does this affect whether the equipment, as installed, still meets its specification in a way that matters to product quality, data integrity, or safety? If yes, it is a re-execution. If no, but it is still a real discrepancy from what the protocol expected, it is a documented, QA-reviewed note. Neither answer is available if the protocol does not force the classification question to be asked explicitly for every deviation raised — which is why a well-written IQ protocol template includes a deviation classification field, not just a pass/fail checkbox.

Sign-off and What Happens Next

IQ closes with QA reviewing the complete package — executed protocol, evidence, and any deviation resolutions — and formally approving the IQ report. That approval is the gate: OQ testing should not begin against equipment whose installation has not been formally accepted, because any subsequent operational test result is only meaningful if the thing being tested is confirmed to be what it was supposed to be.

How This Differs From Facility Qualification and Computer System Validation

Two related CASRAI guides cover adjacent ground and are worth distinguishing explicitly, since the terminology overlaps. Facility qualification applies the same DQ/IQ/OQ/PQ logic to a room, building, or utility system as a whole — HVAC, water systems, cleanrooms — rather than to a single piece of equipment; the IQ protocol structure described here is the same underlying logic, scoped down to one instrument or system. The Computer System Validation guide covers the GAMP 5 risk-categorization and software-lifecycle side of IQ/OQ/PQ for computerized systems specifically — useful alongside this guide when the equipment being installed is itself a software system (a LIMS, an ELN) rather than a piece of physical instrumentation with embedded firmware. Where an organization is qualifying many systems at once, the Validation Master Plan guide covers the governing document that sits above individual IQ/OQ/PQ protocols and defines how they relate to each other.

Frequently Asked Questions

Does every deviation found during IQ have to be resolved before the protocol can be closed?

Yes — every deviation needs a documented disposition, but disposition does not always mean re-execution. A deviation that does not affect fitness for use can be closed with a QA-reviewed written justification; what cannot happen is a deviation being left open, undocumented, or silently corrected without a record.

Who is qualified to execute an IQ protocol?

Anyone with documented training on both the protocol itself and, where relevant, the equipment being qualified. Vendor field-service engineers commonly assist with physical installation, but independent verification against the approved protocol is typically expected to involve the owning organization’s own trained personnel or a qualified third party, not the installing vendor alone signing off on its own work.

Can a vendor’s installation report substitute for an IQ protocol?

Not on its own. A vendor Site Acceptance Testing or installation report is commonly referenced as supporting evidence within the IQ package, but it does not replace the organization’s own approved protocol, independent as-built verification, and QA sign-off — the vendor is not positioned to make the risk-based deviation classification calls the regulated user is accountable for.

Does IQ need to be repeated if the equipment is moved or reconfigured later?

Generally yes, in some form. A physical relocation, a utility change, or a firmware/software update to the captured baseline is a change-control event, and the qualification plan (frequently governed by the site’s Validation Master Plan) should define what level of re-qualification — full IQ, a partial/delta IQ, or just updated documentation — the specific change triggers.