The Validation Master Plan and Computerized System Periodic Review

Most computerized system validation failures are not failures of testing. The protocols passed. The screenshots were captured. The deviations were closed. The failure shows up two years later, when an inspector asks a simple question, “show me the current list of GxP systems and tell me which ones are still in a validated state”, and the answer is a shrug, three spreadsheets that disagree, and a system that was patched eleven times since its last qualification with no one re-assessing whether the validation still held.

That gap is exactly what two governing documents are supposed to close: the Validation Master Plan (VMP), which defines how the whole program runs, and the periodic review, which is the recurring obligation to confirm a system is still validated long after go-live. This article covers both, what each must contain, how they connect, how to execute them step by step, and what an inspector is actually probing when they pull on either thread. The principles apply across pharmaceutical manufacturing, biologics, cell and gene therapy, combination products, and laboratory operations, anywhere a computerized system touches a GxP record or decision.

Why a program needs a plan above the protocol level

Individual validation deliverables, a User Requirements Specification, an IQ/OQ/PQ, a Requirements Traceability Matrix, answer the question “is this one system fit for use?” They say nothing about consistency, prioritization, or how a hundred systems are kept current across an organization. Two project teams left to their own devices will validate to two different standards, classify risk two different ways, and disagree about what even counts as a GxP system. The VMP exists to impose one answer to those questions before any single project starts.

The expectation for a documented, planned approach to validation is long-standing in GxP. EU GMP Annex 15 (Qualification and Validation) establishes that validation should be planned and that a Validation Master Plan or equivalent document should summarize the facility’s validation philosophy, approach, and program. EU GMP Annex 11 (Computerised Systems) carries the same expectation into the digital domain, requiring that validation documentation and reports cover the relevant life-cycle steps and that risk management be applied throughout. ISPE’s GAMP 5, A Risk-Based Approach to Compliant GxP Computerized Systems, Second Edition (2022), provides the industry framework that operationalizes these expectations, and FDA’s Computer Software Assurance for Production and Quality Management System Software (issued as a draft in 2022, finalized 24 September 2025, and revised 3 February 2026) reframes the effort toward critical-thinking and least-burdensome assurance rather than documentation volume. None of these mandate a single document literally titled “VMP”, but every one assumes that a planned, risk-based, governed approach exists and is written down somewhere defensible.

The same discipline runs through US drug and biologics cGMP: 21 CFR 211 and the predicate-rule expectation that systems used in production and quality decisions are controlled, and, for combination products under 21 CFR Part 4, the cGMP streamlined approach that pulls drug and device-constituent quality-system controls together for a single product. A combination product that includes a device constituent (for example a prefilled syringe or an on-body delivery system) is squarely in scope here, with its software and data-bearing systems validated to the same risk-based standard as the drug-side systems. The vocabulary differs across frameworks, the obligation does not.

One way to hold the relationship straight: the VMP is the constitution, the validation plans are the statutes for each project, and the periodic review is the standing audit that confirms the constitution is still being honored after the projects ship.

What a Validation Master Plan must define

A VMP that earns its keep answers five questions concretely. Vague mission statements about “commitment to quality” are not what an auditor reads it for.

1. Scope and policy. State exactly which systems, processes, sites, and product types the plan governs, and, just as important, what it excludes and why. The defensible scoping criterion is GxP impact: does the system create, modify, store, archive, retrieve, or transmit data or decisions that affect product quality, patient safety, or data integrity? A document management system holding batch records is in scope. A cafeteria menu app is not. The boundary cases, a building management system whose alarms feed a GMP cold-storage qualification, a spreadsheet doing a release calculation, are where scoping discipline shows, so the VMP should give the decision logic, not just a list. Publishing that logic as a short decision path saves months of argument and gives an inspector something to test the program against.

The middle branch is the one programs get wrong. A pass-through system is still in scope; it is the rigor that scales down, not the governance.

2. Validation approach and life cycle. Declare the life-cycle model the organization follows (the V-model remains the common reference, mapping specifications on the left arm to corresponding verification on the right) and how GAMP software categories drive the rigor applied. GAMP 5 categories, Category 1 infrastructure software, Category 3 non-configured products, Category 4 configured products, and Category 5 custom/bespoke applications, scale the expected effort: a Category 3 instrument with default firmware is verified far more lightly than a Category 5 custom LIMS workflow. The VMP states this scaling explicitly so teams do not over-test commodity software or under-test custom code. Under the CSA philosophy, it should also state where assurance effort is concentrated, on features whose failure would directly harm the patient or corrupt a quality record, and where unscripted or exploratory testing and vendor evidence are acceptable for lower-risk, non-product features.

3. Roles and responsibilities. Name the functions, not the individuals: System Owner (accountable for the system meeting business needs and staying compliant across its life), Process Owner (accountable for the business process the system serves), Quality Assurance (independent review and approval, release decision), IT/infrastructure (the qualified platform the application runs on), and the validation lead. Annex 11 specifically expects a defined relationship between the regulated company and any supplier or service provider, with responsibilities documented, so supplier and integrator roles belong here too. The single most common ambiguity an inspector exploits is the boundary between System Owner and QA approval authority; the VMP should leave no doubt who can authorize a system for GxP use and who can release it back to service after a change. A short RACI table in the VMP settles most of these arguments before they start:

(A = accountable, R = responsible, C = consulted, I = informed. Each organization tailors this, but the VMP should publish one canonical version.) See GxP roles and responsibilities for how these map to job functions.

4. System inventory. The VMP must require and point to a controlled inventory of computerized systems within scope. Annex 11 is explicit that an up-to-date list of relevant systems and their GxP functionality should be available. This inventory is the spine of the entire program, it is what periodic review schedules against, what change control checks against, and what an inspector requests first. A workable inventory carries at minimum the fields below.

If the inventory is a stale spreadsheet that disagrees with reality, the rest of the program is theater. Keeping it current is itself a controlled, owned activity, not a once-a-year cleanup. A practical control is to make inventory update a mandatory step in both onboarding (no go-live without an inventory entry) and decommissioning (no retirement without flagging the entry and recording the archive location for retained records).

5. Prioritization and risk-based effort. The VMP defines how risk determines where effort goes, which systems get validated first, how deeply, and how often they are reviewed afterward. This is the bridge to ICH Q9(R1) (Quality Risk Management), whose principles, that risk evaluation should be based on scientific knowledge and ultimately link to patient protection, and that the level of effort should be commensurate with the level of risk, apply directly to validation prioritization. A high-criticality, custom (Category 5) system handling release decisions sits at one end; a Category 3 utility system with no direct GxP data at the other. The VMP should give the matrix or scoring logic that places systems on that spectrum, because that placement is what later justifies a two-year review interval for one system and an annual one for another. The CSV risk assessment methodology article covers the scoring mechanics; the VMP simply commits the program to using one.

A VMP should also state its supporting infrastructure expectations, that production sits on qualified infrastructure, that there are procedures for backup and restore, business continuity, security and access management, audit trails, periodic review, and decommissioning, even if the detailed procedures live in separate SOPs. The VMP is the map that shows those procedures exist and connect.

Acceptance criteria: what a good VMP looks like

Before issuing a VMP, run it against this checklist. A reviewer or auditor will.

• Scope is stated with explicit inclusion and exclusion logic, not just a list.
• The life-cycle model and the GAMP category-to-rigor mapping are written down.
• Roles are defined as functions with a clear authorization-and-release authority, and supplier responsibilities are addressed.
• A controlled, owned inventory is required and referenced, with named maintenance responsibility.
• Risk-based prioritization and review-frequency logic is defined and traceable to ICH Q9 principles.
• The plan cross-references the SOPs it depends on (change control, periodic review, backup, security, decommissioning) rather than restating them.
• It is approved by QA and current (under its own change control and periodic review).

Worked example: a small VMP scope and inventory extract

A facility runs a quality-management software suite, a laboratory information system, a chromatography data system, a warehouse environmental-monitoring system, and a handful of validated spreadsheets. A defensible VMP scope statement and the resulting inventory extract might read like this.

Scope: This VMP governs all computerized systems that create, modify, store, archive, retrieve, or transmit data or decisions affecting product quality, patient safety, or GxP data integrity at the [site] operations. Excluded: general office productivity, facilities-comfort systems with no GxP alarm function, and corporate finance systems with no product-quality data. Boundary systems (building management alarms feeding cold-storage qualification; spreadsheets performing GxP calculations) are in scope and individually assessed.

Note the high-criticality systems on a 12-month cycle, the medium ones on 24, and the validated spreadsheet treated as high because it performs a release calculation despite its low technical complexity. That last call is exactly the kind of judgment an inspector looks for evidence of. See infrastructure qualification and spreadsheet validation for how to validate that spreadsheet, and LIMS implementation and validation for the lab systems.

The periodic review obligation

Validation is a point-in-time conclusion: as configured, tested, and documented on this date, the system is fit for its intended use. The problem is that systems do not stay frozen. They get patched, upgraded, re-configured, integrated with new interfaces, moved to new servers, and operated by new people running new processes. Every one of those changes is a chance for the validated state to quietly erode. Periodic review is the control that periodically re-asks the question the original validation answered: is this system still in a validated state today?

The requirement is explicit. EU GMP Annex 11, Section 11 states that computerised systems should be periodically evaluated to confirm that they remain in a valid state and are compliant with GMP, and that such evaluations should include, where appropriate, the current range of functionality, deviation records, incidents, problems, upgrade history, performance, reliability, security, and the validation status reports. The MHRA’s ‘GxP’ Data Integrity Guidance and Definitions (2018) reinforces the same theme from the data-integrity angle, that the ongoing suitability and control of systems generating regulated data must be maintained, not assumed. GAMP 5 treats periodic review as a core operational-phase activity within the system life cycle, alongside change management, incident management, backup/restore, and security administration.

Periodic review is not re-validation. It is an evidence-gathering and assessment exercise that concludes whether the validated state still holds, and, if it does not, identifies the corrective action, which may be re-validation, remediation, or a return to controlled change. Confusing the two leads either to wasteful full re-qualification of stable systems or, worse, to skipping the assessment because “full re-validation seemed like too much.”

What a periodic review actually examines

A credible periodic review pulls evidence from the operational records accumulated since the last review and tests each against the assumption that the system is still controlled and fit for use. The inputs below map directly to what Annex 11 Section 11 contemplates.

The output is a periodic review report with a clear, signed conclusion, system remains in a validated state, remains validated with actions, or validated state not confirmed, plus a CAPA list with owners and due dates, and the date set for the next review. QA approval of that conclusion is the control that makes the review more than a self-attestation by the system owner.

The three conclusions are not interchangeable, and each commits the organization to a different next step. Deciding that in advance stops the review from drifting toward the comfortable answer.

The third conclusion is the one that gets softened under pressure. If the evidence supports it, recording anything else documents that the review saw the problem and looked away.

How to run a periodic review, step by step

1. Schedule and trigger. The inventory’s “next review” date fires the review. Open it as a controlled record with an ID, an owner, and a due date. Build in lead time; a high-criticality system needs weeks, not a single afternoon.
2. Define the period and the scope. State the review window (from last review date to now) and confirm the system identity, version, and validated baseline you are reviewing against. Pull the validation summary report and the last periodic review report as your reference points.
3. Collect the evidence. Request the records in the table above from each owning function: change log, deviation log, patch history, current access list, backup/restore evidence, audit-trail review records, training records, supplier status. Insist on the actual records, not verbal assurance.
4. Assess each input against the validated state. For each line, decide: compliant, compliant-with-action, or non-conformance. The questions in the table tell you what “non-conformance” looks like (an undocumented change, an unverified restore, a leaver still holding admin rights).
5. Reconcile configuration to baseline. Compare the live configuration of GxP-relevant settings (calculations, workflows, e-signature behavior, audit-trail settings, roles) against the documented validated configuration. Any drift is a finding to explain or remediate.
6. Form the conclusion. Roll the line assessments into one of the three conclusions. Be honest; a “remains validated” conclusion sitting next to open undocumented changes is a self-inflicted finding.
7. Raise CAPAs and set the next date. Each action gets an owner, a due date, and a CAPA reference. Set the next review date per the risk tier (or sooner if the review surfaced instability).
8. QA review and approval. QA independently reviews the evidence and conclusion and approves. Update the inventory with the completed date, the conclusion, and the next-due date.

Acceptance criteria for a periodic review

• The review covers a defined period with no gap since the last one.
• Each Annex 11 Section 11 input was actually examined with evidence cited, not asserted.
• Configuration was reconciled to the validated baseline.
• A restore was verified, not merely “backups are running.”
• The conclusion is consistent with the evidence (no “validated” over open undocumented changes).
• CAPAs have owners and dates; prior-review CAPAs are confirmed closed and effective.
• QA approved, and the inventory was updated with completion and next-due dates.

Frequency by risk

There is no universal regulatory number for review frequency; Annex 11 says “periodically” and leaves the interval to a risk-based, justified rationale. That is a feature, not a gap, it forces the organization to defend its intervals against criticality rather than apply a blanket rule. The VMP should define the scheme; a defensible one ties interval to the same criticality used for validation prioritization.

Two refinements matter. First, the interval is a maximum, not a target, a high change rate or a major incident should pull a review forward regardless of the calendar. Second, the rationale for each tier must be written and approved, because an inspector who sees a three-year interval on a release-critical system will ask precisely one question: justify that. “It’s our standard” is not a justification; a documented risk assessment tied to ICH Q9 principles is.

What triggers re-validation (versus a periodic review)

Periodic review is scheduled. Re-validation is triggered, by an event that plausibly invalidates the prior validation conclusion. The distinction the program must encode is that change control, not the calendar, is the primary trigger mechanism: every change is impact-assessed, and the assessment decides whether no validation action, a targeted re-test, or full re-validation is warranted. Annex 15 frames this directly, significant changes that could affect product quality or the validated/qualified state require evaluation and, where justified, re-qualification or re-validation. See change control for validated systems for how the impact assessment is structured.

Common re-validation (or partial re-validation) triggers:

• Major application upgrades, a new version that changes functionality, data structures, or the audit trail. A point patch may need only regression testing of affected functions; a major version generally needs a planned re-validation of impacted requirements.
• Configuration changes to GxP-relevant functionality, altered calculations, workflows, electronic signature behavior, audit-trail settings, or user-role definitions.
• Infrastructure / platform migration, moving to a new server, database engine, OS, or from on-premises to cloud/SaaS. The qualified platform changed, so the validated state must be re-confirmed on the new platform. See cloud and SaaS validation.
• New or changed interfaces / integrations, any new data flow into or out of the system, where data-transfer accuracy must be re-verified end to end.
• Data migration, when records are moved to a new system or database; migration must be validated for completeness and accuracy (data migration validation).
• Process or intended-use change, the system is now used for a new GxP purpose the original validation never covered; the URS itself has effectively changed.
• A periodic review that concludes the validated state is not confirmed, drift, undocumented changes, or repeated incidents found during review feed directly into a re-validation CAPA.
• Findings from data-integrity assessment, audit, or inspection, a finding that the system’s controls are inadequate is a trigger in its own right.

The governing principle is risk and impact, not the size of the change ticket. A one-line configuration change to a release-decision calculation is more consequential than a cosmetic UI upgrade touching a hundred screens. The impact assessment, not the change’s apparent magnitude, sets the validation response, and that assessment must be documented and QA-reviewed for GxP-critical systems.

Worked example: a change impact decision

A LIMS vendor issues a minor release. The change record asks three questions: does it touch GxP functionality, does it change data structures or the audit trail, and does it affect any validated requirement? The patch notes show a fix to a result-rounding routine used in specification comparisons. That touches a GxP calculation, so “cosmetic patch, no testing” is the wrong answer. The correct response is a targeted re-validation: re-execute the requirements and test cases covering the rounding and specification-comparison logic, confirm the audit trail still captures the change, and update the traceability matrix and validation summary. The full system is not re-validated; the impacted slice is. That proportionality is the heart of CSA-aligned thinking.

When the supplier controls the release calendar

Everything above assumes the classic model: you decide when the system changes, you assess the change, you test it, then you approve it into production. Multi-tenant SaaS breaks that assumption, and it is now the normal case for quality management suites, training systems, document control, and a growing share of laboratory software. The vendor ships on its own schedule, to every tenant at once, and you cannot defer the release or run the old version indefinitely. A change-control process that says “QA approves before the change is applied” describes something the organization no longer has the power to do, and an inspector who reads that SOP and then looks at the vendor’s monthly release history will find the gap immediately.

The honest response is not to pretend you still hold the approval gate. It is to relocate the control to the points you do still hold: what you contract for, what you triage, what you test, and what you verify after the fact.

Five controls make this defensible.

1. Contract for what you need before you sign. The quality or technical agreement is where you secure a minimum advance-notice period, release notes with enough detail to assess GxP-relevant change, access to a sandbox or preview tenant during the notice window, notification of incidents and security events, and the right to audit. These are hard to obtain after go-live and nearly impossible after renewal. Supplier and vendor qualification covers the assessment; the agreement is where the assessment turns into an obligation.

2. Know which vendor functionality you actually depend on. Most triage effort is wasted reading release notes for features nobody uses. Maintain a register of the specific configured functions your GxP processes rely on (the release-decision workflow, the e-signature manifestation, the audit trail settings, a particular calculation, a specific report). Triage then answers a narrow question: does anything in this release touch one of these? That is a ten-minute review rather than a fifty-page read.

3. Triage every release, and record the triage. Each vendor release gets a dated record: release identifier, date applied, what the notes say changed, whether any dependent function is affected, the resulting action (none, targeted regression, full impact assessment), and who decided. A release that reached production with no triage record is the finding, and it is the one an inspector can find mechanically by comparing the vendor’s release history to your records.

4. Keep a fast regression set. The notice window is short, so the test set that protects your GxP functions has to be runnable in it. Scope it to the dependent functions from control 2, keep it current, and run it in the sandbox before the release reaches production, or immediately after if no sandbox exists.

5. Verify after the fact when you could not verify before. Where a release lands without a usable notice window, the compensating control is prompt post-release verification of the dependent functions, with the result recorded. This is weaker than pre-approval and should be documented as such, with the residual risk accepted at a named level of authority rather than left unstated.

Periodic review is where this whole arrangement gets audited. The review should reconcile the vendor’s release history for the period against your triage records and confirm there are no unaccounted releases, that dependent-function regression was run where triage called for it, and that the supplier still meets its notice and documentation obligations. A supplier that has quietly stopped sending release notes is a periodic review finding even if nothing has broken yet, because the control you rely on has lapsed.

The regulatory direction supports this framing. EU GMP Annex 11 already expects the relationship with suppliers and service providers to be defined and responsibilities documented, and the draft revision issued for public consultation in July 2025 (consultation closed October 2025, not final as of mid-2026) gives cloud and supplier arrangements noticeably more attention than the 2011 version. Treat the draft as direction of travel rather than as a current requirement, and see cloud and SaaS validation for the qualification mechanics.

Scaling periodic review across a large estate

A program with 15 systems can review every one deeply. A program with 250 cannot, and the failure mode is predictable: reviews slip, then get batched into a year-end rush, then get thinner until they are template exercises with a pre-written conclusion. Scaling is not about doing less. It is about spending the available review effort where an eroded validated state would actually cost something.

Three mechanisms do most of the work.

Tiered depth, not just tiered frequency. The frequency table above sets how often. Depth should scale too. A high-criticality system gets the full evidence set with configuration reconciliation and a verified restore. A low-criticality, stable Category 3 system can be reviewed against a shorter evidence set, with the reduced scope stated in the procedure rather than improvised by whoever runs it.

Grouping like systems. Where a set of systems shares a platform, an administrator, a backup regime, and a change process (a fleet of identical instrument data stations, for example), the shared controls can be reviewed once for the group, with a per-system check limited to what is genuinely system-specific. The group review and the per-system records both have to exist, and the grouping rationale has to be written down. Grouping unlike systems to save time is how a program ends up unable to explain why a release-critical system was reviewed as part of a batch.

Sampling within a group, with a rationale. For a large homogeneous group, the shared-control evidence can be sampled rather than fully enumerated, provided the sample size and selection basis are defined in advance and the systems with the highest criticality are always reviewed individually. Sampling that is decided after the fact, or that always happens to select the easy systems, is not a control.

Program health is worth measuring directly, because these are the numbers an inspector reconstructs anyway and it is better to know them first.

That fifth row deserves a comment. A program that has never once concluded that a validated state was not confirmed is not necessarily a healthy program. Across hundreds of system-years, some systems drift. A permanent record of clean conclusions is more often evidence that the review cannot detect a problem than evidence that no problem exists. See quality metrics and KPIs for how to build and govern measures like these without turning them into targets people manage toward.

Roles across both processes

What inspectors actually look for

Auditors and inspectors rarely read a VMP cover to cover. They sample, and they sample at the seams where programs break.

• Inventory completeness. The first request is usually the system list. Inspectors then probe for systems that should be on it but are not, the validated spreadsheet doing a calculation, the lab instrument’s data station, the SaaS tool a department adopted without IT. A system performing a GxP function that is absent from the inventory is a finding, because it means the governance described in the VMP is not actually being applied to reality.
• Periodic reviews that are real, not retrospective box-checks. They will pull a review report and check whether it genuinely examined change history, deviations, access, and backups, or whether it is a template with a pre-written “remains validated” conclusion and no evidence behind it. A review that concludes “validated” while open deviations and undocumented changes sit in the same period is worse than no review, because it documents that the control failed to detect a known problem.
• The change-control-to-validation link. They trace a sample of changes and check whether each was impact-assessed for validation, and whether changes that should have triggered re-validation actually did. A patch applied to a GMP system with no documented impact assessment is a classic finding.
• Audit trail and Part 11 controls in the operational phase. For systems holding electronic records and signatures, FDA expects compliance with 21 CFR Part 11, secure, time-stamped audit trails, controlled access, and signature controls, sustained across the system’s life, not just demonstrated once at validation. Annex 11 and the MHRA data-integrity guidance reinforce that audit trails must be reviewed; a periodic review is where “are we actually reviewing audit trails per our SOP?” gets verified. See operationalizing audit trail review.
• Overdue reviews and stale intervals. A review past its due date, or a long interval on a high-criticality system without a documented risk rationale, is a quick finding that signals broader program drift.

What ties all of this together is consistency between what the VMP says the program does and what the records show the program did. The plan can be elegant; if the inventory is incomplete, reviews are overdue, and changes bypass impact assessment, the VMP becomes evidence against the organization, a documented standard it failed to meet.

Common mistakes and inspection-finding patterns

• The “ghost system.” A spreadsheet, a data station, or a departmental SaaS tool performs a GxP function but never made it onto the inventory, so it was never validated and is never reviewed. The most common root of a data-integrity observation.
• Self-attested reviews. Periodic reviews signed only by the system owner with no QA approval and no cited evidence, conclusions that read as fill-in-the-blank.
• The “remains validated” reflex. A conclusion of validated state while open deviations, undocumented configuration changes, or unresolved CAPAs exist in the same period. Documents that the review failed.
• Untested restore. “Backups run nightly” recorded as the backup control with no evidence a restore was ever performed. Backups you cannot restore are not a control.
• Patch drift. Operating-system and database patches applied by IT with no validation impact assessment, the application’s validated state silently undermined by platform changes nobody assessed.
• Stale intervals without rationale. A 36-month interval on a release-critical system, or no documented rationale for any interval. The interval scheme exists but the per-tier justification does not.
• Leavers retaining access. Periodic review skips the access reconciliation, terminated or transferred users still hold privileges, segregation of duties broken.
• Untriaged vendor releases. A SaaS system took eleven vendor releases in the review period and the change log holds none of them, because the SOP only recognizes changes the organization initiates. The vendor’s own release history is public evidence against you here.
• A change-control SOP describing authority you no longer hold. The procedure requires QA pre-approval of every change to a system whose supplier ships to all tenants on its own schedule. The gap between the written control and the achievable one is the finding.
• VMP that overpromises. A VMP describing a mature program the records do not support, turning the plan into the standard the organization is judged against and fails.

Interview questions and how to answer them

These come up for CSV, validation, and quality-systems roles. Crisp, specific answers separate candidates who have run a program from those who have read about one. See GxP quality interview preparation for broader coverage.

Q: What is the difference between a VMP and a validation plan? The VMP is program-level; it sets scope, life-cycle model, roles, the inventory requirement, and risk-based prioritization once, so every project validates to one standard. A validation plan (or project plan) is system-specific; it applies the VMP to one system. The VMP is the constitution, the validation plan is the statute for one project.

Q: How often must a computerized system be periodically reviewed? There is no fixed regulatory number. Annex 11 Section 11 says “periodically” and leaves the interval to a justified, risk-based rationale. A defensible scheme ties the interval to criticality, for example 12 months for high-criticality release-relevant systems, 24 for medium, 36 for low, with the per-tier rationale documented and the interval treated as a maximum that incidents or high change rates can pull forward.

Q: What is the difference between periodic review and re-validation? Periodic review is scheduled and assesses whether the validated state still holds, it is evidence-gathering and a conclusion, not re-testing. Re-validation is triggered by a change or finding that plausibly invalidates the prior conclusion, and it re-executes the affected validation. A periodic review can conclude that re-validation is needed, but it is not itself re-validation.

Q: What triggers re-validation? Change control, not the calendar, is the primary trigger. Major upgrades, GxP-relevant configuration changes, platform or infrastructure migration, new or changed interfaces, data migration, an intended-use change, a periodic review concluding the validated state is not confirmed, and adverse audit, inspection, or data-integrity findings. The impact assessment, not the size of the change, sets the response.

Q: An inspector asks for your system inventory and finds a validated spreadsheet doing a release calculation that is not on it. What is the finding and why does it matter? The finding is that a GxP system is outside the governed program: not on the inventory, so not validated, change-controlled, or periodically reviewed. It matters because it shows the VMP is not applied to reality, and because a release calculation is high-criticality, an error there flows straight to product disposition. It signals the inventory cannot be relied on, which casts doubt on the whole program.

Q: How does GAMP 5 software categorization affect the program? It scales rigor. Category 1 infrastructure and Category 3 non-configured products carry lighter verification, often leaning on supplier evidence; Category 4 configured products need configuration verified against requirements; Category 5 custom code needs the most, including design and code-level assurance. The VMP states this mapping so teams neither over-test commodity software nor under-test custom code. CSA reinforces concentrating effort where failure would harm the patient or corrupt a record.

Q: Your QMS is multi-tenant SaaS and the vendor pushes releases monthly. Your SOP says QA approves changes before production. What do you do? Acknowledge that the pre-approval gate no longer exists and move the control to where you still hold it, rather than leaving an SOP that describes a power you do not have. Secure advance notice, release notes, and sandbox access in the quality agreement; maintain a register of the specific vendor functions your GxP processes depend on so triage is scoped; triage and record every release against that register; keep a regression set short enough to run inside the notice window; and where a release lands without a usable window, verify the dependent functions promptly afterward and record the residual risk as accepted. Then have periodic review reconcile the vendor’s release history against your triage records. The wrong answer is to keep the old SOP and hope nobody compares it to the vendor’s release history.

Q: You have 250 systems and cannot review them all deeply. How do you scale without gutting the control? Scale depth as well as frequency, and write the scaling into the procedure rather than leaving it to whoever runs the review. High-criticality systems get the full evidence set including configuration reconciliation and a verified restore. Groups of genuinely alike systems sharing a platform, administrator, backup regime, and change process can have their shared controls reviewed once for the group, with per-system checks for what is system-specific and the grouping rationale documented. Within a large homogeneous group, shared-control evidence can be sampled if the sample size and selection basis are defined in advance and the highest-criticality systems are always reviewed individually. Then measure the program: overdue rate by tier, inventory accuracy, and whether prior-review CAPAs actually closed.

Q: Every periodic review your program has ever run concluded “remains validated.” Is that good news? Usually not. Across a large estate over several years, some systems drift, patches get applied without assessment, and access lists go stale. A perfect record is more likely to mean the review cannot detect a problem than that no problem has occurred. I would treat it as a signal to check whether reviews are examining real evidence or restating a template, whether the reviewer is independent enough to record an uncomfortable finding, and whether “remains validated with actions” is being used to avoid the harder third conclusion.

Q: How do CSA and the older CSV approach differ here? CSA (FDA guidance, 2022 draft, final 2025, current version February 2026) shifts the emphasis from documentation volume to critical thinking and least-burdensome assurance, more unscripted/exploratory testing and reliance on supplier evidence for low-risk features, with rigorous scripted testing reserved for high-risk, patient-impacting functions. In the VMP, that shows up as an explicit statement of where assurance effort is concentrated. See Computer Software Assurance (FDA).

Bringing it together

The VMP and periodic review are two sides of the same discipline. The VMP defines the program once, scope, life cycle, roles, inventory, and how risk concentrates effort, so that every project is validated to one consistent, defensible standard. Periodic review keeps the conclusion of each of those projects honest over time, re-confirming on a risk-based schedule that systems still hold the validated state they were granted, and routing change-driven erosion into re-validation when an impact assessment demands it.

When both work, the program can keep a simple promise: at any moment, the organization can produce a current list of its GxP computerized systems, state the validation status of each, and show evidence, recent, signed, and grounded in operational records, that each remains fit for its intended use. That is what an inspector is looking for, and it matters beyond the audit, because behind many of those systems is a record that decides whether a product is safe to release.

Related reading

• CSV risk assessment methodology
• Change control for validated systems
• GAMP 5 CSV framework
• Validation deliverables guide
• User requirements and traceability
• 21 CFR Part 11 and EU Annex 11
• GxP computerized systems operations
• Retroactive validation of legacy systems

Key references

• EU GMP Annex 11, Computerised Systems (validation, risk management, periodic evaluation, supplier responsibilities, audit trails). EudraLex Volume 4, Annex 11
• EU GMP Annex 15, Qualification and Validation (Validation Master Plan, change control, re-qualification triggers).
• ICH Q9(R1), Quality Risk Management (risk-based effort, link to patient protection). ICH Q9
• ISPE GAMP 5, 2nd Edition (2022), A Risk-Based Approach to Compliant GxP Computerized Systems (software categories, life cycle, operational-phase activities including periodic review).
• FDA, Computer Software Assurance for Production and Quality Management System Software (draft 2022; final 24 September 2025; current version issued 3 February 2026), and 21 CFR Part 11, Electronic Records; Electronic Signatures. 21 CFR Part 11
• MHRA, ‘GxP’ Data Integrity Guidance and Definitions (2018) (ongoing control and suitability of data-generating systems).
• 21 CFR 211 (cGMP for finished pharmaceuticals) and 21 CFR Part 4 (cGMP for combination products), for the predicate-rule expectation that systems used in production and quality decisions are controlled and validated.