System Periodic Review

What system periodic review is

System periodic review is the scheduled, documented re-evaluation of a computerised GxP system to confirm it remains validated, secure, compliant, and fit for its intended use. It's the lifecycle control that catches validation drift, access drift, and accumulated configuration changes before they surface as inspection findings.

The principle behind periodic review is straightforward: validation isn't a one-time event. A system that passed IQ / OQ / PQ three years ago, then accumulated patches, configuration changes, role assignments, integrations, and users coming and going, isn't automatically still in the same validated state. The original validation evidence describes a snapshot. Periodic review confirms the snapshot still matches reality.

EU GMP Annex 11 §11 is the most direct regulatory statement. GAMP 5 (Second Edition, 2022) treats periodic review as part of the operational phase of the system lifecycle. Modern data integrity guidance (MHRA March 2018 updated September 2021, PIC/S PI 041-1) treats periodic review as a data integrity control alongside audit trail review and access review.

Why periodic review increasingly drives inspection conversations

Inspectors look at periodic review records for a specific signal: does the firm actively manage its computerised systems through their lifecycle, or did validation end at go-live and nobody has looked since? Programs with thoughtful periodic review records — defined scope, documented evidence, real findings, traceable follow-up — answer the first question. Programs without can't answer at all.

FDA's chromatography enforcement actions from 2017 onward produced findings where validation was technically complete at go-live but the system had drifted significantly by the time of inspection. Patches had been applied without re-validation. Roles had been added without SoD re-evaluation. Audit trail review programs had stopped running. The inspector traced the drift through change logs and missing periodic-review records.

For SaaS systems specifically, the conversation has shifted. Older arguments that "the vendor validated the platform" don't satisfy current inspectors — the customer-side validation responsibility (URS, configuration, intended use, training) requires its own periodic review regardless of who owns the underlying infrastructure.

Inspector perspective: inspectors typically ask for periodic review records early. If they don't exist, the validation conversation is essentially over and a finding for missing lifecycle control follows, regardless of how good the original validation was. If they exist, inspectors look for evidence that the reviews actually examined something — change logs reviewed, access reviewed, deviations correlated, audit trail review confirmed running. Tick-the-box reviews concluding \"system OK\" with no underlying analysis are themselves a finding.

Where system periodic review obligations come from

The obligation is explicit in some frameworks and implicit in others:

• EU GMP Annex 11 §11 — Periodic Evaluation: "Computerised systems should be periodically evaluated to confirm that they remain in a valid state and are compliant with GMP. Such evaluations should include, where appropriate, the current range of functionality, deviation records, incidents, problems, upgrade history, performance, reliability, security and validation status reports." The most direct regulatory statement on the topic.
• 21 CFR Part 11 §11.10(a): validation requirement that periodic review re-confirms. The validation isn't a single event; it's a state to be maintained.
• 21 CFR §211.68(b): drug manufacturing computerised systems must produce data per established requirements with controls preventing unauthorised changes. Periodic review is the operational form of "maintained".
• 21 CFR §211.180(e): quality unit responsibility for evaluation; periodic review evidence is one of the records the unit reviews.
• 21 CFR §820.70(i): medical device automated processes must be validated; periodic re-evaluation is implicit in the maintenance requirement.
• FDA Guidance: Computer Software Assurance (Draft September 2022, Final September 13, 2024): risk-based validation approach explicitly includes ongoing risk management, of which periodic review is a key element.
• GAMP 5 (Second Edition, 2022): treats periodic review as part of the operational phase; provides risk-based frequency guidance per system category (Category 3 / 4 / 5).
• MHRA "GxP" Data Integrity Definitions and Guidance for Industry (March 2018, updated September 2021): periodic review as a data integrity control; references the connection between validated state and DI assurance.
• PIC/S PI 041-1 (July 2021): data lifecycle and DI controls require ongoing review of the systems supporting them.
• PIC/S PE 009-17 (June 2023): the current PIC/S GMP Guide; supports the periodic-review framing for computerised systems.
• ICH Q10 §3.2.3: change management system implicitly requires the evaluation periodic review provides.
• ISO 13485 §4.1.6: validation of software used in QMS; implicit ongoing maintenance.
• ISO 27001 A.18.2: information security review; alignment for systems with security implications.

What a working periodic review program contains

A defensible periodic review program contains these elements:

• Risk-based frequency, documented per system. High-risk GxP systems (LIMS, MES, eQMS, ERP, batch release) typically annual. Lower-risk systems on longer cycles. The frequency and justification per system documented in a controlled SOP or schedule.
• Defined scope per review. The review template specifies what gets evaluated: validation status, change history, deviations, audit trail effectiveness, access controls, backup and recovery, security, performance, vendor updates. Without a defined scope, reviews drift to whatever is easy.
• Inputs gathered before the meeting. Change log, deviation log, access review records, audit trail review records, security patches applied, supplier change notifications, performance metrics — all assembled in advance. The review session evaluates the data; it doesn't gather it.
• Documented evaluation, not a checklist. For each scope area, the review records what was examined, what was found, and the conclusion. "OK" with no underlying analysis isn't documentation; it's the absence of evidence.
• Findings drive follow-up. Any drift, deficiency, or risk identified routes into change control, CAPA, or revalidation as appropriate. Findings without follow-up are themselves a finding.
• Continued-validation conclusion. The review concludes with an explicit statement on continued validated state: maintained, requires action, or requires revalidation. Signed off by the system owner with QA concurrence.
• Cross-reference to other review programs. Periodic review pulls from audit trail review (is the audit trail review program running?), access review (RBAC current?), and CAPA / deviation history (anything system-related?). These programs reinforce each other; periodic review without the underlying reviews is incomplete.
• Management Review input. System periodic review outputs feed Management Review: system inventory health, overdue reviews, recurring drift patterns, revalidation triggers.
• Aged-or-overdue tracking. Reviews approaching due dates flagged; overdue reviews escalated. Programs that let reviews slip can't claim periodic discipline.
• Validation package alignment. The system's URS, IQ/OQ/PQ evidence, and traceability matrix are referenced; the review confirms current operation against the original validation baseline.

What strong periodic review programs do

The patterns that hold up at inspection:

• System inventory current. The list of GxP systems requiring periodic review is maintained, with risk classification, frequency, and next-review-due date per system.
• Risk classification per GAMP 5. Category 3 (standard infrastructure / commercial off-the-shelf), Category 4 (configured commercial), Category 5 (custom) — different periodic review depth.
• Review template defined. Controlled document covering required scope areas, evidence sources, and conclusion structure.
• Inputs assembled in advance. Change log, deviation log, access review, audit trail review status, security patches, performance metrics. Pre-meeting prep is documented.
• Real evaluation, not tick-box. Each scope area shows what was examined and what was concluded with evidence.
• Findings closed. Every finding has owner, due date, and traceable closure through change control, CAPA, or revalidation.
• Continued-validation conclusion explicit. Signed; QA concurrence captured.
• Cross-review pulls. Audit trail review status, access review status, deviation history all referenced.
• Management Review input. System health metrics standing input to MR.
• Overdue tracking. Aging reviews escalate; programs don't let reviews slip silently.
• Validation alignment. URS / IQ-OQ-PQ / traceability matrix referenced against current operation.
• SaaS aware. Vendor-side validation evidence considered; customer-side scope explicit.

How Complere supports system periodic review

System periodic review is your lifecycle discipline. Your team decides what the review covers, who signs it off, and what the conclusion means. What Complere gives you is the evidence base the reviewer actually needs, ready in a form they can use rather than reconstruct.

Every change made to the system carries its full history — what changed, who approved it, what the impact assessment said, whether the effectiveness review confirmed the outcome. Every deviation, incident, or quality event involving the system lives on the same record, with the investigation evidence attached. When your reviewer sits down to evaluate continued validated state, the change log, the deviation log, the access reviews, and the audit trail review records are all there — and so is the original validation evidence the review compares against.

When the review concludes, the conclusion itself lives as a controlled document: a periodic review report, template-driven, approved through the same workflow your other quality records use, with the signature carrying its full meaning. If the conclusion identifies drift that needs action, the finding routes straight into change control or a CAPA — with a link back to the originating review, so the closure trail stays intact when an inspector asks "what did you do about this?".

The platform also ships with its own validation pack — VMP, URS, IQ/OQ/PQ evidence — that gives you the baseline your customer-side periodic review compares against. So when an inspector asks about the SaaS argument, you have the vendor-side evidence in hand and the customer-side review built on it.

What stays with your team: the system inventory and risk classification, the periodic review schedule per system, the review template scope, the actual review work, and the discipline of acting on findings rather than just filing them. Complere supports the program; you run it.

Related validation and lifecycle terms

System periodic review sits in the validation and lifecycle cluster:

• Periodic Review — the umbrella discipline; system periodic review is its application to validated systems
• Validation — the original state periodic review re-confirms
• Change Control — change history is a principal input; findings often route back to change control
• 21 CFR Part 11 — §11.10(a) validation requirement; periodic review is the maintenance form
• Audit Trail Review — confirmed running as part of periodic review
• User Access Review — confirmed running as part of periodic review
• RBAC — RBAC currency checked
• Data Integrity — system integrity is a periodic review output
• Management Review — system health metrics are MR inputs