SOP: Periodic Review of GxP Computerized Systems

This is a ready-to-use SOP. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, and route it through your normal document control, review, and approval. A worked filled specimen follows the template so you can see how a completed version reads. Verify each cited regulation against the current source before you rely on it. This template is an educational reference for you to adapt to your own quality system, products, and regulatory context; it is not legal, regulatory, or professional advice. This procedure governs how the review is run. The output it produces is the periodic review report, and a ready-made report template is available at Periodic Review Report (Validated System). The evidence-gathering worksheet used to run the review before the report is written is at Periodic Review Evidence Collection Form.

Document control header

1. Purpose

This procedure defines how <<FILL: COMPANY NAME>> periodically re-confirms that computerized systems used for GxP purposes remain in a validated state, remain fit for their intended use, and continue to protect the integrity of the records they hold. Validation is a conclusion reached on one date about one configuration. Systems are then patched, re-configured, integrated, migrated, and operated by new people running changed processes. This procedure is the recurring control that tests whether that original conclusion still holds, and defines what happens when it does not.

2. Scope

This procedure applies to every computerized system recorded as GxP in the system inventory maintained under <<FILL: SOP-ID or register reference for the system inventory>>, at the sites listed in the header. It covers applications, their configuration, the interfaces between them, the qualified infrastructure they run on, and hosted or supplier-operated systems where <<FILL: COMPANY NAME>> relies on the system for a GxP purpose.

This procedure does not re-execute qualification or validation testing. Where a review finds that the validated state is in question, it raises and routes the remediation or re-validation rather than performing it. Re-validation is planned and executed under <<FILL: SOP-ID for change control / validation>>. Audit trail review is a separate, more frequent control performed under <<FILL: SOP-ID for audit trail review>>; this procedure checks that it happened, it does not replace it. Periodic review of manufacturing equipment and utilities is governed by <<FILL: SOP-ID for equipment requalification and periodic review>>.

3. Responsibilities

The performing role and the approving role are always different people. The System Owner performs; QA approves. Where a System Owner sits within the quality function, the approving QA reviewer must be someone with no operational responsibility for the system.

4. Definitions

• Periodic review: the scheduled, documented re-assessment of an operational validated system, which gathers operational evidence accumulated since the last review and concludes whether the system remains in a validated state. It is an assessment, not a re-test.
• Validated state: the condition in which a system, as currently configured and operated, is still covered by current approved specifications, testing, and documentation, and still performs its intended GxP function.
• Validated baseline: the approved configuration, version, and specification set that the current validation documentation describes, against which the live system is reconciled.
• Review period: the interval from the end date of the previous review period (or from validation release for a first review) to the cut-off date of the current review. Periods must be continuous, with no gap between consecutive reviews.
• Review interval: the maximum time permitted between reviews for a given risk tier. It is a ceiling, not a target date.
• Event-driven pull-forward: bringing a review forward from its scheduled date because an event has made the validated state doubtful before the interval has expired.
• Re-validation: planned re-execution of some or all validation activity, triggered by a change or a finding, and governed by change control, not by this procedure.

5. Procedure

5.1 Schedule and trigger the review from the inventory

1. The system inventory is the single source of the review schedule. Every GxP system entry carries a risk tier, a date of last review, and a next-review-due date. A system with no next-review-due date is a finding against the inventory, not a reason to skip the review.
2. The Inventory Owner issues a due notification to the System Owner and QA at least <<FILL: lead time, e.g. 8 weeks for high tier, 4 weeks for medium and low>> before the due date. Lead time exists because evidence has to be requested from other functions and they need time to produce it.
3. The System Owner opens the review as a controlled record with a unique identifier, a named owner, the review period, and a target completion date on or before the due date.
4. In addition to the scheduled trigger, any of the following pulls a review forward regardless of the calendar. The System Owner or QA may invoke a pull-forward, and the reason is recorded on the review record.

5.2 Set review depth and interval by risk tier

1. The interval and the depth both come from the risk tier recorded in the inventory. The tier is set from data criticality, GxP impact, complexity or GAMP category, and change rate, using the risk methodology in <<FILL: SOP-ID or VMP reference for risk classification>>.
2. Apply the default scheme below unless a documented, approved rationale sets something different for a named system. Every tier rationale is written and approved once in the Validation Master Plan; it is not re-argued at each review.

3. The interval is a maximum. Completing a review earlier than the due date is acceptable and resets the clock from the actual completion date. Completing it later is an overdue review and is handled under section 5.11.
4. Depth is set at the start of the review and recorded on the review record. If evidence collected during the review shows the system is less stable than its tier assumed, the System Owner increases the depth for that review and raises the tier reassessment as an action.

5.3 Define the period and the baseline

1. Set the review period start date to the end date of the previous review period, or to the date of validation release for a first review. Consecutive periods must be continuous. A gap between periods means a window of operation that no review ever examined, and it is a finding.
2. Record the system identity being reviewed: name, unique inventory ID, current application version, and the environment or environments in scope.
3. Retrieve the reference documents the review assesses against: the latest validation summary report, the approved configuration specification or validated baseline record, the requirements specification, and the previous periodic review report with its open actions.

5.4 Collect the evidence set

1. Request the evidence below from the owning function, in writing, using the evidence collection form. Record the date requested and the date received for each item, so that a missing input is visible as a gap rather than as silence.
2. Insist on the actual records. A verbal assurance from a system administrator that backups are fine is not evidence and is not recorded as such.

3. Where an input genuinely does not apply, record “not applicable” with the reason. Where an input applies but was not provided, record it as not received and treat it as a finding under section 5.5, not as an empty row.

5.5 Assess each input

1. Assess each input against one of three outcomes, and record the outcome with the record reference that supports it.

2. Reconcile the live configuration to the validated baseline for every GxP-relevant setting: calculations, specification limits, workflow and approval routing, electronic signature behavior, audit trail settings, user roles and privileges, and interface mappings. Any difference is either an authorized change traceable to a change record, or it is a non-conformance. There is no third category.
3. Cross-check the change log against the patch history and the live configuration in both directions. A change present in the log but not on the system, and a change present on the system but not in the log, are both findings.
4. Look for patterns across inputs rather than only within them. Three separate deviations closed individually, all naming the same interface, are one unresolved root cause and are recorded as such.
5. Confirm every action from the previous periodic review is closed, and that closure was effective. Actions silently dropped between cycles are a non-conformance against this procedure.

5.6 Reach one of the three permitted conclusions

1. Roll the input assessments into exactly one conclusion. Only the three below are permitted.

2. The conclusion must be supported by the body of the review. A conclusion of “remains in a validated state” recorded alongside an open undocumented change is a self-inflicted finding: it documents that the control ran and failed to detect a problem that was in front of it.
3. Do not soften a conclusion to avoid raising an action. A defensible “validated with actions” survives inspection. An unsupported “fully validated” does not survive the moment an inspector pulls the underlying evidence.
4. An incomplete evidence set is not a reason to conclude favorably. If inputs were requested and never received, the review cannot conclude that the state is confirmed, because the evidence that would confirm it was never examined.

5.7 Escalate when the validated state is not confirmed

1. The System Owner notifies QA and the Validation Lead within <<FILL: e.g. 1 working day>> of reaching this conclusion. Do not wait for the report to be finalized.
2. QA assesses, with the System Owner and Validation Lead, whether GxP records already produced by the system in the review period may be affected. Where they may be, a data integrity investigation is opened under <<FILL: SOP-ID for data integrity investigation>> and the potential product impact is assessed under <<FILL: SOP-ID for deviation management>>.
3. QA determines whether the system may continue in GxP use, and on what basis. The options are:

4. The Validation Lead determines whether remediation, targeted re-validation, or full re-validation is required, and raises it through change control. The periodic review does not perform re-validation; it establishes the need and hands it over.
5. Escalate to <<FILL: management forum, e.g. the Quality Council or Management Review>> where the conclusion affects product already released, where suspension of use is required, or where the same system reaches this conclusion in two consecutive reviews.

5.8 Raise CAPA and actions

1. Every non-conformance is raised as a CAPA under <<FILL: SOP-ID for CAPA management>>. Every “compliant with action” item is raised either as a CAPA or as a tracked action, per the thresholds in that procedure.
2. Every action carries a description, a named owner, a due date, and a reference to the record that tracks it. An action without an owner and a date is not an action.
3. Actions arising from a change to the system are raised through change control rather than CAPA, so that validation impact is assessed in the right place.
4. The review report records the action list and its status at the time of issue. The report tracks; it does not replace the CAPA system, and closure is recorded in the CAPA system.

5.9 QA review and approval

1. The System Owner completes the periodic review report, attaches or references every piece of evidence, signs, and submits it to QA within <<FILL: e.g. 10 working days>> of the period cut-off date.
2. QA independently reviews the evidence, not just the summary. QA checks at minimum that:
   • the review period is continuous with the previous period;
   • every input in section 5.4 was addressed, with a record reference or a documented rationale for non-applicability;
   • the configuration reconciliation was actually performed and its result stated;
   • a restore was verified, rather than backups merely reported as running;
   • the audit trail review evidence is named, rather than data integrity being asserted;
   • the conclusion is consistent with the input assessments;
   • prior-review actions are confirmed closed and effective;
   • every action has an owner and a due date.
3. QA either approves, or returns the review with the specific evidence gap that blocks approval. QA may change the conclusion where the evidence does not support what was drafted, and records the reason for the change.
4. QA approves within <<FILL: e.g. 10 working days>> of receipt. A review is not complete until QA has approved it.

5.10 Update the inventory and set the next review

1. On QA approval, the Inventory Owner records against the system entry: the review record identifier, the completion date, the conclusion, and the next-review-due date.
2. Set the next due date from the actual completion date plus the tier interval, unless the review concluded that the tier itself should change, in which case the tier is updated first and the interval follows the new tier.
3. Where the conclusion was “validated state not confirmed”, set the next review date to <<FILL: e.g. 6 months>> regardless of tier, and do not restore the standard interval until one review closes with no non-conformance.
4. Retain the review record and its evidence per the records retention schedule, for not less than <<FILL: retention period>>.

5.11 Handle overdue reviews

1. The Inventory Owner reports reviews approaching due and past due to <<FILL: forum, e.g. the monthly quality systems review>> at least monthly. Overdue reviews are visible by default, not on request.
2. A review is overdue the day after its due date. The System Owner records on the review record why it is late, the recovery date, and the interim assessment of whether anything known about the system suggests the validated state is at risk.
3. An overdue review beyond <<FILL: e.g. 30 days>> is raised as a deviation under <<FILL: SOP-ID for deviation management>> and escalated to <<FILL: role, e.g. the Head of Quality>>.
4. An overdue period is never skipped or shortened to catch up. The next review still covers the full window back to the end of the previous period, so that no operating time goes unexamined. The due date moves; the coverage does not.
5. Where a system is overdue and is also high tier, QA assesses whether continued GxP use requires interim controls until the review is completed.

5.12 Scale the review across a large system estate

Where the inventory holds more systems than can be reviewed individually at full depth, use the three mechanisms below. All three are permitted; none of them removes the requirement that every GxP system is reviewed and reaches a conclusion within its interval.

1. Tiered depth. Apply the depth set in section 5.2. Most of the effort belongs on the high-tier systems that own release-relevant records. A low-tier system with no changes, no incidents, and no access movement in the period can reach a supported conclusion from summary evidence, provided the absence of activity is evidenced from the source records rather than assumed.

2. Grouping of like systems. Systems may be reviewed as a group where all of the following hold, and the grouping rationale is written and approved by QA before the review:

   • the systems share the same platform, the same supplier and version family, the same hosting model, and the same administration team;
   • they carry the same risk tier;
   • they are subject to the same change control, backup, access management, and monitoring processes. Typical valid groups: a fleet of identical instrument data stations of the same model and software version; a set of environmental monitoring loggers of one type; several instances of the same configured product deployed per site under one administration model. Systems that share only a vendor, or only a general purpose, are not a valid group.

3. Sampling within a group. Within an approved group, common controls (backup, restore, patching, access administration, business continuity, supplier status) may be assessed once at group level. System-specific evidence (changes, deviations, configuration reconciliation, audit trail review, intended use) is then examined on a sample of group members, subject to all of the following:

   • the sample size and selection basis are written into the review record before evidence is collected, not chosen after seeing the results;
   • the sample covers at least <<FILL: e.g. 20 percent of the group or 3 members, whichever is greater>>, and every group member is sampled at least once across <<FILL: e.g. 3>> consecutive review cycles;
   • selection is not limited to the members expected to be clean; include any member with change or incident activity in the period;
   • any non-conformance found in a sampled member ends the sampling for that cycle. The finding is treated as potentially applying to the whole group, and every member is then examined for the same defect before the review concludes.
   • the group review report names every member system and records the conclusion for each, so that each system’s inventory entry can be updated individually.

Grouping and sampling reduce duplicated effort on genuinely identical systems. They are not a mechanism for reviewing a diverse estate cheaply, and a group assembled for convenience rather than technical similarity will not hold up when an inspector asks why two systems with different configurations were reviewed as one.

6. Acceptance criteria

A periodic review is acceptable when all of the following are true.

• The review was completed within the interval set by the system’s risk tier, or the overdue handling in section 5.11 was followed and documented.
• The review period is continuous with the previous period, with no unexamined gap.
• Every applicable input in section 5.4 was examined, with the supporting record cited by reference, and any non-applicable input carries a documented rationale.
• The live configuration was reconciled to the validated baseline for GxP-relevant settings, and the result is stated.
• A restore was actually verified during the period, and the record is cited; backup completion logs alone do not satisfy this.
• Audit trail review records for the period are named and confirmed, rather than data integrity being asserted without evidence.
• Each input carries an assessment of compliant, compliant with action, or non-conformance.
• The conclusion is one of the three permitted conclusions and is consistent with the input assessments.
• Every action has a named owner, a due date, and a tracking reference, and prior-review actions are confirmed closed and effective.
• Where the validated state was not confirmed, escalation, interim controls, and the re-validation or remediation route are documented.
• QA reviewed the evidence and approved, and the inventory was updated with the completion date, conclusion, and next-due date.
• Where grouping or sampling was used, the rationale, sample size, and selection basis were approved before evidence collection, and every member system has a recorded conclusion.

7. References

21 CFR Part 11 (electronic records and electronic signatures). 21 CFR 211.68 (automatic, mechanical, and electronic equipment), 211.180 (general records requirements), 211.194 (laboratory records). 21 CFR Part 4, Regulation of Combination Products, for combination-product systems in scope. The phrase “current good manufacturing practice requirements for combination products” is the title of Subpart A of that Part, not of Part 4 as a whole, and Subpart A is the portion that carries the manufacturing practice requirements relied on here. EU GMP Annex 11, Computerised Systems. Section 11 is the periodic evaluation clause, which expects computerised systems to be periodically evaluated to confirm they remain in a valid state and compliant with GMP, considering matters such as the current range of functionality, deviation records, incidents, problems, upgrade history, performance, reliability, security, and validation status reports. EU GMP Annex 15, Qualification and Validation, for the planned approach to validation and for change and re-qualification expectations. ICH Q9(R1), Quality Risk Management. The guideline’s general proportionality thinking, that the rigour applied should track the risk carried, is what the tiered interval and depth scheme in this procedure builds on. The scheme itself is ours; read the guideline directly for its own treatment. ISPE GAMP 5, Second Edition (2022), A Risk-Based Approach to Compliant GxP Computerized Systems, which treats periodic review as an operational-phase activity of the system life cycle. FDA, Computer Software Assurance for Production and Quality Management System Software, current version issued 3 February 2026, superseding the final guidance issued 24 September 2025 (titled Computer Software Assurance for Production and Quality System Software), which was preceded by the draft issued 13 September 2022. MHRA, ‘GxP’ Data Integrity Guidance and Definitions (2018), for the expectation that ongoing suitability and control of data-generating systems is maintained rather than assumed. PIC/S PI 041-1, Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments.

Confirm the current version and clause numbers of each reference before issue.

8. Records generated

9. Revision history

10. Approvals

Filled specimen

The following shows the review record header and the assessment summary completed for an example manufacturing execution system, so you can see the level of detail an inspector expects. The company, system, and numbers are illustrative; replace them with your own.

Conclusion recorded: the validated state is not confirmed. The undocumented signature timeout change is a GxP-relevant configuration difference with no change record, which means change control did not operate for this system for at least one change in the period.

Escalation and actions taken. QA and the Validation Lead notified 08 June 2026, one working day after the finding. A data integrity investigation (DII-2026-011) assessed whether the extended timeout allowed a batch record signature to be applied outside the intended attended window; 412 signatures in the affected window were examined and none showed a signature applied after operator session abandonment, so no batch impact was identified. QA permitted continued use with interim controls: the setting was reverted under emergency change EC-2026-017 on 09 June 2026, and daily configuration monitoring was applied to the signature settings until the CAPA closes. CAPA-2026-044 addresses the administrative access path that allowed the setting to be changed outside change control. Targeted re-validation of the signature timeout function was raised through change control and completed 27 June 2026. Next review set to 31 December 2026, six months rather than twelve, and the standard interval will not be restored until one review closes with no non-conformance.

In this example the reviewer reconciled the live configuration rather than accepting the change log at face value, found a change that change control had missed, escalated the same week instead of finishing the paperwork first, established the record impact with a counted examination rather than an assumption, and recorded a conclusion that was uncomfortable but supported. That sequence, evidence to honest conclusion to escalation to tracked remediation, is exactly what a reviewer is expected to demonstrate.

Common inspection findings this SOP prevents

• Periodic review is required by procedure, but reviews are months or years overdue and nobody is reporting the backlog.
• A review period starts after the previous one ended, leaving a window of operation no review ever examined.
• The review asserts the system “remains validated” with no evidence cited: no change list, no configuration reconciliation, no access reconciliation, no restore record.
• A change present on the live system is absent from the change log, and the review never compared the two so never found it.
• Backups are reported as running and the review stops there, so recoverability was assumed and never proven.
• The review claims data integrity is intact but never states whether the audit trail review actually happened during the period.
• The conclusion is “validated” while open deviations, undocumented changes, or unresolved prior actions sit in the same period, which documents that the control failed to detect a known problem.
• The review is signed only by the system owner, with no independent QA approval of the conclusion.
• Actions from the previous review were silently dropped and never carried forward.
• Review intervals exist but no written rationale ties them to criticality, so a three-year interval on a release-critical system cannot be defended.
• A “grouped” review covers systems that share only a vendor, with no technical basis for treating them as one, and no per-system conclusion recorded.
• Sampling within a group was chosen after the evidence was seen, or the same convenient members were sampled every cycle while others were never examined.

How to adapt this SOP

1. Set your document number, owner, effective date, and site scope in the header.
2. Replace the tier definitions and intervals in section 5.2 with the scheme your Validation Master Plan already commits to, and make sure the per-tier rationale exists there in writing. If the VMP does not define one, fix that first; this SOP inherits the scheme, it should not invent it.
3. Point every cross-reference to your real procedures: system inventory, change control, deviation, CAPA, data integrity investigation, audit trail review, business continuity, and equipment periodic review.
4. Set the lead time, submission time, and QA approval time in sections 5.1, 5.9, and 5.11 to intervals your organization can actually meet. A 5-day approval target that is missed every cycle is worse than a 15-day target that is met.
5. Adjust the evidence table in section 5.4 to name the actual systems of record your evidence comes from, so the reviewer requests from a named source rather than hunting.
6. Decide whether grouping and sampling under section 5.12 apply to your estate at all. A site with 30 systems usually does not need them. A network with 800 instrument data stations does, and the grouping rationale is worth writing carefully before the first grouped review rather than defending it afterwards.
7. Confirm every regulation in section 7 against the current published version before issue, and check that the referenced FDA guidance version and date still match what is current at the time you issue.