A Validation Master Plan is a site-level document describing the entire validation strategy, scope, and schedule across all systems, equipment, and processes at a facility — it covers the complete programme. A Validation Plan is project-specific, written for a single system or validation activity, detailing that system's scope, approach, responsibilities, acceptance criteria, and timeline. Both are required: the VMP provides strategic context, while the VP provides operational direction for the individual project.
A Validation Plan or equivalent scoping document is expected for every GxP validation project — its depth and formality should scale with the system's risk and complexity rather than follow a single template. A simple Category 3 off-the-shelf application may have a concise combined VP and test summary, while a complex Category 5 custom ERP integration warrants a detailed standalone VP with explicit risk-based rationale. EU GMP Annex 15 requires that qualification and validation activities be planned and documented before work begins.
A regulatory-ready Validation Plan typically includes: system scope and brief description, GAMP 5 software category and GxP impact classification, reference to the relevant URS and risk assessment, validation approach and V-model phase coverage, list of planned deliverables with document IDs, roles and responsibilities, acceptance criteria for system release, deviations and discrepancy handling process, and schedule. The plan does not need to be long — it must be complete enough that a stranger could understand what is being validated, why, and how.
Yes. The Validation Plan must be reviewed and formally approved — with electronic or wet signatures — before any IQ, OQ, or PQ protocol execution starts. Testing executed before plan approval is not considered planned, controlled validation; it is ad hoc testing, and its results cannot be included in a compliant validation package. Inspectors routinely check document approval dates against protocol execution dates to confirm this sequence was followed.
The VMP scope should define what is included — all GxP-regulated systems, equipment, utilities, and processes at the facility — and explicitly state what is excluded, with documented rationale for each exclusion. It should reference the GxP system inventory that populates the VMP's system list, define how new systems are added through the validation lifecycle process, and clarify which types of validation activities are governed by the VMP versus by separate sub-plans such as a cleaning validation programme.
The VMP is called a living document because the site's validation landscape changes continuously — systems are added, retired, upgraded, and moved between risk classifications. At minimum, the VMP should be reviewed and updated annually as part of the site's quality management review cycle, and immediately whenever a material change occurs such as a significant facility expansion, a major system implementation, or a change in site regulatory scope. An outdated VMP that does not reflect current site operations is a direct inspection finding.
A Validation Plan defines the overall approach, scope, and structure of the validation project — it is a management and strategy document. A test protocol (IQ, OQ, or PQ) is an execution document specifying the exact steps, expected results, and acceptance criteria for individual test cases. The Validation Plan tells you what will be validated and how; the test protocol tells testers what to do step by step. Both are required and serve distinct roles in the validation documentation hierarchy.
EU GMP Annex 15 explicitly requires a Validation Master Plan, stating that all qualification and validation work should be planned, described in a VMP, and approved before execution. WHO guidelines similarly require a VMP. FDA regulations do not explicitly name the VMP but require documented validation programmes under 21 CFR Parts 211 and 820 — in practice, FDA inspectors expect to see a site-level document equivalent to a VMP and often request it first when beginning a validation-focused inspection.
The Validation Master Plan should be approved by the site's Head of Quality and senior department heads from manufacturing, engineering, and IT — since the VMP commits organisational resources and sets the compliance posture for the whole site. A project-level Validation Plan should be approved by the system owner, the validation lead, and Quality Assurance. QA approval is non-negotiable: it confirms that the planned approach is compliant and appropriate before any work begins.
The Validation Plan should link directly to the system's functional risk assessment — documenting which functions are high, medium, or low risk and how that classification drives the planned test coverage. High-risk functions must be explicitly targeted with exhaustive testing, while low-risk functions should show a documented rationale for reduced testing rather than a silent omission. The VMP at site level should show the risk-based prioritisation sequence for the overall validation schedule, ensuring highest-risk systems are validated first.
The Validation Plan should name or describe: the system owner (accountable for business requirements and operational acceptance), the validation lead or author (responsible for documentation), the tester (executing protocols), the QA reviewer (confirming compliance at each lifecycle stage), and IT or technical support (responsible for configuration and environment setup). Vague responsibility assignments — "the validation team" without named functions — are a common drafting gap that inspectors flag during document review.
Any function, module, interface, or data type explicitly excluded from the validation scope must be listed with a documented, risk-based justification — for example, an excluded reporting module may be justified by classifying it as non-GxP-impacting with reference to the functional risk assessment score. Unjustified exclusions are treated by inspectors as evidence that untested components may be operating in a GxP context without demonstrated assurance. The exclusion list is as important as the scope list.
Scope changes after a Validation Plan is approved must go through formal change control — the plan is amended, re-reviewed, and re-approved before the changed scope is executed. Running tests against a broader or narrower scope than the approved plan defines, without a documented change, creates a disconnect between planned and actual validation that inspectors will find during document review. Many validation platforms manage this by linking the VP version history directly to the change control record that triggered each revision.
No. The Validation Plan must state the criteria that must be met for the system to be formally released for GxP use — such as all IQ/OQ/PQ test cases executed with a pass result or documented deviation resolution, RTM confirmed complete, all critical and major deviations closed, and QA sign-off on the Validation Summary Report. Leaving release criteria undefined means there is no agreed standard against which release can be formally justified, making any subsequent release decision unverifiable.
Yes. A retrospective validation — performed for a system already in operation that was never properly validated — still requires a plan before work begins. The plan for retrospective validation will differ in approach: rather than pre-purchase design qualification, the plan describes how existing configuration, test evidence, and operating history will be reviewed and supplemented with additional testing to demonstrate the system is fit for its current GxP use. The absence of any plan, even retrospective, is a compliance gap rather than a pragmatic shortcut.
The VMP is the strategic document that tells an inspector what a site believes requires validation, what approach was used, and whether the organisation has thought comprehensively about its GxP risk exposure. If a system appears during inspection that is not in the VMP or system inventory, it suggests either that the VMP is outdated or that an unvalidated system is operating in a GxP context — both are serious findings. A complete, current VMP signals a mature, systematic validation programme before any individual system document is reviewed.
CSA shifts the emphasis of a Validation Plan from describing volumes of documentation toward articulating the risk-based testing strategy — explicitly justifying why certain functions will be tested with scripted protocols, why others will use unscripted or exploratory testing, and why some will rely on vendor evidence. Plans written under CSA should be shorter and more decision-focused: they document thinking and rationale rather than promising documentation outputs, reducing the disconnect between planning documents and actual testing activity.
Yes. The Validation Plan should reference whether a supplier audit or assessment is planned, its scope, and how the results will influence the on-site validation approach — since a vendor with a mature, assessed quality system can provide evidence that reduces the amount of on-site testing required. Omitting supplier assessment from the plan implies it was not considered, which is inconsistent with GAMP 5's requirement to assess supplier quality as a foundational input to validation scope decisions.
The core structure is similar — scope, approach, responsibilities, schedule, acceptance criteria — but the content emphasis differs. A computer system Validation Plan emphasises software categorisation, functional risk assessment, testing phases (IQ/OQ/PQ or equivalent), and data integrity controls. A process validation plan emphasises critical quality attributes, critical process parameters, control strategy, and stage-based execution across process design, process qualification, and continued process verification as defined in FDA's 2011 process validation guidance.
Word-based VMPs and Validation Plans stored on shared drives have no enforced version control, no electronic approval workflow, and no automatic linkage to the systems or projects they govern. When a system's status changes — retired, upgraded, or reclassified — updating the relevant plan sections depends entirely on someone remembering to do it. Digital validation platforms manage plans as structured, linked records where each system entry in the VMP is connected live to its validation status, making the plan a current reflection of the site's actual compliance posture.