Every validated system you own records an audit trail. Ask who reviews them, how often, and where the record of that review lives, and the room usually goes quiet.
That gap is one of the most reliable findings in a GxP inspection, and it is entirely fixable — but not by reviewing everything, which is what makes teams give up before they start.
Why 'the system captures it' isn't an answer
Both 21 CFR Part 11 and EU Annex 11 expect audit trails to be reviewed, not merely generated. MHRA's data integrity guidance is the most explicit about it: review is part of the control, not an optional extra.
The logic is simple. An audit trail nobody looks at deters nobody and detects nothing. It only becomes a control at the moment someone would notice.
So the inspector's question is never "do you have audit trails". It is who reviews them, against what, how often, and show me the last three.
Making it proportionate
Nobody can read every audit trail entry, and no regulator expects it. What they expect is a risk-based approach you can articulate. In practice that means deciding three things.
Which events matter. Not every entry is interesting. The ones that usually are: changes to results or data after initial entry, changes to specifications or limits, deletions, permission and role changes, changes to system date or time, disabled controls, and repeated failed logins. Everything else is background.
When review happens. The strongest model is review at the point of an existing decision — the reviewer approving a batch record or a lab result also reviews the audit trail for that record. It is contemporaneous, has a natural owner, and produces a record automatically. Periodic system-level review then covers what record-level review cannot: administrator activity, configuration changes, permission drift.
What a reviewer does when something looks wrong. If there is no defined escalation, reviews quietly become ticking exercises.
Writing it down
Your procedure needs to answer, per system or system class:
- Which event types are reviewed, and the rationale for that selection.
- Who reviews, and their independence from the activity being reviewed.
- Frequency, tied to risk rather than to convenience.
- How review is evidenced — a signed record, not a memory.
- What happens on a finding: deviation, investigation, CAPA.
- How review itself is verified — someone checking that reviews happen.
If your system can filter to the event types that matter, the whole thing becomes practical. If it cannot, that limitation belongs in your risk assessment — and in the requirements for whatever replaces it.
The failure modes
- The procedure exists, the reviews don't. Most common by far, and trivially detectable: the inspector asks for the last three records.
- Reviewing everything, so nothing gets reviewed. An unachievable procedure guarantees the finding.
- The person reviewed is the person reviewing. A system administrator reviewing their own activity is not a control.
- Findings with no trail. If a review has never produced a single question in two years, nobody believes it is happening.
- Forgetting integrations. Data crossing between systems is where attribution is most often lost, and where audit trails are least often reviewed.
Related: data integrity (ALCOA+), preparing for a GxP audit, and for AI systems the same obligation applies to review records — see what inspectors ask about AI.
Where to go next
Explore GxP Copilot for AI-native validation, TraceDraft for source-traceable clinical documentation, or book a demo to see either on your own data.