Why Does Our IQ Protocol Keep Failing FDA Audits?

If the same installation qualification keeps coming back with findings, it is tempting to blame the equipment, the vendor package, or the inspector having a bad day. It is almost never any of those. An IQ protocol fails an audit because of what is written in it, or what is missing from it, and the failure pattern repeats because the underlying template repeats.

This post walks through the recurring reasons an IQ protocol draws a 483 observation or a warning-letter citation, in the order we see them most often. For each one we describe what the finding looks like, why it happens, and the specific change that closes it. None of this requires a new quality system. It requires writing the protocol the way an inspector reads it.

If you would rather see the fixes applied to a live document than read about them, you can generate a fully structured IQ protocol from your equipment context and check it against this list yourself. Start at /signup or read on first.

What an IQ is actually supposed to prove

Installation qualification is documented evidence that the equipment, as installed, matches its approved design and the manufacturer's specifications, and that the supporting utilities and environment are in place before you power it up for real work. That is the whole job. IQ is not where you prove the equipment performs. That is operational and performance qualification. IQ proves the thing was received, installed, connected, and documented correctly.

Most IQ findings trace back to a protocol that either tries to do more than that, or does less. The document either wanders into performance testing it cannot defend, or it skips the boring verification steps that an inspector will absolutely ask to see. We cover the boundary between the three stages in detail in IQ vs OQ vs PQ and what actually goes in each one, and when IQ alone is enough in how to determine if equipment needs IQ only or full IQ/OQ/PQ.

Root cause 1: acceptance criteria that cannot be judged pass or fail

This is the single most common reason an IQ protocol gets flagged. A test step reads "verify the equipment is installed correctly" with an acceptance criterion of "installed correctly." That is not a criterion. It is a restatement of the step, and it gives the executing technician nothing to measure against and the inspector nothing to check.

Bad looks like: "Verify utilities are connected. Acceptance: utilities connected."

Good looks like: "Verify the compressed air supply is connected to inlet port A at 6.0 to 7.0 bar, confirmed against gauge PI-101 and recorded. Acceptance: measured inlet pressure is within 6.0 to 7.0 bar as specified in the equipment installation manual, section 4.2."

Every acceptance criterion in an IQ should be measurable, tied to a named specification source, and have a pass or fail boundary that two different technicians would judge the same way. We wrote a full guide on this in how to write acceptance criteria that won't get flagged in an audit.

Root cause 2: no traceability from specification to test

An inspector's hardest question is not "did you test it" but "show me where this requirement was verified." If your IQ lists installation requirements in one place and test steps in another, with nothing connecting them, you cannot answer that question quickly, and a slow answer during an inspection reads as a gap.

The fix is a traceability matrix that maps each installation requirement, drawn from the URS, the design specification, and the vendor installation manual, to the specific IQ test step that verifies it, and to the recorded result. When every requirement has a test and every test has a requirement, there are no orphan tests and no uncovered requirements for the inspector to find. Build it before execution, not after. Our full method is in the traceability matrix in validation.

Root cause 3: undocumented deviations and blank fields

An inspector will read the executed protocol, not just the blank template. When they find a test step with a blank result field, a value that is out of range with no deviation recorded, or a correction with no initial, date, or reason, that is a data integrity finding. It does not matter that the equipment was fine. The record does not show that it was fine.

The expectation, grounded in ALCOA+ data integrity principles, is that every field is completed, every out-of-specification result triggers a documented deviation with a disposition, and every correction is attributable, dated, and explained. A single-line-through correction with initials and a reason is defensible. An overwrite is not. Where electronic records and signatures are used, 21 CFR Part 11 governs how those records and corrections are captured and controlled.

Root cause 4: the approval chain is incomplete or out of order

A validation protocol has to be approved before it is executed. That sequence matters. If the approval signatures on your IQ are dated after the execution dates, or if a required approver, typically quality assurance, is missing, an inspector reads it as an uncontrolled execution. The work may have been perfect. The document says it was done without authorization.

Good looks like: a clearly defined approval block naming the roles required to approve the protocol before execution, with signatures and dates that precede the first execution date, and a separate post-execution review and approval of the completed protocol and its results. Quality assurance owns the final review. This is one of the details inspectors check first, as we describe in what auditors actually look for in validation documentation.

Root cause 5: no risk basis for what was and was not verified

Modern qualification is risk-based. An IQ that verifies every attribute at the same depth with no documented rationale, or one that skips an important installation check with no rationale, both invite the same question: why this and not that? Without a risk basis, you cannot answer it.

You do not need a heavy analysis for IQ. You need a defensible statement of which installation attributes are critical to the equipment's intended use, informed by your risk assessment, and a test plan that clearly covers those. The GHTF process validation guidance, GHTF/SG3/N99-10:2004, and current FDA process validation expectations both frame qualification as scoped to risk. When the scope is justified, the inspector has nothing to push on.

Root cause 6: the protocol does not match the equipment in front of them

Copy-paste is the quiet killer. A protocol cloned from the last piece of equipment, with the model number changed but the test steps left generic, will contain steps that do not apply and miss steps that do. An inspector who has read the equipment manual will spot a test that references a component this unit does not have, and now they are wondering what else in the document is boilerplate.

Every IQ should be specific to the equipment as installed: its actual utilities, its actual components, its actual installation manual references, its actual serial and model numbers. A protocol generated fresh from the real equipment context avoids this by construction, because there is no previous document to inherit stale steps from.

Root cause 7: environmental and utility verification treated as an afterthought

IQ is where you confirm the room, the utilities, and the supporting infrastructure are ready. Findings cluster here because teams focus on the machine and treat the environment as assumed. Missing verification of HVAC conditions, grounding, calibrated supporting instruments, or documented as-built drawings shows up as a gap because the inspector knows the machine cannot be qualified in a vacuum.

The fix is a dedicated section that verifies each supporting utility and environmental condition against its specification, confirms that supporting measurement instruments are calibrated and in date, and captures the as-built and as-installed documentation the manufacturer requires.

How to break the repeat cycle

The reason these findings repeat is that they live in the template, so every protocol built from that template inherits them. Fixing one executed protocol does not fix the next one. You have to fix the pattern.

There are three durable ways to do that. Rewrite your IQ template so acceptance criteria, traceability, deviation handling, and the approval block are structurally correct before anyone fills it in. Have a qualified engineer review each protocol against a fixed checklist derived from the seven causes above before it goes for approval. Or generate the protocol from structured equipment inputs so the structure is right every time and your engineer spends review time on judgment, not formatting.

Valiqa exists for that third path. You enter the equipment context, and you get a structured IQ protocol with measurable acceptance criteria, a built-in traceability matrix, a defensible approval block, and a risk-informed test plan, as a draft your qualified engineer reviews and approves inside your own quality system. It does not sign your protocol and it does not replace your engineer. It makes the first draft structurally audit-ready so the recurring findings never get authored in the first place. You can see whether it fits your team in a few minutes at /signup, review transparent pricing at /pricing, or start from your equipment type with the protocol selector.

If your bigger question is which category of tool your team should even be shopping in, take the honest self-scoring at /evaluate. Sometimes the answer is a template and a checklist, and we will tell you so.