Periodic Review & Schedule
Frequently Asked Questions

Periodic review is a scheduled, documented evaluation that confirms a validated GxP system remains in its validated state, still fits its intended use, and that its underlying risk assumptions remain sound — it is not simply a check that nothing has changed.

A thorough periodic review examines the change history since the last review, outstanding deviations and their closure status, incident and disaster recovery records, user complaints and error trends, calibration and maintenance records for connected instruments, supplier communications about software changes, regulatory guidance updates affecting the system's compliance posture, and the currency of the Validation Master Plan entry for that system.

EU GMP Annex 11 Clause 11 states that computerised systems should be evaluated periodically to confirm that they remain in a validated state. This is a performance-based obligation — the review must actively confirm fitness for use, not passively note the absence of formal change requests.

Annex 11 Clause 11 requires that computerised systems be periodically evaluated to confirm they remain in a validated state — it does not prescribe frequency, format, or document title, leaving those decisions to a risk-based quality system.

The clause requires the evaluation to confirm that the system, its software, data handling, and documentation are still consistent with the validated state established at initial qualification. In practice this means the review must reconcile the system's current configuration, software version, and operating environment against what was qualified — not merely confirm no formal change requests were raised.

The draft revised Annex 11, which entered stakeholder consultation in 2025, is expected to strengthen periodic review expectations, particularly for cloud-hosted systems and those subject to continuous vendor updates. Organisations should monitor the final text closely.

FDA does not use the phrase "periodic review" in 21 CFR Part 11, but the expectation of ongoing maintenance of validated state is embedded in its cGMP regulations, software validation guidance, and the 2026 Computer Software Assurance final guidance.

FDA's General Principles of Software Validation states that software validation is not a once-and-done activity — the validated state must be maintained throughout the system's operational life. The final CSA guidance reinforces that ongoing assurance activities are expected proportionate to risk, which operationally requires periodic re-evaluation of whether the system continues to perform its intended function reliably.

During pharmaceutical drug-GMP inspections, FDA investigators routinely request evidence of ongoing system monitoring, change history review, and validation file currency — activities that constitute periodic review whether or not organisations call them by that name.

Periodic review is an evaluation that determines whether the current validated state is still adequate; revalidation is additional validation work performed when the evaluation concludes that the existing evidence no longer supports continued GxP use.

A periodic review that finds the system unchanged, performing as qualified, with no outstanding risk items, closes with a documented conclusion that the validated state is confirmed — no new testing is required. Revalidation is triggered when the review identifies a gap: a configuration change not covered by existing qualification evidence, a software version update beyond the qualified baseline, or a significant process change that affects how the system is used in GxP operations.

The confusion between the two terms often leads organisations to either over-test (performing full revalidation when a review conclusion would suffice) or under-document (closing a review that should have triggered revalidation without formal evidence). The distinction matters for both resource efficiency and inspection defensibility.

Change control captures intentional, planned modifications; periodic review catches what change control misses — informal configuration drift, vendor-side changes, expired calibrations, accumulating minor deviations, and shifts in the regulatory or operational context the system operates in.

In practice, systems in production environments experience changes that were never submitted to change control: infrastructure patches applied by IT, vendor updates pushed to cloud-hosted applications, instrument firmware updates treated as maintenance rather than changes, and gradual process evolution that shifts the system's actual use beyond its validated boundary. Periodic review is the safety net that detects this drift before it becomes an inspection finding.

ICH Q10 describes change management and periodic review as complementary quality system elements. An organisation with robust change control still needs periodic review to confirm that the accumulated state of all changes — individually assessed but never jointly evaluated — still adds up to a validly qualified system.

Neither EU GMP Annex 11 nor FDA regulations prescribe a specific frequency; the appropriate interval for each system should be determined by a documented, risk-based assessment that considers the system's GxP impact, rate of change, and operating environment stability.

Common industry practice ranges from annual review for high-risk direct-impact systems (batch release, LIMS, MES) to biennial for lower-risk systems with stable configurations and limited GxP data scope. The key principle from ICH Q9(R1) is that review effort should be proportionate to risk — a mission-critical system processing batch release decisions warrants more frequent review than a document management system used only for SOP storage.

The chosen frequency should be documented with a rationale in the system's Validation Plan or the site's Validation Master Plan, and should be revisited whenever the system's risk profile changes — for example, when the system is expanded to support additional GxP processes or when the organisation has experienced recurring incidents or deviations.

A risk-based review schedule assigns each system a review interval based on its GxP impact classification, change frequency, incident history, data integrity sensitivity, and the consequences of the system operating outside its validated state without detection.

Start with the system's GxP impact classification from the inventory: direct-impact systems warrant the shortest intervals. Then layer in dynamic risk indicators: a system with frequent changes, recent deviation history, or a recent vendor notification of significant software updates should be reviewed sooner than its baseline interval. A system with no changes, no incidents, and a stable vendor relationship may justify extending the interval with documented rationale.

ICH Q9(R1)'s risk evaluation framework — severity of harm, probability of occurrence, and detectability — translates directly into review scheduling decisions. A system where a validation gap would be difficult to detect in production and would directly affect product quality or patient safety demands a shorter review cycle than one where operating anomalies are immediately visible.

Portfolio-scale periodic review management requires a centralised scheduling system — typically the GxP System Inventory — that tracks each system's last review date, assigned interval, and next due date, with automated escalation for approaching and overdue reviews.

Without a centralised tracking mechanism, periodic reviews fall through the gap between IT change management (which tracks versions) and quality management (which tracks deviations and CAPAs). A spreadsheet-based inventory often fails at scale because it depends on someone manually checking dates — whereas a digital validation platform surfaces overdue reviews as active alerts tied to the system owner's responsibilities.

Practical portfolio management also requires batching: grouping systems by owner, department, or application server so that reviews across related systems can be coordinated and resource requirements predicted. Sites with 100+ systems should define a rolling annual review calendar that distributes reviews throughout the year rather than clustering them at year-end.

An unscheduled review should be triggered whenever an event makes it likely that the system's validated state may have been compromised or that its current risk profile no longer matches the assumptions underlying the last review.

• A vendor notification that the software version in production is approaching end-of-support or has reached end-of-life.
• Discovery of an undocumented configuration change or software update applied without change control.
• A significant deviation, incident, or data integrity event linked to the system that was not anticipated in the existing risk assessment.
• A regulatory guidance update — new Annex 11 revision, FDA warning letter pattern, or ISPE guide — that changes expectations for the system's technology type.
• A significant change to the business process the system supports, even when the software itself was not modified.
• A merger, acquisition, or outsourcing arrangement that changes the system's operational or regulatory context.

An overdue periodic review does not automatically render a system unvalidated, but it creates a compliance exposure that grows with time and becomes an inspection finding if the system is assessed during that gap.

The system's validated state was established at initial qualification and maintained through change control. An overdue review means that the cumulative state of the system since its last evaluation has not been formally assessed — the system may still be in its validated state, but this has not been confirmed as required. Regulators and auditors treat an overdue periodic review as evidence that the quality system has not adequately maintained oversight of the validated environment.

The appropriate response to an overdue review is not to immediately restrict the system but to conduct the review promptly, document the delay with a rationale and risk assessment, and implement process improvements to prevent recurrence. If the overdue review reveals a genuine validation gap, the system's use should then be restricted or controlled until remediation is complete.

A meaningful periodic review goes significantly beyond checking the change control log — it must assess the actual current state of the system, its data, its environment, and the continued validity of the risk and compliance assumptions made at last review.

• Current software version and configuration versus the qualified baseline — including vendor-managed updates, patches, and configuration drift.
• All change control records since the last review, confirming each was assessed, validated where required, and formally closed.
• Open and closed deviation and incident records related to the system, with patterns or recurring issues identified.
• Calibration and maintenance status for instruments or equipment interfacing with the system.
• Supplier and vendor communications, release notes, and end-of-support notifications.
• User access rights and role assignment current state versus what was approved in the system's security specification.
• Backup and disaster recovery test records confirming data can be recovered within required timeframes.
• Audit trail completeness and any exceptions identified during routine data integrity monitoring.
• Training records for current users against the approved training plan.
• Any applicable new or revised regulatory guidance that affects the system's compliance posture.

Periodic review is a responsibility of the regulated organisation — it cannot be fully delegated to a vendor, because the review must assess fitness for the organisation's specific use, environment, and regulatory context, not the vendor's intended use.

In practice, the review is typically led by the system owner or validation lead, with input from IT or technical services for infrastructure and configuration assessment, end-users for operational performance evaluation, and Quality Assurance for compliance and risk conclusion. The system owner is accountable for the factual accuracy of the review findings; QA is accountable for the compliance conclusion.

Vendor-supplied release notes, test reports, and supplier qualification records are evidence inputs to the review, not substitutes for it. The regulated organisation must assess whether the vendor's activities — whatever they found or tested — are applicable to its specific configured use of the system in its own operating environment.

A periodic review report must document not just the conclusion but the evidence and reasoning that support it — an inspector should be able to trace every aspect of the review's scope to an observable, recorded fact.

• System identification: name, version, environment, GxP impact, review date, and review interval rationale.
• Scope of the review: what was examined, what was out of scope and why, and the risk basis for any exclusions.
• Change history assessment: list of changes reviewed, validation evidence status for each, and confirmation all required revalidation was completed.
• Deviation and incident summary: all records reviewed, patterns identified, and CAPA status where applicable.
• Infrastructure and environment assessment: current configuration versus qualified baseline.
• User access review findings: any unauthorised or inappropriate access rights identified and addressed.
• Supplier and vendor status: current version support status, end-of-life risk, quality agreement currency.
• Risk conclusion: whether the current risk profile remains consistent with the validated state or requires updated assessment.
• Outcome and decision: confirmed, conditionally confirmed with tracked actions, or revalidation required.
• Approvals: system owner, validation lead, and QA with signatures and dates.

A system with no changes and no incidents still requires a substantive review — because the absence of formal changes does not mean the system's environment, risk profile, or compliance context has remained unchanged.

The review must still confirm: that no uncontrolled changes occurred (configuration drift, infrastructure patches, vendor updates applied by the hosting provider), that the system's risk assumptions remain valid given any new regulatory guidance or industry incidents in comparable systems, that user access rights are still current and appropriate, and that disaster recovery capabilities were tested within the required interval.

A review that consists of a single sentence stating "no changes were found" and a QA signature is likely to be questioned during inspection. Regulators expect to see that the absence of findings is itself the product of active investigation, not passive assumption.

Cloud and SaaS systems with continuous vendor-managed updates require a periodic review approach that treats vendor release management as a controlled input to the customer's validation lifecycle, not as an external event beyond compliance scope.

The regulated organisation must have a process — typically defined in its quality agreement with the vendor — for receiving advance notice of updates, assessing their impact on the validated configuration, and determining whether each update requires formal change control and supplemental validation before the update is applied to the production tenant. Periodic review then assesses whether this process was followed consistently across every update since the last review.

A periodic review for a cloud system should specifically assess: the list of updates applied since the last review and whether each was assessed through the agreed process, any updates applied by the vendor without advance notice and their retrospective impact assessment, and whether the current tenant configuration still matches what was validated — especially for configurable features that vendors may enable or modify as part of platform updates.

Revalidation is required when the review reveals that the current state of the system, its environment, or its use cannot be demonstrated to fall within the scope of the existing qualification evidence — not merely when something has changed.

• A software version upgrade beyond the qualified baseline where the vendor's release notes document functional changes affecting GxP-relevant features.
• Configuration changes discovered without change control that affect functions validated in original protocols.
• Operating system or database version changes on the hosting infrastructure that were not covered by an infrastructure qualification scope extension.
• Evidence that the system is being used for GxP functions beyond the scope of the original validation — typically discovered through user access reviews or incident investigations.
• A business process change that means the system now processes data types, volumes, or transaction types not covered by original performance qualification.
• Discovery that the original validation was incomplete — for example, a critical requirement was never tested and the gap was not discovered until the review.

The most frequently cited periodic review deficiencies share a common root: the review was treated as a paperwork exercise rather than an active verification of the system's current state.

• No documented review schedule or risk-based rationale for review intervals — systems are reviewed when someone happens to remember rather than on a controlled calendar.
• Review scope limited to formal change control records, missing configuration drift, vendor updates, and infrastructure changes applied without change control.
• Overdue reviews with no escalation record, risk assessment for the gap period, or corrective action to prevent recurrence.
• Review reports that conclude "validated state confirmed" without examining audit trail completeness, user access currency, or disaster recovery test status.
• Revalidation triggered by the review but not completed before the next review is scheduled — creating a rolling gap that compounds over time.
• Cloud and SaaS systems excluded from periodic review on the basis that the vendor manages the system, without recognising that the customer's configuration and use require periodic assessment.
• No connection between periodic review findings and the CAPA system — identified gaps are noted in the review report but never formally tracked to closure.

Inspectors evaluate a periodic review programme by selecting one or two systems and tracing through the complete evidence chain — from the GxP inventory schedule, through the review report, to the underlying change records, deviation logs, and configuration documentation the report claims to have examined.

An inspector will typically compare the change control log entries for a system since its last review against the list of changes documented in the review report, to determine whether the review captured all relevant changes. They will also check whether any changes listed in the review report generated appropriate revalidation evidence, and whether that evidence was completed before the system continued in GxP production use.

The inspector will also look at the system's current configuration and compare it to what the periodic review documented as the qualified baseline — if a discrepancy exists that the review did not identify, it suggests the review was not genuinely examining the system's actual state.

Periodic review findings that identify systemic gaps — repeated instances of the same type of issue, or patterns that indicate a weakness in the quality system rather than an isolated event — should be escalated to the CAPA system rather than closed within the review report.

A single misconfiguration discovered during a review may be resolved through a change control record and a targeted protocol update. But if the same type of misconfiguration has been found across multiple systems in multiple review cycles, the root cause is likely a systemic gap in the change control process — a configuration management SOP that is not being followed, or a change risk assessment template that fails to prompt for configuration impact assessment. That systemic root cause requires a CAPA.

ICH Q10 explicitly treats periodic review as an input to the pharmaceutical quality system's continual improvement process. An organisation whose periodic reviews consistently identify no findings, or whose findings are always closed within the review report without CAPA escalation, should examine whether the reviews are genuinely challenging enough to surface systemic issues.

Each approved periodic review report should be filed in the system's validation file and updates its status in the GxP System Inventory — together, the original qualification package and the chain of review reports constitute the complete evidence that the system has been continuously maintained in a validated state.

An inspection-ready validation file for a system in production for five years should contain: the original validation package (URS, risk assessments, protocols, VSR), change validation records for each material change since release, and periodic review reports at the required intervals. An inspector reviewing this file should be able to confirm continuous validated state at any point in time without finding gaps in the documentation chain.

Organisations that maintain validation files as physical binders or unstructured shared-drive folders frequently discover during inspection preparation that review reports are missing, change records are not linked to the original validation package, or the current system configuration cannot be reconciled with any documented baseline. A digital validation platform that links all these records to the system's inventory entry prevents this fragmentation.