How to Set Up Audit Trail Review
Make audit trails actually protect data integrity by getting them reviewed.
What a how-to is not
A how-to is SPEQ’s practitioner method, not a procedure. It does not replace your own SOP, it is not a validated approach, and the judgement calls in it belong to your quality unit.
An audit trail records who did what, when, and (where relevant) why to electronic data — but it only protects data integrity if it is reviewed. Setting up audit-trail review means defining which trails matter, who reviews them, how often, and what the reviewer looks for, so that alterations and deletions are actually caught rather than merely logged.
- 1
Identify the critical audit trails
Determine which systems and data are GxP-critical and prioritise their audit trails. You cannot review everything with equal depth, so risk-rank what matters for product quality and decisions.
- 2
Define what a review looks for
Specify what the reviewer checks — changes to critical results, deletions, re-processing, changed timestamps, aborted runs, and out-of-sequence actions — not just that a trail exists.
- 3
Tie review to the record-review point
Make audit-trail review part of the review-and-approval of the associated GxP record (e.g., before batch release or result approval), so it is a gate, not an afterthought.
- 4
Assign responsibility and frequency
Define who reviews (someone independent of the data creator where possible) and how often — per record for critical results, periodically for system-level trails.
- 5
Document the review and act on findings
Record that the review occurred and its outcome, and investigate anything anomalous through deviation/CAPA.
- 6
Handle systems with weak audit trails
Where a system cannot produce an adequate audit trail, define interim controls (procedural, second-person, restricted access) and plan remediation — an inadequate audit trail is itself a risk to manage.
- !Audit trails captured but never reviewed — the single most common data-integrity gap.
- !Reviewing that a trail "exists" without examining it for deletions, changes, or anomalies.
- !No independence between the data creator and the audit-trail reviewer.
- !Ignoring legacy systems that cannot produce adequate audit trails, with no interim controls.
How to Set Up Audit Trail Review: frequently asked questions
Common questions on set up audit trail review.
Do regulators require audit-trail review?
Yes. Modern data-integrity guidance (MHRA, FDA, EU GMP Annex 11) expects that audit trails for critical GxP data are reviewed — typically as part of the review of the associated record — not merely enabled. An unreviewed audit trail provides little assurance.
How often should audit trails be reviewed?
Risk-based. Audit trails for critical results should be reviewed at the point the record is reviewed/approved (e.g., before batch release). System-level configuration and access trails can be reviewed periodically. The frequency should match the data’s importance.
What does an audit-trail reviewer look for?
Changes or deletions of critical data, re-processing or re-integration of results, altered timestamps, aborted or repeated runs, actions out of expected sequence, and any activity inconsistent with the recorded process — anything that could indicate data was manipulated.
What if a system has no usable audit trail?
That is itself a data-integrity risk. Define interim controls (restricted access, independent second-person verification, procedural safeguards) and plan to remediate or replace the system. Regulators expect you to manage the gap, not ignore it.