Ask most project teams when equipment validation begins, and they’ll say IQ, once the unit is on-site and ready to install, because that’s when protocols are executed, data is recorded, and sign-offs start accumulating. It’s a reasonable answer; however, it’s also the point at which some teams discover the real work went wrong long before IQ began.

By the time IQ starts, the user requirement specification has been written, the vendor has been chosen, and the equipment has been built to match. Whatever gaps exist in that specification (or mismatches between what the equipment does and what the process actually needs) are already sitting inside the unit on the loading dock. IQ doesn’t create those gaps. It’s just the first place they get tested against.

Requirement Specifications and Qualification Answer Different Questions

What a Clean IQ Confirms, and What It Doesn’t

A clean IQ confirms one specific objective: the equipment that arrived matches the equipment that was ordered, installed the way the manufacturer specifies. It doesn’t confirm that what was ordered was ever going to meet the process requirements downstream.

IQ, OQ, and PQ each test a system against a defined specification, but none of the three protocols ask whether the specification was the right one to write. That question sits upstream of the qualification lifecycle, in the design qualification work that happened before any protocol existed to test against.

Why the Specification Has to Be Built Around the Process, Not the Vendor’s Catalog

ASTM E2500 frames qualification as verification that equipment meets process requirements defined up front, based on the science of the product and process rather than on whatever configuration a vendor typically supplies.

The FDA’s 2011 process validation guidance takes a similar view, placing equipment qualification and facility design within the first stage of process validation, not as a phase that starts once validation is already underway.

A specification built by adapting a vendor’s standard offering, instead of starting from what the process actually requires, can pass qualification protocol in sequence without ever answering whether the equipment was the right choice for this process specifically.

Where the Gap Between Selection and Qualification Shows Up

At Equipment Selection

When choosing between comparable units, teams often default to the shorter lead time or the lower quote, on the assumption that anything in the right equipment category will clear qualification the same way.

It won’t necessarily. Two units in the same category can differ in control strategy, operating range, or how their standard configuration handles a specific product or process. A unit chosen on availability instead of fit doesn’t fail at selection. It fails in OQ or PQ, once someone is testing it against criteria it was never built to meet.

During OQ and PQ

When an OQ repeatedly fails a criterion or a PQ can’t consistently meet a performance target, the problem is often treated as an execution issue: rerun the test, adjust the protocol, or extend the timeline. Sometimes that’s the right call, but other times the protocol was not the issue; the equipment was never suited to the requirement in the first place.

That’s a specification problem surfacing three project phases after the decision that caused it, at a point where the fix is a vendor conversation or a re-scope instead of a document revision.READ MORE : What Is Pharma 4.0? What Pharma Manufacturers Need to Know

What Validating Earlier Actually Requires

Starting validation at the requirement stage means building verifiable reasoning behind three things: what the process needs the equipment to do, whether the equipment under consideration can do it, and what happens to the qualification plan if it can’t. All three have to be worked out before a purchase order goes out, not discovered during OQ.

In practice, that includes:

Developing the URS with qualification in mind. Involve the experts who will execute OQ and PQ so that operating ranges and performance criteria reflect what those protocols will actually need to test, rather than what procurement assumes is standard.
Running a risk assessment before equipment is purchased, so a control strategy gap surfaces while it’s still a specification change instead of after the unit is already on-site
Documenting the rationale behind requirement decisions in a form that can be reviewed on its own, separate from the qualification protocols that will eventually test against it

Final Thoughts

A program that starts validation at the requirement stage tends to move through IQ, OQ, and PQ without the pause that shows up when a criterion turns out to be untestable or a unit turns out to be the wrong fit. The protocols themselves don’t look any different. What’s different is how often someone has to stop mid-execution and ask whether the problem is the test or the equipment.

If your team’s validation planning still starts the clock at IQ, it’s worth looking at who was in the room when the requirement specification was written, and the equipment was chosen, and what reasoning is on file behind those decisions. That’s the point where a program either sets up a clean qualification phase or unknowingly builds in the gaps that surface later.

Performance Validation works with pharma and medical device manufacturers on the full CQV lifecycle, including the requirement and selection decisions that determine how the rest of it goes. Our CQV Pharma Services page covers that lifecycle end to end, and our earlier piece on commissioning and qualification breaks down where qualification fits against validation and where the ASTM E2500 and ISPE Baseline Guide approaches diverge.

Working through a specification or equipment decision before your next validation project kicks off? Contact Performance Validation to talk through it before it becomes a qualification problem.

When Should Equipment Validation Start? Earlier Than Most Pharma Programs Plan For