Periodic Review of Computerized Systems in Pharmaceuticals
A practical, risk-based guide to confirming that a validated GxP system remains fit for use, secure, reliable, and compliant throughout operation.
What Is a Periodic Review of a Computerized System?
A periodic review is a lifecycle control performed after a computerized system has entered routine operation. It brings together evidence from the period under review to determine whether the system remains suitable for its approved purpose and whether controls continue to protect product quality, patient safety, and trustworthy records.
In pharmaceutical operations, a review may cover an application and its supporting infrastructure, configured workflows, interfaces, user accounts, data repositories, and relevant supplier services. The exact boundary should be clear in the system inventory and review plan. A cloud-hosted application, for example, may need an assessment of the regulated application plus the service responsibilities, integrations, data export, backup, and vendor change notifications that support its GxP use.
A periodic review is not simply a calendar reminder or a re-run of the original validation protocol. It is a structured evaluation of actual use and lifecycle evidence since the last review. It may conclude that the system remains acceptable, identify actions to restore control, or recommend targeted testing or revalidation where the evidence shows that changes or problems could affect intended use.
For the wider lifecycle context, see this guide to Computerized System Validation.
Regulatory Expectations for Periodic Evaluation
EU GMP Annex 11 is the clearest direct reference for this activity. Section 11 says computerized systems should be periodically evaluated to confirm that they remain in a valid state and comply with GMP. It identifies, where appropriate, the current range of functionality, deviation and incident records, problems, upgrade history, performance, reliability, security, and validation-status reports as review inputs. The European Commission currently lists Annex 11 as the January 2011 revision in EudraLex Volume 4. genui{"citation":{"ref":"turn307view0"}}
Annex 11 also connects periodic evaluation to lifecycle risk management, change and configuration control, data storage, audit-trail review, security, business continuity, and archiving. A strong review therefore checks whether the system’s operating controls still work in practice, rather than treating the validation file as a static archive. See the official EudraLex Volume 4 page and the EU GMP Annex 11 text.
In the United States, 21 CFR Part 11 includes controls for systems used to create, modify, maintain, or transmit electronic records within the rule’s scope. For closed systems, section 11.10 addresses validation, accurate and complete copies, record protection and retrieval, authorized access, audit trails, authority checks, training, and system documentation controls. The regulation does not set a single fixed interval for a broad periodic system review. Companies should use their quality system and documented risk assessment to maintain control and determine review timing. genui{"citation":{"ref":"turn306view1"}}
Applicability should be assessed for the records and signatures involved; Part 11 is not a blanket label that automatically applies identically to every software tool. Review the relevant 21 CFR requirements alongside applicable predicate rules and company procedures. Current good manufacturing practices and data-integrity principles provide the broader quality-system context.
What Should a Computerized System Periodic Review Cover?
The review scope should match the system’s GxP impact, architecture, and use. Include the evidence needed to confirm both the validated state and day-to-day control. A review can draw from quality records, IT service records, system-generated logs, training records, vendor evidence, and operational metrics.
System identity and intended use
Confirm the inventory entry, owner, process, GxP functions, interfaces, data types, system boundary, current approved use, and impact classification. Compare actual use with the approved URS and validation baseline.
Validation and configuration status
Check the current system version, configuration, infrastructure dependencies, approved requirements, traceability, test evidence, unresolved qualification items, and whether documentation reflects the production environment. Refer to relevant IQ, OQ, and PQ records.
Changes, incidents, and deviations
Review approved and emergency changes, patches, releases, configuration updates, incidents, problems, deviations, complaints, and related CAPA. Confirm impact assessments, required tests, approvals, and closure evidence.
Data integrity and audit trails
Assess whether audit trails are enabled for relevant records, retained, readable, and reviewed under procedure. Check record attribution, timestamps, metadata, electronic signatures, data exports, and controls for changes or deletions. Use ALCOA+ principles to structure the data-integrity assessment.
Access, security, and training
Review active users, roles, privileged accounts, service accounts, access approvals, leaver removal, periodic access recertification, security events, relevant vulnerabilities, and current role-based training.
Availability, backup, and records retention
Check backup success and restore-test evidence, continuity arrangements, recovery objectives, record readability and retrieval, retention controls, archival access, and planned system end-of-support dates.
For systems hosted or supported by suppliers, review service changes, release notes, support status, subcontractor or hosting changes, agreed responsibilities, relevant assurance evidence, and incident notifications. Supplier evidence can inform the review, but the regulated company remains responsible for assessing whether the evidence is sufficient for its intended use.
How Often Should a Periodic Review Be Performed?
Set the frequency through a documented, risk-based rationale. The chosen interval should allow the organization to detect changes or control failures before they create unacceptable risk. Do not copy one interval across an entire system inventory without considering differences in GxP impact, operating context, and recent performance.
Consider the following when assigning review frequency:
- Potential effect on patient safety, product quality, batch disposition, laboratory decisions, or regulated records.
- System complexity, customization, configuration, interfaces, and dependency on infrastructure or external services.
- Volume and criticality of electronic records, audit-trail activity, and electronic signatures.
- Frequency and significance of upgrades, patches, deviations, incidents, access changes, and supplier changes.
- Security exposure, vulnerability posture, end-of-life status, and effectiveness of existing monitoring.
- Previous review findings, open actions, and the quality of available operational evidence.
A site may use tiered intervals—for example, more frequent reviews for high-impact systems and longer intervals for low-impact systems—if the rationale is documented and remains defensible. Any numerical schedule in an SOP is an internal control, not a universal regulatory interval. Reassess the schedule when the system’s intended use, risk, architecture, or operating history changes.
Periodic review does not replace event-driven assessment. A major release, data-integrity incident, cybersecurity event, migration, new interface, significant configuration change, or change to intended use may require an immediate impact assessment, targeted review, and possibly additional validation before the next scheduled review date.
Periodic Review of Computerized Systems: Step-by-Step Process
- Define the system boundary and review period. Identify the application, infrastructure, interfaces, records, business process, system owner, process owner, and QA reviewer. State the dates covered and intended use being assessed.
- Confirm risk and review plan. Recheck GxP criticality, patient/product/data impact, applicable regulations, planned scope, evidence sources, sampling approach, acceptance criteria, and review frequency.
- Gather controlled evidence. Collect the approved validation baseline, system inventory, change history, incident/deviation log, access list, audit-trail review records, backup and restore evidence, security status, supplier notices, training status, and performance information.
- Reconcile the live system to its documentation. Verify the version and material configuration in production against approved records. Investigate undocumented differences, obsolete diagrams, untracked interfaces, or unsupported components.
- Evaluate changes and quality events. Confirm each relevant change was assessed, authorized, tested at a risk-appropriate level, approved, and documented. Review incidents for recurrence, root cause, product or record impact, and effective corrective actions.
- Assess controls in operation. Sample role assignments, audit trails, electronic records, signatures, backups, restore tests, security events, data transfers, and business-continuity tests according to documented risk.
- Determine continued validated state. Decide whether evidence supports continued use for the approved purpose. Document gaps, limitations, residual risks, and whether additional testing, remediation, restricted use, or revalidation is needed.
- Approve the report and actions. Obtain review by accountable system/process owners and Quality. Assign action owners, due dates, risk priorities, and effectiveness checks; escalate any issue that could affect released product, ongoing operations, or record reliability.
- Feed results into the lifecycle. Update the inventory, risk assessment, validation status, access controls, supplier oversight, training, and next review date. Trend recurring issues across systems and sites.
Use approved SOPs to define roles, evidence retention, review records, escalation, and closure. A consistent review process supports cGMP controls and the documented lifecycle approach described in the site’s validation program.
Periodic Review Checklist for GxP Computerized Systems
Adapt this checklist to the system and risk assessment. “Reviewed” should mean evidence was inspected and a conclusion recorded, not merely that a box was checked.
- System inventory, owner, GxP classification, intended use, and system boundary are current.
- Production version, configuration, infrastructure, interfaces, and data flows match approved documentation.
- URS, functional or configuration specifications, traceability, test evidence, and validation summary remain available and current.
- Changes, upgrades, patches, emergency changes, and deviations have documented impact assessments and appropriate approval/testing.
- Incidents, problems, complaints, data errors, and CAPAs were assessed for recurrence, product impact, and closure effectiveness.
- User access is appropriate to job role; privileged, dormant, shared, emergency, and service accounts are controlled and justified.
- Audit-trail settings, retention, readability, review frequency, and escalation are suitable for relevant GxP records.
- Electronic records, metadata, signatures, timestamps, exports, and copies remain attributable, complete, readable, and retrievable.
- Backup jobs are monitored, restore tests are current, and recovery/continuity arrangements are documented and tested at a risk-based interval.
- Security controls, vulnerability assessments, patch decisions, incident handling, and end-of-support risks have been evaluated.
- Supplier/service-provider status, service changes, agreements, support coverage, and relevant assurance evidence have been reviewed.
- Required user, administrator, and support training is current and responsibilities remain assigned.
- Open actions are risk-ranked, assigned, tracked, and escalated; no unresolved issue invalidates the basis for continued use.
- The review conclusion, approvers, evidence references, limitations, and next review date are recorded.
Periodic Review Report: Contents and Acceptance Criteria
The report should make the decision understandable to a qualified reviewer who was not part of the review. Cite records, dates, versions, samples, and data sources. Summarize exceptions and explain their significance instead of listing findings without impact assessment.
| Report section | What to document |
|---|---|
| System and review context | System name/ID, process, owner, GxP impact, intended use, boundary, review period, and applicable sites or environments. |
| Risk-based plan | Review scope, rationale for depth and frequency, sampling method, acceptance criteria, reviewers, and evidence sources. |
| Evidence and results | Validation status, system/configuration baseline, changes, incidents, users, audit trails, security, supplier activity, backup/recovery, training, and performance. |
| Findings and impact | Facts observed, affected functions or records, patient/product/data-integrity assessment, immediate controls, and risk rating with rationale. |
| Conclusion and actions | Continued-use decision, restrictions if any, required remediation or testing, action owner/due date, QA approval, and next review date. |
Example acceptance criteria
Acceptance criteria should be approved before review and tailored to system risk. A typical conclusion may require that the approved intended use and system configuration are known; changes and incidents are controlled and assessed; access and data-integrity controls operate as intended; records remain accessible and readable for their required retention period; backup and recovery evidence is satisfactory; and no unresolved critical issue undermines the validated state.
Where gaps exist, the report should state whether continued operation is acceptable, whether temporary controls or restrictions are needed, and which actions must be completed before normal use can continue. Acceptance is not justified by a “no issues found” statement alone; the evidence reviewed must support the conclusion.
Periodic Review vs. Revalidation, Change Control, and Audit
| Activity | Main question | Typical output |
|---|---|---|
| Periodic review | Does the system remain in a controlled, validated state for its approved use? | Review report, continued-use decision, actions, revised risk or review date. |
| Revalidation or targeted regression testing | Did a change or issue affect validated functions, requirements, or controls? | Impact assessment, updated tests and evidence, approved validation conclusion. |
| Change control | Can a proposed change be made safely and under control? | Approved change plan, impact assessment, implementation and verification records. |
| Quality or supplier audit | Are the quality-system processes or supplier controls adequate and followed? | Audit evidence, observations/findings, and corrective actions. |
A periodic review can identify the need for revalidation, but it does not automatically replace change control or testing. Revalidation should be based on an impact assessment of actual changes, risk, and the system’s validated requirements. Qualification records such as DQ, IQ, OQ, and PQ can support the lifecycle evidence where relevant.
Common Periodic Review Gaps to Avoid
Using a universal annual checklist
Applying the same depth and frequency to every application can ignore material differences in risk. Document why the interval and scope fit each system or defensible system group.
Reviewing documents but not actual use
Compare the approved baseline with live versions, settings, access, interfaces, and operational records. A tidy validation folder cannot prove the production system remains controlled.
Leaving out supplier and cloud changes
Capture vendor releases, hosted-service changes, outages, security notices, subcontractor changes, and responsibilities for the customer-versus-provider boundary.
Ignoring audit trails and metadata
Review whether records can be reconstructed and interpreted, not only whether the application opens. Check the audit-trail process and its evidence.
Calling every review “revalidation”
Periodic evaluation, change control, and risk-based testing are related but distinct. Define each activity and use targeted revalidation when warranted.
Closing the report with actions still unmanaged
Assign owners, deadlines, risk-based escalation, and effectiveness checks. Link significant issues to the quality system and CAPA process.
How Periodic Review Supports the Computerized-System Lifecycle
Periodic evaluation is most effective when it is part of the full system lifecycle—from requirements and design through operation, maintenance, and retirement. It can reveal when the approved purpose has drifted, when infrastructure is approaching end of support, or when operational evidence no longer supports the assumptions made during initial validation.
Keep review documents consistent with the system’s approved requirements, risk assessment, change records, and validation evidence. If the review identifies a data-integrity concern, assess affected records and decisions promptly, preserve evidence, and follow the site’s deviation and escalation procedures. For related reading, explore the guides to ALCOA+ data integrity, CAPA in pharmaceuticals, and 21 CFR regulations.
Frequently Asked Questions
What is a periodic review of a computerized system?
It is a documented evaluation of a GxP computerized system during operation to confirm that it remains fit for its approved use, in a validated state, and under effective quality, security, and data-integrity controls.
Does EU GMP Annex 11 require periodic review?
Yes. Annex 11 section 11 says computerized systems should be periodically evaluated to confirm that they remain in a valid state and comply with GMP. It lists relevant review inputs, including functionality, deviations, incidents, upgrades, performance, reliability, security, and validation status.
How often should a GxP computerized system be reviewed?
There is no single universal interval for every system. Establish a documented, risk-based frequency in the quality system and reassess it when system criticality, intended use, architecture, supplier status, or operating history changes.
Is an annual periodic review mandatory?
EU GMP Annex 11 and 21 CFR Part 11 do not prescribe one blanket annual interval for all computerized systems. A company may adopt annual review for defined systems, but should justify the interval and scope based on risk.
Is periodic review the same as revalidation?
No. Periodic review evaluates the continuing state of control. Revalidation or targeted regression testing is performed when an impact assessment shows that a change, incident, or other event could affect validated functions or controls.
Which systems should be included in a periodic review program?
Include computerized systems with GxP functions or that create, modify, maintain, transmit, or retain GxP records, based on a documented applicability and risk assessment. The system inventory should explain the boundary and impact classification.
What evidence should be reviewed?
Typical evidence includes the current validation baseline, changes and upgrades, incidents and deviations, user access, audit-trail controls, data retention and retrieval, backup and restore tests, security status, supplier changes, training, and performance records.
Can periodic review be combined with another quality review?
It can be coordinated with other quality-system activities if the computerized-system-specific scope, evidence, risk decisions, conclusions, and approvals remain explicit and traceable.
What happens if the review finds a critical gap?
Assess immediate product, patient, process, and record impact; protect relevant evidence; apply restrictions or compensating controls as needed; document a deviation; and initiate corrective action. Determine whether additional testing, revalidation, or suspension of use is necessary.
How should cloud or SaaS systems be reviewed?
Review the regulated application and its service boundary, including provider releases, service changes, data access and export, integrations, backup and recovery responsibilities, security notifications, support status, and evidence supplied under the quality agreement or service agreement.
Official References and Further Reading
- European Commission, EudraLex Volume 4, Annex 11: Computerised Systems.
- European Commission, EudraLex Volume 4 index.
- Electronic Code of Federal Regulations, 21 CFR Part 11.
- Computerized System Validation in Pharmaceuticals — related internal guide.
This article is educational guidance, not a substitute for applicable regulations, current agency guidance, a site-specific risk assessment, or approved quality procedures. Confirm requirements for the system, records, jurisdiction, and intended use with your Quality and Regulatory teams.
Key Takeaway
A defensible periodic review shows, with current evidence, that a computerized system still performs its approved GxP role and that changes, records, access, security, suppliers, and recovery controls remain governed. Base its frequency and depth on documented risk, act on important findings promptly, and retain a clear Quality-approved report.
.webp)
