Periodic Review (Computerized Systems)

Systems drift: changes accumulate, users come and go, suppliers update software and business use evolves. A periodic review asks whether the validated state still holds.

Annex 11 section 11 says computerised systems should be periodically evaluated to confirm they remain valid and compliant.

Typical inputs include changes since the last review, incidents and deviations, open CAPA, audit trail review findings, user access and privileges, backup and restore tests, security patches, supplier status, SOP currency, training and intended use.

Each input should lead to a conclusion, not just a list.

Frequency is risk-based: high-impact systems such as batch record or LIMS systems may be reviewed annually; lower-impact systems less often. Significant events can trigger an earlier review.

Document the rationale for each system's frequency.

Confirm that user accounts match current staff and roles, privileged access is limited and reviewed, and generic accounts are not used for GxP actions.

Access reviews often find leavers with active accounts.

Check that audit trails are enabled, reviewed per procedure and retained. Confirm backups run and restores have been tested.

Data archiving and retrieval for retained records should work in practice.

Review supplier changes, release notes, support status and any audit findings. Cloud services may update frequently; confirm how updates are assessed.

Unsupported software versions are a risk to plan for.

A review concludes that the system remains validated, that actions are needed, or that revalidation or retirement is required. Actions go into CAPA or change control.

Approve the review report and track actions to closure.

Pitfalls include template reviews that tick boxes without evidence, missing reviews for spreadsheets and small systems, and actions that never close.

Reviewers should be independent enough to challenge the system owner.

V5 keeps audit trails, user and role records, change history and document versions, which can supply evidence for a customer's periodic review. Enterprise customers receive IQ/OQ support.

The customer performs the periodic review and owns validation, PQ and conclusions; V5 does not declare a system validated.

List your GxP systems with last review date and risk rating. Start with any high-risk system overdue for review.

Use the next review to test whether its conclusions change anything.

Spreadsheets used for GxP calculations and small standalone systems are frequently missed. Include them in the inventory with risk ratings and proportionate reviews.

A simple checklist for low-risk tools can still confirm version control, protection and verification.

For software-as-a-service, the supplier controls much of the infrastructure. Periodic review should consider supplier audit results, release management, service-level performance and incident reports.

Contracts and quality agreements should give the customer the information needed for review.

A useful report states scope, period, inputs reviewed, findings, conclusion on validated state and actions with owners and dates. Attach or reference evidence rather than paraphrasing.

Approval by system owner and quality closes the review.

A periodic review of a LIMS finds 14 changes since last year, two of which skipped impact assessment, three leaver accounts still active and no restore test in 18 months.

The reviewer concludes the system remains fit for use with actions: retrospective impact assessments, account removal, a restore test and a change-control refresher. Actions are tracked in CAPA.

A periodic review confirms that a computerised system is still in a controlled, validated state. It is a review of evidence, not a repeat of validation.

1. Confirm the scope, intended use and risk classification are still correct.
2. Review changes made since the last review and whether each was assessed and tested.
3. Review incidents, deviations, open CAPAs and audit trail review results.
4. Check user access lists and remove accounts that are no longer needed.
5. Confirm backups were tested and supplier agreements remain current.
6. Record the conclusion, actions and the date of the next review.

Higher-risk systems usually need more frequent review. If the review finds the system is no longer in a validated state, the system owner and quality should agree corrective actions and decide whether any use should be restricted.

1. Confirm the applicable requirement, product scope and decision owner.
2. Map the current method and the records already available.
3. Define terms, responsibilities, evidence and exception handling in the approved procedure.
4. Pilot the method on one representative process and challenge a difficult exception.
5. Train affected roles, approve the change and monitor whether the method works as intended.
6. Review after significant change and retain a transparent history of decisions.

Scale the formality to risk and complexity. A small operation still needs clear responsibilities and reconstructable evidence, while a multi-site operation also needs harmonised definitions, governance and comparison rules.

• Can a reviewer identify the source, owner, method and current approved version?
• Do summaries reconcile to original records and include unfavourable or missing evidence?
• Are exceptions visible, assessed and linked to the affected material, product or process?
• Are actions assigned, overdue items escalated and effectiveness reviewed?
• Have changes in product, supplier, equipment, method or regulation triggered reassessment?
• Does the record distinguish system support from the decision an authorised person made?

• Approved scope, definitions and responsibilities for Periodic Review of Computerised Systems.
• Source records and identifiers that let a reviewer reconstruct the work.
• Methods, assumptions, calculations, exclusions and any data-quality limitations.
• Exceptions, investigations, decisions, approvals and resulting actions.
• Version history showing when the approach changed and why.

Records should be proportionate to the decision and usable by someone who was not present. Preserve original evidence and corrections rather than replacing it with an unexplained summary.

• Can users trace every summary value back to its source record and version?
• How are roles, permissions, signatures and corrections recorded?
• Can the workflow reflect our approved procedure without inventing a universal rule?
• What happens during an outage, and how are later entries distinguished?
• Can we test the highest-risk exception with realistic data before committing?
• Which decisions remain explicitly assigned to an authorised person?