This is a ready-to-use periodic review record for the system-level audit trail events that no single batch or result review ever examines: account and privilege changes, specification and limit changes, clock and time-zone changes, and periods when the audit trail was disabled. Record-level review catches manipulation of one record; this record catches the configuration and access events where the most serious integrity problems hide. Replace every <<FILL: ...>> placeholder with your own specifics, route it through document control, and keep the completed record per your retention schedule. A filled specimen follows the blank form. Verify each cited regulation against the current source before you rely on it.
Why this record exists (regulatory basis)
Record-level audit trail review is tied to a specific record at approval and is evidenced inside batch record review and analytical result review. It does not, by design, examine system-wide events that appear in no single record. The FDA data integrity guidance (Data Integrity and Compliance With Drug CGMP: Questions and Answers) expects audit trails of critical data to be reviewed at appropriate intervals based on the system’s complexity and use, and EU GMP Annex 11 section 9 expects GMP-relevant audit trails to be reviewed on a regular basis. The MHRA GxP Data Integrity guidance and PIC/S PI 041 both put primary review with the person responsible for the data and expect QA oversight. This periodic record is the evidence that the regular, system-level review happened, covered the right event categories, and was dispositioned.
Document control header
| Field | Entry |
|---|---|
| Record title | Periodic System-Level Audit Trail Review |
| Record / form number | <<FILL: form ID, e.g. QA-F-042>> |
| Governing SOP | <<FILL: SOP-ID for audit trail review>> |
| System reviewed (name / ID / environment) | <<FILL: e.g. LIMS-PROD, validated>> |
| GxP criticality of system | <<FILL: High / Medium / Low, per data criticality assessment>> |
| Review period | <<FILL: from date>> to <<FILL: to date>> |
| Review frequency and basis | <<FILL: e.g. Monthly, high-criticality release system>> |
| Exception tool / query and version | <<FILL: report name + version, or "full manual review">> |
1. Scope of this review
This review covers the system-level (not record-level) audit trail events listed in section 3 for the period above. It confirms that the audit trail was enabled and complete for the entire period, that each in-scope event was authorized and explained, and that any anomaly was routed to disposition. It does not replace record-level audit trail review performed at batch or result approval, which is governed by <<FILL: SOP-ID for record-level review>>.
2. Prerequisites (confirm before reviewing)
| Prerequisite | Confirmed (Y/N) | Note |
|---|---|---|
| Audit trail was enabled for the entire period, with no unexplained gaps | <<FILL>> | If No, raise an exception immediately |
| Reviewer has read access to the full system-level audit trail | <<FILL>> | |
| Reviewer is independent of the administrative actions under review | <<FILL>> | See independence note in section 6 |
| Exception query/report (if used) is validated and change-controlled at the version stated in the header | <<FILL>> |
3. Event categories reviewed and findings
Review at least the following categories for the period. For each, record the count found, whether every instance was authorized and explained, and the disposition. “None found” is a valid, and required, entry; never leave a category blank.
| Event category | Count in period | Every instance authorized and explained? | Disposition / reference |
|---|---|---|---|
| User account created, disabled, or deleted | <<FILL>> | <<FILL: Y/N>> | <<FILL: tied to access request tickets>> |
| Role or privilege change (esp. grants of admin) | <<FILL>> | <<FILL>> | <<FILL>> |
| Shared or generic account use detected | <<FILL>> | <<FILL>> | <<FILL: expect zero; any use is an exception>> |
| Specification, limit, or calculation change | <<FILL>> | <<FILL>> | <<FILL: tie to change control number>> |
| Master data / method / recipe library change | <<FILL>> | <<FILL>> | <<FILL>> |
| System clock, time-zone, or date-format change | <<FILL>> | <<FILL>> | <<FILL: expect zero on a synced system>> |
| Audit trail disabled, then re-enabled | <<FILL>> | <<FILL>> | <<FILL: any occurrence is an exception>> |
| Configuration change to security or password policy | <<FILL>> | <<FILL>> | <<FILL>> |
| Bulk data export, purge, or archive operation | <<FILL>> | <<FILL>> | <<FILL>> |
<<FILL: site-specific event learned from prior deviations>> | <<FILL>> | <<FILL>> | <<FILL>> |
4. Exceptions raised
| # | Event detail (who, when, what) | Initial assessment | Deviation / investigation ref | Data held pending resolution? |
|---|---|---|---|---|
<<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL: Y/N>> |
If no exceptions were raised, state explicitly: “No exceptions. All in-scope events authorized, explained, and consistent.”
5. Acceptance criteria
This periodic review is acceptable when all of the following are true:
- The audit trail was enabled and complete for the entire period, with no unexplained gap.
- Every in-scope event category was examined and its result recorded, including categories with no findings.
- Every user/role change traces to an approved access request; every specification, limit, or master-data change traces to an approved change control.
- Zero shared-account uses, zero unexplained clock changes, and zero unexplained audit-trail-disable events, or each such occurrence is raised as an exception and routed to a deviation.
- Every exception has a disposition and, where quality-relevant, a deviation reference, and affected data was held until resolved.
- The record is complete, signed, and dated by the reviewer and approved by QA within the defined time.
6. Independence, reviewer, and QA oversight
The reviewer must not be the person who performed the administrative actions under review. In a small team where the administrator and reviewer would otherwise be the same person, route administrative-event disposition to a second qualified person or to QA, and record how independence was achieved here: <<FILL: how independence is achieved>>.
| Role | Name | Signature | Date |
|---|---|---|---|
| Reviewer | <<FILL>> | ||
| QA oversight / approval | <<FILL>> |
7. References
21 CFR Part 11.10(e) (secure, computer-generated, time-stamped audit trails). 21 CFR 211.68, 211.180(e), 211.194 (records and their review). FDA Guidance, Data Integrity and Compliance With Drug CGMP: Questions and Answers. EU GMP Annex 11, section 9 (audit trails, reviewed regularly). MHRA GxP Data Integrity Guidance and Definitions; PIC/S PI 041.
Confirm the current version and clause numbers of each reference before issue.
Filled specimen
The following shows the record completed for an example production LIMS for one month. Company, system, and numbers are illustrative; replace them with your own.
| Field | Entry |
|---|---|
| System reviewed | LIMS-PROD (validated) |
| GxP criticality | High (holds release-testing results and specifications) |
| Review period | 01 July 2026 to 31 July 2026 |
| Review frequency and basis | Monthly, high-criticality release system |
| Exception tool / query | ATR-Query v3.2 (validated, change-controlled) |
| Event category | Count | Authorized and explained? | Disposition |
|---|---|---|---|
| User account created/disabled/deleted | 3 | Yes | 2 new hires, 1 leaver; tied to access tickets ACC-2026-311/312/318 |
| Role / privilege change | 1 | Yes | Analyst granted temporary approver role, ticket ACC-2026-320, time-boxed |
| Shared/generic account use | 0 | n/a | None found |
| Specification / limit change | 1 | Yes | Assay limit updated under change control CC-2026-0142 |
| Master data / method change | 0 | n/a | None found |
| Clock / time-zone change | 0 | n/a | None found (NTP synced) |
| Audit trail disabled/re-enabled | 0 | n/a | None found |
Exceptions: One privilege change (ACC-2026-320) initially had no expiry recorded. Reviewer queried the system owner the same day; the grant was confirmed time-boxed to 14 days and the record was corrected. No deviation warranted. Disposition: acceptable with rationale.
Reviewer: A. Patel, signed 03 August 2026. QA oversight: R. Gomez, signed 04 August 2026.
In this example the reviewer found a privilege grant with a missing expiry, queried it the same day, confirmed and corrected it, and documented the reasoning rather than passing it silently. That query-and-disposition trail is exactly what a periodic system review is expected to show.
Common inspection findings this record prevents
- System-level events (user/role changes, clock changes, audit-trail-disable events) never reviewed, only record-level review in place.
- A privilege escalation used once and downgraded, never questioned because nobody reviewed account events.
- A clean review period left blank instead of positively documented, so it looks like a missed review.
- A specification change made in the system with no traceable change control behind it.
- The administrator reviewing their own administrative actions with no independence.
How to adapt this record
- Set the form number and point the governing-SOP field at your real audit trail review procedure.
- Replace the event-category list in section 3 with the actual system-level events your platform can log, and add the site-specific events your deviations have taught you to watch.
- If you use a validated exception query, name it and its version and reference its validation record.
- Set the review frequency from the system’s criticality; do not commit to a cadence you cannot evidence.
- Confirm every regulation in section 7 against its current published version before issue.