What Is a CQV Master Plan?

Most validation programmes do not fail at execution. They fail because nobody wrote down, in advance, what the programme was supposed to prove — and by the time that becomes obvious, two hundred protocols have been written against assumptions nobody agreed to.

The CQV Master Plan is the document that prevents this. It is the apex of the validation document hierarchy, and everything beneath it — System Level Impact Assessments, Quality Risk Assessments, User Requirement Specifications, FAT and SAT protocols, IQ, OQ, PQ, the Requirements Traceability Matrix — inherits its logic.

What belongs in a CQV Master Plan

A CQVMP that an inspector can follow, and that a project team can actually work from, covers nine things.

1. Scope and system boundaries

Which systems, which buildings, which phases. More importantly: where each system stops. Boundary disputes between, say, purified water generation and the distribution loop, or between a filling line and the isolator around it, are the single most common cause of qualification gaps — two teams each assuming the other owned the interface.

Draw the boundaries on a drawing, reference the drawing number, and list what is explicitly out of scope.

2. Organisation and responsibilities

Who writes, who reviews, who executes, who approves, and who has the authority to accept a deviation. Under a risk-based approach this matters more than it used to, because subject matter experts take on decisions that used to sit with the quality unit by default.

3. The risk-assessment approach

This is the heart of the document. It should state which methodology is used, what the impact categories are, how criticality is determined, and — critically — how the output of the risk assessment translates into qualification depth. A risk assessment that classifies systems but does not change what happens next is decoration.

4. The document hierarchy

A map of every document type in the programme, what each one does, and how they trace to each other. This is what makes the Requirements Traceability Matrix constructible rather than archaeological.

5. The leveraging strategy

If commissioning evidence will be used to support qualification — and under ASTM E2500 and the ISPE Baseline Guide Volume 5 it usually should be — the CQVMP is where that is agreed, with the conditions attached: calibrated instruments, trained executors, document control, quality unit approval in advance. Leveraging decided retrospectively is not leveraging; it is a gap with a justification bolted on.

6. Acceptance criteria philosophy

Not the criteria themselves — those live in the protocols — but the rules for setting them. Where do they come from? URS, vendor specification, regulatory limit, process requirement? What happens when a criterion cannot be met as written?

7. Deviation and discrepancy handling

Classification, who can close what, and the escalation path to the site QMS. A CQVMP that does not connect to the site’s deviation procedure creates a parallel quality system, which inspectors notice.

8. Change control interface

Design changes during execution are certain. The plan should say how a change is assessed for validation impact and who decides whether re-execution is needed.

9. Release criteria

What must be true, and documented, before a system can be used for GMP manufacturing. This is the question the whole programme exists to answer, and it is astonishing how often it is left implicit.

Where it sits

CQV Master Plan (CQVMP)
 ├── System Level Impact Assessment (SLIA)
 ├── Quality Risk Assessment (QRA)
 ├── User Requirement Specification (URS)
 │    └── Design Qualification (DQ)
 ├── FAT / SAT protocols
 ├── IQ / OQ / PQ protocols and reports
 ├── Requirements Traceability Matrix (RTM)
 └── Validation Summary Report → system release

Each layer should be derivable from the one above it. If you cannot trace an OQ test back through the RTM to a requirement in the URS, and from there to a criticality decision in the risk assessment, and from there to the approach set out in the CQVMP, then you have a test without a reason — and an inspector will ask why you ran it, or why you did not run something else.

Five mistakes that sink a CQVMP

Writing it after protocols have started. The plan then documents what happened rather than governing what should. Boundaries get drawn around completed work.

Leaving system boundaries undefined. Interfaces are where qualification gaps live. If the plan does not say who owns the interface, nobody does.

Agreeing the risk approach with engineering but not the quality unit. The quality unit will eventually have to defend the decisions the approach produced. Approval after the fact is not approval.

No leveraging strategy. Either you repeat commissioning as qualification — expensive, slow, and no more compliant — or you leverage without a documented basis, which is worse.

Deferring acceptance criteria entirely to protocols. Without a stated philosophy, fifteen protocol authors invent fifteen different standards, and the inconsistency becomes visible only during review.

When you need one

Any project with more than a handful of systems, any greenfield facility, any technology transfer, and any programme where more than one organisation is executing. A single equipment qualification at an operating site with a mature VMP may not need its own master plan — but it does need to sit under one.

The test is simple: if a new engineer joined the project tomorrow, could they determine from the documentation what is being qualified, why, to what depth, and what “done” means? If not, the plan is missing, whatever the document is called.