Audit Trail

Audit Trail Review: How to Actually Do It

Updated 2026-11-07

Having an audit trail is the easy part — most systems generate one automatically. The part that trips companies up is reviewing it. Regulators expect evidence that someone actually looks at audit trails and acts on what they find; an audit trail nobody reviews is where data integrity problems quietly live. This article covers how to do the review in practice.

For the underlying principles, see data integrity and ALCOA+ in practice.

What an audit trail review is

It is the routine, documented examination of audit trail entries to catch unauthorised, suspicious or unexplained changes to GxP data — and to confirm that where changes were made, they were justified and recorded properly. It is part of trusting the data, not a separate box-ticking exercise.

What to look for

A useful review looks for the entries that should make you pause:

  • Changes to critical data — results, calculations, status, dates — especially after the fact.
  • Changes without a recorded reason, where a reason is expected.
  • Deletions or voided records, and whether they were justified.
  • Repeated reprocessing or re-tests, which can indicate “testing into compliance”.
  • Actions at odd times or by unexpected users, hinting at shared accounts or access problems.
  • The audit trail being disabled or interrupted — a red flag in itself.

The point is not to re-read every line, but to focus on the entries that matter for the integrity of the result.

Making it risk-based

You cannot review everything on every system equally, so focus by risk. High-impact data — the records that decide whether a product is released — warrants closer and more frequent review than low-impact configuration. The frequency and scope should be defined and justified, typically tied to the review of the associated records (for example, reviewing a batch’s audit trail as part of reviewing the batch). A defined, risk-based approach that you follow consistently is far stronger than an undocumented habit.

How often

There is no single universal number; it is driven by risk and by how the data is used. A common pattern is to review the relevant audit trail at the same time as reviewing the data it belongs to — so a result’s audit trail is checked when the result is reviewed and approved. Define the frequency, justify it, and do it consistently.

Why it matters so much

Audit trail review sits at the centre of data integrity expectations in both EU Annex 11 and 21 CFR Part 11. Inspectors routinely check not just that an audit trail exists and is secure, but that it is reviewed. An unreviewed audit trail undercuts the trust in every record the system holds, which is why its absence is a recurring and serious finding.

Practical challenges

  • Volume. Busy systems generate huge audit trails. Risk-focused review, and tools or filtered views that surface the meaningful changes, keep it manageable.
  • Usability. Some systems make the audit trail hard to read or export. This is worth catching during validation — an audit trail you cannot practically review is a design weakness.
  • Independence. Where possible, the reviewer should not be the only person who could have made the changes being reviewed; segregation of duties strengthens the control.

Designing for reviewability

The easiest audit trail to review is one designed to be reviewed. During the URS and OQ, it is worth specifying and testing that the audit trail captures the right fields (old value, new value, who, when, why), that it cannot be switched off by ordinary users, and that it can be filtered and exported for review. Reviewability is a requirement, not an afterthought.

Next