Audit Trail Review
An audit trail is the secure, computer-generated, time-stamped record of who did what to an electronic record, and when — and, where it matters, why. Audit trail *review* is the human act of actually reading those records to confirm nothing was changed, deleted, or reprocessed in a way that undermines the data a decision rests on. The gap between the two is where a large share of data-integrity findings live: systems that dutifully generated audit trails no one ever looked at, or that had audit trails switched off entirely. The MHRA GXP data integrity guidance, PIC/S PI 041, EU GMP Annex 11, and 21 CFR Part 11 all converge on the same point — the audit trail is only a control if someone reviews it, and reviews the parts that matter.
What an explainer is not
A topic explainer is SPEQ’s synthesis of what a practice involves, cited to the standards that govern it. It does not reproduce their text, and it does not determine which of them apply to your product or process.
[ POSITION IN THE FRAMEWORK ]
7 DIMENSIONS · 26 LINKSHaving an audit trail is not reviewing it: the review is an active, recurring control spanning the documentation and quality-system disciplines, won or lost inside the computerized systems below and policed by the standards at right.
06 · QUALITY MATURITY — AUDIT TRAIL REVIEW, REACTIVE TO ADAPTIVE
Audit trails are enabled but never read, or switched off entirely; the deleted run is found by the inspector, not the reviewer.
A review SOP exists and the batch record carries an 'audit trail reviewed' initial, but scope and the events checked are undefined.
Risk-based review is scheduled and evidenced: named trails, defined critical events, an independent reviewer, and a route to deviation.
Result changes, deletions, and reprocessing are trended across systems; anomalous edit patterns surface before batch disposition.
Exception-based review on validated systems: the trail flags the events that matter, and findings feed data governance and system selection.
SPEQ’s shared five-stage progression, labelled synthesis — not the FDA QMM rating scale. Where does your organization sit? Score your quality system →
07 · REGULATORY & EVIDENCE
GOVERNING STANDARDS · 4
Derived from the 4 standards SPEQ maps to this subject, across 4 regulatory bodies: FDA, EMA, MHRA, PIC/S.
RECORDS & OBJECTIVE EVIDENCE
- Documented audit-trail review records naming the trails and event types in scope
- Procedures defining review frequency, scope, and reviewer independence
- Investigations opened from audit-trail findings (changed results, deleted runs)
- User-access and privilege records showing who can alter or disable a trail
- System-level periodic reviews confirming the audit trail is enabled and complete
COMMON INSPECTION FINDINGS
- Audit trail switched off, or enabled but never reviewed
- 'Audit trail reviewed' signed with no record of what was examined
- Reviewer checking their own actions, with no independence
- Deleted or reprocessed runs never investigated
- Shared logins making audit-trail entries non-attributable
The distinction that built an enforcement wave: having vs. reviewing
The single most consequential misunderstanding is that possessing an audit trail satisfies the requirement. It does not. A generated-but-unread audit trail is a security camera pointed at the wall — it records everything and protects nothing, because no one watches it. Regulators discovered exactly this pattern across an era of inspections: chromatography systems whose audit trails were disabled, shared logins that made every action anonymous, and audit trails that were technically enabled and functionally ignored. The finding was rarely "you have no audit trail"; it was "you never reviewed it," and the two are worlds apart in what they say about a quality system.
This is why the obligation is framed as **audit trail review**, an active recurring task with an owner, a frequency, and a defined scope — not merely a system capability. EU GMP Annex 11 expects audit trails for GMP-relevant changes and deletions and expects them to be *available and reviewed*; 21 CFR Part 11 requires secure, computer-generated, time-stamped audit trails for actions that create, modify, or delete electronic records. Capability is the precondition; review is the control.
Why the audit trail is load-bearing for ALCOA+
The audit trail is the mechanism that makes several ALCOA+ attributes enforceable rather than aspirational. **Attributable** depends on every action being traceable to a unique individual — which is why shared or generic logins are a data-integrity failure: they sever the link between an action and a person. **Original** and **contemporaneous** depend on being able to see whether a record was altered after the fact and whether it was created when the event happened. Without a functioning audit trail, "the data was not changed" is an assertion; with one, it is verifiable. The audit trail is the difference between trusting a result and being able to *show* it was not manipulated.
That is also why the most revealing audit-trail events are not the routine ones. The entries that matter are the ones that can hide a problem: a result changed after first acquisition, a run deleted or renamed, an aborted or "trial" injection, a re-integration of a chromatography peak, a change to a system clock or a processing method, an override of a flagged result. A reviewer who reads only the orderly entries and skips these has reviewed the audit trail in name only — the events most worth reviewing are precisely the ones a bad actor or a careless one would rather not be seen.
Risk-based review — or you drown in keystrokes
Audit trails can record enormous volumes of low-consequence activity, and a requirement to review *every* entry on *every* system would be both impossible and counterproductive — it would bury the meaningful events under the trivial ones. The workable model, which PIC/S PI 041 and the MHRA guidance both endorse, is **risk-based review**: focus on the audit trails of the data and systems with genuine GxP impact, and concentrate on the events that could affect a decision. A change to a reportable analytical result deserves scrutiny; a benign navigation event does not.
The practical structure has two layers. Routine **record-level review** folds audit-trail review into the review of the record it belongs to — the analyst’s data audit trail is examined as part of reviewing that analytical result, and the batch’s relevant electronic-record trails are checked as part of batch-release review, so the review happens at the natural quality checkpoint rather than as a disconnected exercise. Periodic **system-level review** steps back to look at the system as a whole — configuration, user privileges, whether the audit trail is still enabled and complete, whether anyone has the ability to alter or disable it. The reviewer must also be independent enough to be meaningful: a person reviewing their own audit trail for their own actions is not a control.
The tick-box failure — and what a real review produces
The characteristic weak implementation is the audit-trail review reduced to a signature: a box on the batch record initialled "audit trail reviewed" with no evidence anyone examined the events that mattered, no record of what was looked at, and no mechanism that could ever surface a problem. As with the copy-paste product quality review, a review that cannot fail is not a control. Inspectors probe exactly this by asking the reviewer to walk through what they actually checked and to explain a specific unusual event — and the answer reveals whether the review was real.
A genuine audit trail review is defined by scope and consequence: it states which trails and which event types are in scope, it is performed by someone competent and appropriately independent, and it has a route for what happens when something is found — an unexplained result change or deleted run becomes a deviation and an investigation, not a shrug. Its outputs feed the broader data-governance picture that management review is meant to see. The audit trail is the backbone of a data-integrity programme, but only the review turns that backbone into assurance; without it, the record exists and the control does not.
FREQUENTLY ASKED
Is having an audit trail enough to be compliant?
No — and this is the distinction regulators built an enforcement wave on. A generated-but-unread audit trail is a security camera pointed at the wall: it records everything and protects nothing. The requirement is audit trail review, an active recurring task with an owner, frequency, and scope. Findings were rarely "you have no audit trail" but "you never reviewed it," and the two say very different things about a quality system.
Which audit-trail events matter most in a review?
The ones that can conceal a problem: a result changed after first acquisition, a run deleted or renamed, an aborted or "trial" injection, a re-integration of a chromatography peak, a change to a system clock or processing method, or an override of a flagged result. A reviewer who reads only the orderly entries and skips these has reviewed the trail in name only.
Do you have to review every audit-trail entry?
No. Reviewing every entry on every system would bury the meaningful events under trivial ones. PIC/S PI 041 and the MHRA guidance endorse risk-based review: focus on the audit trails of data and systems with genuine GxP impact and on events that could affect a decision. Routine record-level review folds into reviewing the record itself; periodic system-level review checks configuration, privileges, and whether the trail is still enabled and complete.
How does the audit trail relate to ALCOA+?
It makes several ALCOA+ attributes enforceable rather than aspirational. Attributable depends on every action tracing to a unique person — which is why shared logins are a data-integrity failure. Original and contemporaneous depend on being able to see whether a record was altered after the fact or created late. Without a functioning, reviewed audit trail, "the data was not changed" is an assertion rather than something you can demonstrate.