Infrastructure Periodic Review Report

This is a ready-to-use infrastructure 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.

An infrastructure periodic review is the scheduled re-evaluation of IT infrastructure that is already qualified and in operation: the physical and virtual hosts, operating systems, hypervisor, network and firewall, storage, database engines, time synchronization, backup, and monitoring that GxP applications run on. It is not a requalification and it is not a fresh build. It asks one question and answers it with evidence: has the infrastructure drifted from its qualified baseline, and is it still fit to host GxP applications and data. The review looks back over the period at everything that could have eroded the qualified state, configuration drift, missed patches, components nearing end of support, capacity pressure, security exposure, untested backups, and infrastructure incidents, then reaches a documented conclusion with actions.

Document control header

1. Purpose

This report documents the periodic review of the IT infrastructure listed in section 2, performed by <<FILL: COMPANY NAME>>, to confirm the infrastructure remains in a qualified state, has not drifted from the baseline established at qualification, and is still fit to host GxP applications and the records they hold. The objective is to gather and assess evidence across configuration and baseline status, patching and obsolescence, capacity, security, backup and disaster recovery, and incidents across the review period, and to reach a documented conclusion with any actions required to restore or maintain the qualified state.

2. Scope

This review covers the infrastructure named in the header: the hosts, operating system builds, hypervisor, network and firewall configuration, storage, database engines, time service, backup, and monitoring that support the GxP applications listed below. It covers the review period stated in the header. It does not re-execute infrastructure qualification testing and it does not validate the applications that run on the platform; where the review finds the qualified state is in question, it raises the need for requalification or remediation rather than performing it here.

For infrastructure delivered as a service, state which layers the provider keeps qualified under its own controls and which layers you review. Reuse of the provider’s evidence (its audit reports, its uptime and DR records) is acceptable when you have assessed it; record that assessment in this review, do not assume it.

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. Infrastructure overview and risk basis

State the frequency and the depth of this review against the risk basis. Infrastructure supporting a system that owns release or batch-disposition data warrants a deeper look and a shorter interval than infrastructure supporting only read-only or non-decision systems.

5. Configuration and baseline status

Confirm the live infrastructure still matches the qualified baseline and that every difference is explained by an approved change. This is the central question of the review: has the platform drifted.

A configuration present on the infrastructure but absent from change control, an extra firewall rule, an unrecorded version bump, a host added outside the build standard, is a finding, not a footnote. Cross-check the live state against the baseline, not against memory.

6. Patching and obsolescence

Confirm that operating systems, hypervisor, database engines, firmware, and security agents are patched under control and that no in-scope component has slipped past, or is about to slip past, vendor support.

Patching is not exempt from change control because it comes from the vendor. Each patch needs a GxP impact assessment proportionate to its risk before it touches qualified infrastructure. A component running past vendor end of support, with no patches available for new vulnerabilities, is a finding even if it still works; record the migration or extended-support plan with a date.

7. Capacity

Confirm compute, memory, storage, and where relevant network capacity have headroom against the documented sizing and the observed growth trend, so the platform does not run out of room before the next review.

Storage that fills up can stop a system from writing records or completing backups, which is a data integrity and availability problem, not just an IT housekeeping one. State the trend, not only the snapshot, so a slow climb toward a limit is caught before it becomes an outage.

8. Security

Confirm the security controls that keep the platform trustworthy remain effective: access control, hardening, vulnerability posture, time synchronization, and the security events of the period.

Administrator accounts and time synchronization are the two security points inspectors challenge most on infrastructure. Confirm each administrator account maps to a named person and a documented need, and confirm the clock all hosts depend on is still locked to a trusted source, because every audit trail timestamp on every hosted system inherits that clock.

9. Backup and disaster recovery test status

Confirm backups run and complete, that they have been proven restorable in the period, and that the disaster recovery arrangement was tested against its recovery objectives. A green backup log is not the evidence; the restore is.

An untested backup is an assumption, not a control. State the recovery time objective (RTO) and recovery point objective (RPO) targets and the actual results from the test, and confirm the DR plan still matches the architecture, because a DR plan written for an old topology will fail when it is needed.

10. Incidents

Summarize infrastructure incidents, outages, and problems for the period and confirm each was investigated, resolved, and assessed for impact on the hosted GxP data and on the qualified state.

A repeating incident signals a root cause that was never fixed. Note any pattern even when each instance was closed, and feed it to an action or CAPA in section 12. An outage with no data loss is still relevant: it puts your failover and recovery controls to a real test.

11. Conclusion on continued qualified state

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

Defined outcomes:

• Qualified, no action required. All sections satisfactory; the infrastructure remains in its qualified state, has not drifted from baseline, and remains fit to host GxP applications and data.
• Qualified, actions required. The infrastructure remains usable, but defined actions are needed within set timeframes to maintain the qualified state (for example a pending patch, a capacity expansion, an end-of-support migration). Use is permitted while actions are tracked.
• Qualified state in question. Evidence indicates the infrastructure may no longer be in its qualified state or hosted data may be at risk (for example unexplained drift, an untested DR over the required interval, a component past end of support with an open vulnerability). Define interim controls, escalate, and trigger remediation or requalification before continued reliance.

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

12. 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 and change systems. Carry forward any open action from the previous periodic review so nothing is dropped between cycles.

13. Next review

14. References

EU GMP Annex 11 (Computerised Systems), in particular sections on validation, data storage and backup, business continuity, periodic evaluation, and security. 21 CFR Part 11 (electronic records and electronic signatures) and the predicate-rule data controls it supports. 21 CFR 211.68 (automatic, mechanical, and electronic equipment) and 211.180 (records retention), where infrastructure runs GMP records. ISPE GAMP 5 (a Risk-Based Approach to Compliant GxP Computerized Systems), including the IT infrastructure control and compliance guidance; infrastructure is Category 1. ICH Q9, Quality Risk Management (for the risk-based review frequency and depth). ICH Q10, Pharmaceutical Quality System. PIC/S PI 011, Good Practices for Computerised Systems in Regulated GxP Environments. MHRA GxP Data Integrity Guidance and Definitions (for the data storage, backup, and time-synchronization expectations).

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

15. Attachments

16. Revision history

17. Approvals

Filled specimen

The following shows the same report completed for an example virtualized host cluster supporting a laboratory data system, so you can see the level of detail an inspector expects. The company, hosts, and numbers are illustrative; replace them with your own.

In this example the reviewer compared the live platform against its recorded baseline rather than against memory, caught a firewall rule that bypassed change control, tracked a component toward end of support before it expired, read storage as a rising trend rather than a single number, named the restore and DR tests as the proof rather than the backup log, confirmed the clock all hosted audit trails depend on, and reached an honest “qualified with actions” conclusion with owned, dated actions. That sequence, baseline comparison to evidence to tracked action, is exactly what a reviewer is expected to demonstrate.

Common inspection findings this report prevents

• Infrastructure periodic review is required by procedure but no report exists, or reviews are years overdue.
• The report asserts “infrastructure remains qualified” with no baseline comparison, so configuration drift is invisible and unproven either way.
• A configuration or firewall rule present on the live platform is absent from change control and from the review.
• Patches are applied with no GxP impact assessment, or a component runs past vendor end of support with no migration plan and an open vulnerability.
• Storage or capacity is reported as a single snapshot with no trend, so a slow climb toward a limit becomes a surprise outage.
• Backups are reported as successful but no restore or DR test was performed in the period, so recoverability of GxP records is assumed, not proven.
• Time synchronization is not verified, leaving every hosted audit trail timestamp untrustworthy.
• Over-privileged or orphan administrator accounts persist with no access review on record.
• The conclusion is “fully qualified” while the body shows unresolved drift, an end-of-support component, or an untested DR, so the conclusion is not supported by its own evidence.
• Open actions from the previous periodic review are not carried forward or are silently dropped.

How to adapt this report

1. Set your document number, owner, infrastructure scope, and review period in the header, and link the original qualification record and baseline this review is measured against.
2. Set the review frequency and depth from your own risk basis in section 4; infrastructure supporting a high-risk release system needs more than infrastructure supporting only read-only systems.
3. Point every input in section 3 to your real CMDB, change, patch, lifecycle, capacity, security, backup, DR, and incident records, and attach or reference them.
4. In section 5, run an actual comparison of the live configuration against the qualified baseline and explain every difference with an approved change; do not assert “no drift” without the comparison.
5. In section 6, list real versions against vendor support dates so an approaching end of support is caught with time to plan, and confirm each patch carried a GxP impact assessment.
6. Pull real numbers and trends into the capacity, security, backup, and DR sections; for backup and DR, name the restore and the DR test and their RTO and RPO results, not the backup log.
7. For cloud or IaaS hosting, state which layers the provider keeps qualified and record your assessment of the provider’s evidence rather than assuming it.
8. Choose one of the three defined conclusions in section 11 and make sure the body supports it; raise formal actions as CAPA or change records and reference them in section 12.
9. Carry forward open actions from the previous review and set a specific next-review date with named earlier-review triggers in section 13.
10. Confirm every regulation in section 14 against the current published version before issue.