Periodic Review Report (Validated System)

This is a ready-to-use periodic review report. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, attach the evidence each section references, 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.

A periodic review is the scheduled re-evaluation of a system that is already validated and in operation. It asks one question and answers it with evidence: is this system still in a validated state, and is the data it holds still trustworthy. It is not a re-validation and it is not a fresh project. It is a documented look back over the review period at everything that could have eroded the validated state, with a conclusion and actions.

Document control header

1. Purpose

This report documents the periodic review of <<FILL: system name>> performed by <<FILL: COMPANY NAME>> to confirm the system remains in a validated state, fit for its intended use, and operated under control across the review period. The objective is to gather and assess evidence across validation status, changes, deviations, CAPA, access, backup and recovery, and data integrity, and to reach a documented conclusion with any actions required to restore or maintain the validated state.

2. Scope

This review covers the system named in the header, including its application, configuration, interfaces to <<FILL: connected systems>>, the infrastructure it runs on, and the GxP records it creates, modifies, or stores. It covers the review period stated in the header. It does not re-execute qualification or validation testing; where the review finds the validated state is in question, it raises the need for re-validation or remediation rather than performing it here. The system risk classification and GxP impact are stated in section 4 and drive the depth of this review.

3. Inputs to this review

The reviewer collected and examined the following inputs for the review period. Each is referenced in the relevant section and retained with this report.

4. System overview and risk classification

State the frequency and the depth of this review against the risk classification. A high-risk system that owns release or batch-disposition data warrants a deeper look and a shorter interval than a low-risk read-only system.

5. Validation status

Confirm the system is still covered by current, approved validation documentation that reflects the system as it runs today.

If changes since the last review altered functionality, confirm the change records carried the right validation impact (covered in section 6). A live system whose behavior no longer matches its approved specifications is the single most common reason a periodic review concludes “validated with actions”.

6. Changes since last review

List every change to the system, its configuration, infrastructure, or interfaces during the review period. Confirm each followed change control, carried a documented GxP and validation impact assessment, and was completed and closed.

Cross-check the change log against the live configuration and against patch and upgrade records from IT. A change present on the system but missing from change control is a finding, not a footnote.

7. Deviations and incidents

Summarize deviations, system incidents, outages, and security events for the period and confirm each was investigated, closed, and assessed for impact on data and the validated state.

A repeating incident is a signal the root cause was never fixed. Note any pattern even if each instance was closed, and feed it to CAPA in section 8.

8. CAPA status

Confirm CAPAs raised against this system are progressing, that overdue items have a documented reason, and that closed CAPAs were effectiveness-checked.

9. Access review

Confirm user access is current, role-appropriate, and segregated, and that the periodic access review for this period was performed and documented.

Orphan accounts of leavers and over-privileged administrators are routine inspection hits. Confirm each administrator account maps to a named person and a documented need, and that no ordinary user can disable the audit trail.

10. Backup and disaster recovery status

Confirm backups run, complete, and have been proven restorable, and that disaster recovery and business continuity arrangements were tested within the required interval.

An untested backup is an assumption, not a control. The restore test, not the green backup log, is the evidence. State the RTO and RPO targets and the actual results from the DR test.

11. Data integrity

Confirm controls over the records the system holds remain effective across the ALCOA+ attributes for the period.

State whether the audit trail review for this system actually happened across the period, with a reference to the records. A periodic review that asserts data integrity without naming the audit trail review evidence is incomplete.

12. Conclusion on continued validated state

State a clear, single conclusion supported by the sections above, using one of the defined outcomes.

Defined outcomes:

• Validated, no action required. All sections satisfactory; the system remains in a validated state and the data remains trustworthy.
• Validated, actions required. The system remains usable, but defined actions are needed within set timeframes to maintain the validated state. Use is permitted while actions are tracked.
• Validated state in question. Evidence indicates the system may no longer be validated or data may be at risk. Define interim controls, escalate, and trigger remediation or re-validation before continued reliance.

Do not soften the conclusion to avoid an action. A defensible “validated with actions” beats an unsupported “fully validated” every time an inspector pulls the underlying evidence.

13. Actions

Actions that require formal tracking are raised as CAPA or change records and referenced here; this report tracks status but is not a substitute for the CAPA system.

14. Next review

15. References

21 CFR Part 11 (electronic records and electronic signatures). 21 CFR 211.68 (automatic, mechanical, and electronic equipment) and 211.180 (records retention). EU GMP Annex 11 (computerised systems), in particular sections on periodic evaluation, security, audit trails, and business continuity. EU GMP Chapter 4 (documentation) and Chapter 6 (quality control records). MHRA GxP Data Integrity Guidance and Definitions. PIC/S PI 041, Good Practices for Data Management and Integrity. ICH Q9, Quality Risk Management (for the risk-based review frequency and depth). ISPE GAMP 5 (a risk-based approach to compliant GxP computerized systems), for periodic review expectations.

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

16. Revision history

17. Approvals

Filled specimen

The following shows the same report completed for an example laboratory information management system, so you can see the level of detail an inspector expects. The company, system, and numbers are illustrative; replace them with your own.

In this example the reviewer gathered evidence across every section, cross-checked the change log against the live configuration, named the restore test rather than the backup log as the proof, named the audit trail review evidence rather than asserting integrity, spotted a recurring deviation and tracked it to CAPA, and reached an honest “validated with actions” conclusion with owned, dated actions. That sequence, evidence to conclusion to tracked action, is exactly what a reviewer is expected to demonstrate.

Common inspection findings this report prevents

• Periodic review is required by procedure but no report exists, or reports are years overdue.
• The report asserts “system remains validated” with no evidence: no change list, no deviation list, no access review, no backup or DR evidence cited.
• A change found on the live system is absent from the change log and from the review.
• The review claims data integrity but never names whether the audit trail review actually happened during the period.
• Backups are reported as successful but no restore or DR test was ever performed, so recoverability is assumed, not proven.
• Leaver and over-privileged administrator accounts persist with no access review on record.
• Open and overdue CAPAs and prior-review actions are not carried forward or are silently dropped.
• The conclusion is “fully validated” while the body shows unresolved issues, so the conclusion is not supported by its own evidence.

How to adapt this report

1. Set your document number, owner, system ID, and review period in the header.
2. Set the review frequency and depth from your own risk classification in section 4; a low-risk read-only system needs less than a high-risk system owning release data.
3. Point every input in section 3 to your real change, deviation, CAPA, access, backup, DR, and audit trail records, and attach or reference them.
4. Pull actual records into sections 5 to 11; do not paraphrase the logs, cite them and attach the evidence.
5. Carry forward open actions from the previous periodic review and from CAPA so nothing is dropped between cycles.
6. Choose one of the three defined conclusions in section 12 and make sure the body supports it; raise formal actions as CAPA or change records and reference them in section 13.
7. Confirm every regulation in section 15 against the current published version before issue.