It is a Friday afternoon and someone in your quality team opens a spreadsheet, works through a checklist that has not meaningfully changed in three years, marks a handful of items green, attaches last year’s report for reference, and closes the periodic review with a signature. The system in question has had four undocumented configuration changes applied by IT, two user accounts that belong to employees who left the company six months ago, and a backup procedure that was updated in the change control system but never reflected in the validation documentation. None of this surfaces during the review. The report concludes that the system remains in its validated state.

This is not a hypothetical scenario. It is, in some variation, how periodic review is conducted in a significant portion of regulated organizations today. And it represents one of the most quietly dangerous compliance gaps in the industry – not because companies are being careless, but because the process was designed to generate a record rather than generate insight.

Where the Industry Gets It Wrong

The most common failure mode in periodic review is not the absence of the activity – it is the absence of intent. Organizations perform periodic reviews because their SOPs say they must, at the interval their SOPs specify, using templates that were built during initial validation and rarely revisited. The result is a structured exercise in confirmation bias: reviewers look for evidence that the system is compliant, and they tend to find it.

Several patterns repeat across the industry:

• Fixed-interval scheduling divorced from risk. A LIMS used for release testing and an archival document repository are routinely placed on the same 12-month review cycle. The resource investment is identical for both. The actual risk differential between them is significant.

• Checklist execution without interrogation. Teams verify that change controls were raised, that deviations were closed, and that training records are current. But they rarely ask whether the cumulative effect of those changes has shifted the system’s functional behavior in ways that were never assessed for GxP impact – what could be called silent compliance drift.

• Documentation review mistaken for system review. There is a meaningful difference between confirming that a change control record exists and confirming that the change it describes was implemented correctly, that it did not introduce unintended side effects, and that the validation documentation still accurately reflects the system as it currently operates. Many periodic reviews only achieve the first.

• Regulatory misalignment. EU GMP Annex 11, currently undergoing its most significant revision in over a decade – with the final updated version expected in mid-2026 – explicitly requires that periodic evaluations cover functionality, deviations, incidents, upgrades, performance, reliability, security, and validation status. FDA’s finalized Computer Software Assurance (CSA) guidance, published in September 2025, further reinforces that periodic review records must demonstrate ongoing assurance that software continues to perform as intended. A checklist that does not address these dimensions does not meet either standard.

What Good Actually Looks Like

Effective periodic review is not more review. It is smarter review – grounded in a clear understanding of what the system does, what could have changed since the last assessment, and what the consequences of undetected drift would be.

Organizations that do this well start with a system inventory that is genuinely maintained, not just formally documented. Each system in that inventory carries a risk classification that was established through a documented assessment and that is revisited when the system’s regulatory context, business function, or technical environment changes. That classification directly drives review frequency and scope, not a uniform interval applied across the board.

The cross-functional review team matters. Effective periodic reviews bring together the system owner, who understands business process dependencies; IT or infrastructure, who can confirm the current technical state of the system; and QA, who holds the regulatory framework. Without all three perspectives, the review is structurally incomplete. A QA-only review will miss technical drift. An IT-only review will miss regulatory implications.

What GAMP 5 Second Edition and the evolving Annex 11 framework both emphasize is the shift from periodic review as an audit of records to periodic review as a verification of the system’s current state against its validated baseline. That distinction is operational: it means physically confirming configurations, actively sampling audit trails, verifying that access rights reflect current personnel, and testing that backup and recovery procedures are not just documented but executable. The record follows from the activity. The activity does not exist to produce the record.

A Practical Framework To Follow

The following five principles represent the structural foundation of a defensible, risk-intelligent periodic review program.

1. Risk-stratify your system inventory and schedule accordingly.

Every GxP computerized system should carry a documented risk classification that accounts for its impact on product quality, data integrity, and patient safety. High-impact systems – ERP modules driving batch release, LIMS supporting QC testing decisions, MES systems controlling critical process parameters – warrant annual review at minimum. Lower-impact systems may reasonably support a two- to three-year interval, provided that classification is justified and documented. Crucially, the classification should trigger review scope, not just frequency. A higher-risk system requires deeper interrogation across more domains.

2. Define review scope against the validated baseline, not against the previous review.

Each periodic review should begin with the system’s current validation documentation – URS, functional specification, configuration baseline, test evidence – and ask a single organizing question: does the system as it operates today match what was validated? Change controls, deviations, and incident records are inputs to that question, not the answer to it. If the documentation cannot confirm the current system state, that gap is itself a finding.

3. Make access control review non-negotiable.

User access drift is one of the most consistently cited findings in regulatory inspections involving computerized systems. Former employees with active accounts, users holding privileges that exceed their current role, shared credentials that circumvent audit trail attribution – these are not edge cases. They are common, and they represent a direct data integrity risk under both 21 CFR Part 11 and Annex 11. Every periodic review must include a structured access rights review conducted against the current organizational structure and role definitions. This is not an IT task delegated to the side; it is a core GxP control.

4. Verify the audit trail – do not just confirm it exists.

Annex 11 requires that audit trails be available, readily comprehensible, and regularly reviewed. The CSA guidance reinforces the use of system-generated evidence – logs, audit trails, digital records – as the primary source of assurance. During periodic review, this means conducting a risk-based sample review of the audit trail for the period under assessment, specifically looking for anomalies: deletions of GxP-relevant records, modifications without documented justification, periods of unexpected inactivity or unusually high activity. A ticked checkbox confirming the audit trail is enabled is not a review of the audit trail.

5. Close the loop on previous findings before generating new ones.

A periodic review that concludes with open CAPAs from the prior cycle, unresolved deviations from interim audits, or outstanding items from the last supplier assessment has not established that the system is in its validated state – it has documented that the system has a backlog of unresolved compliance obligations. Before a periodic review can conclude affirmatively, all prior commitments made in the name of maintaining the validated state must be verified as closed and effective. This is not administrative housekeeping. It is the foundation on which the current review’s conclusions rest.

The Compliance Multiplier

Periodic review done properly does not just protect a single system. It functions as an early warning system for the broader validation program.

A well-executed review of a complex system – an ERP, a LIMS, a manufacturing execution system – will surface configuration drift, documentation gaps, access control weaknesses, and supplier oversight failures before any of those issues reach an inspector. Addressed systematically, they generate targeted CAPAs that strengthen the entire quality framework. Addressed reactively – at inspection – they generate findings that are considerably harder to remediate under scrutiny.

The organizations that consistently perform well in regulatory inspections of computerized systems are, almost without exception, the ones that treat periodic review as a continuous assurance mechanism rather than a compliance deadline. The relationship is not coincidental. Inspection readiness is not a state you achieve in the weeks before an audit. It is the cumulative result of the controls you run every day – and periodic review is one of the most direct levers available to maintain it.

In the next article in this series, we turn to Disaster Recovery and Resiliency – specifically, the gap between having a backup procedure documented and having a recovery capability that can actually be relied upon under GxP conditions. The distinction is more significant than most organizations realize until they need to test it.