GxP / Guide 10

Periodic review and inspection readiness

What a periodic review of a GxP system covers, building an evidence pack with the scripts, incidents and deviations, and what inspectors ask IT.

Periodic review is the check that a system is still in the state its validation described, and still fit for its intended use. It's also the best rehearsal for an inspection: if the periodic review can find the evidence quickly, so can you when an inspector asks. This guide covers what to review, how to gather the evidence with the scripts, and what inspectors ask IT teams.

How often

Set the frequency by risk in your procedure. A common pattern is yearly for high-risk systems, every two years for medium, and every three years for low, with an extra review after major changes or serious incidents. The draft Annex 11 revision defines a list of items every review should cover; the list below is compatible with it.

What to review

Area	Question	Evidence
Intended use and scope	Is the system still used as validated? New users, sites, interfaces or data types?	System owner statement, interface list
Changes	Were all changes made through change control? Is the cumulative effect still covered by testing?	Change list, pipeline history, drift reports
Configuration	Does the running system match the baseline?	IaC version deployed, policy and conformance results
Incidents, deviations, CAPA	What went wrong, were root causes found, are actions closed?	Incident and deviation records
Access	Were access reviews done on time, and removals completed?	Signed review worksheets, removal tickets
Audit trails	Are audit trails on, retained, and reviewed as the procedure says?	Log coverage report, review records
Backup and restore	Are backups succeeding? Were restore tests and DR drills done and passed?	Backup evidence reports, restore test records, drill reports
Security	Is the system patched and supported? Open vulnerabilities?	Patch compliance, vulnerability scan results, vendor support status
Suppliers	Are supplier assessments and agreements current?	Latest SOC 2 review, quality agreements
Procedures and training	Are procedures current, and users and admins trained on them?	SOP versions, training records
Archive and retention	Can old records still be retrieved and read?	Archive retrieval test

The review ends with a conclusion (the system remains in a validated state, or it doesn't, and what will be done), actions with owners and dates, and QA approval.

Build the evidence pack

The scripts on this site produce the IT part of the evidence in a few minutes, and each output comes with a .sha256 file that records the file's hash, who ran it, when, and with which parameters. Run them into one dated folder per review:

$pack = "D:\GxP-Evidence\CSV-0042-LIMS\PR-{0:yyyy-MM-dd}" -f (Get-Date)
New-Item -ItemType Directory -Path $pack -Force | Out-Null

# Azure platform
.\Get-AzGxPAccessReview.ps1       -ExpandGroups -IncludeEligible -OutputFile "$pack\AccessReview.csv"
.\Get-AzGxPAuditLogCoverage.ps1   -MinRetentionDays 730          -OutputFile "$pack\AuditLogCoverage.csv"
.\Get-AzGxPBackupEvidence.ps1     -Days 365                      -OutputFile "$pack\BackupEvidence.csv"

# AWS platform
.\Get-AwsGxPAuditTrailStatus.ps1  -ProfileName notes-gxp          -OutputFile "$pack\AwsAuditTrail.csv"
.\Get-AwsGxPConformanceReport.ps1 -ProfileName notes-gxp          -OutputFile "$pack\AwsPart11Pack.csv"
.\Get-AwsGxPRestoreEvidence.ps1   -ProfileName notes-gxp -Days 365 -OutputFile "$pack\AwsRestoreEvidence.csv"

# Controlled document libraries
.\Get-SPOGxPLibraryControls.ps1 -SiteUrl https://sharepointonline.ravindran.in/sites/qms -OutputFile "$pack\LibraryControls.csv"

Anyone can later confirm a file hasn't changed since it was produced:

$line = (Get-Content "$pack\AccessReview.csv.sha256")[0]
$expected = $line.Split(' ')[0]
(Get-FileHash "$pack\AccessReview.csv" -Algorithm SHA256).Hash.ToLower() -eq $expected

Store the pack in a controlled location (a records library with a retention label, or immutable storage), and reference it from the periodic review report. Reports are evidence, not approvals: the review record still needs a person's assessment of what the reports show.

Incidents and deviations

Annex 11 §13 expects incidents to be reported and assessed, and serious ones to have their root cause found. Make sure the IT incident process connects to the quality process:

Tag GxP systems in the service management tool, so incidents on them are visible to the system owner and QA.
Define which IT events are GxP deviations: data loss, a failed backup beyond the RPO, an audit trail gap, an unauthorized change, unauthorized access, a restore that didn't return correct data.
For those, open a deviation, assess impact on data and product, find the root cause, and track corrective and preventive actions to closure.

What inspectors ask IT

From experience, these come up again and again. Have the answer and the evidence ready:

Show me the inventory of computerised systems and which are GxP.
Who has administrator access to this system and its database, and when was that last reviewed?
Show me the audit trail for this record, and when it was last reviewed.
Can an administrator change data or turn off the audit trail? How would you know?
When did you last restore this system from backup, and what did you check?
Show me a recent change to this system, from request to closure.
How do you qualify the cloud platform, and how do you know when the provider changes it?
What happens to the process when this system is down?
How do you make sure a leaver loses access on their last day?
How are these IT staff trained on GxP and on your procedures?

On inspection day

Have a named IT subject matter expert for each GxP platform available, and brief them on the scope.
Show, don't tell: a live query or a report produced during the inspection is more convincing than a slide.
Answer the question asked. If you don't know, say you'll find out, and do.
Record what was shown and asked, so follow-up requests and responses are consistent.