Switching an audit trail on is easy. Reviewing it in a way that would catch a real problem takes a clear procedure and reviewers who know what they’re looking for.
Most labs now have audit trails switched on. Far fewer review them in a way that would actually catch a problem. An audit trail nobody reads is a record of what happened, not a control over it.
When audit trails should be reviewed
FDA’s 2018 data integrity guidance recommends that audit trails capturing changes to critical data be reviewed with each record, before the record is finally approved. In practice, that means audit trail review belongs inside routine data review, not in a separate exercise months later.
System-level audit trails, such as user account changes and configuration changes, are typically reviewed periodically, at a frequency based on risk.
What reviewers should look for
Reviewers don’t need to read every line. They need to know which events change the meaning of a result, and look for those:
- Deleted or aborted data. Runs, injections or results that were started but not reported, or files that were removed.
- Reprocessing and reintegration. Especially repeated reprocessing of the same data, or changes made after a result was out of specification.
- Changes to methods, parameters or sequences after acquisition, and whether each one was justified.
- Results that changed after first review. Any edit after a reviewer has seen the data deserves attention.
- Timing anomalies. Timestamps out of sequence, gaps, or changes to the system clock.
- Unexpected users or times. Actions by people outside the expected role, or outside normal working hours.
- Unreported test runs. Samples run before the reported run, which can indicate testing into compliance.
Every change should have a reason recorded, and the reason should make sense.
Making review practical
Audit trail review fails most often because it’s hard to do, not because people don’t care. A few things make it workable:
- Reviewable reports. Configure the system to produce audit trail reports filtered to the events that matter, rather than raw logs.
- A clear procedure. Define what to review, when, by whom, and what to do when something doesn’t look right.
- A checklist. A short, system-specific checklist keeps reviews consistent between reviewers.
- Trained reviewers. Reviewers need to understand the system well enough to recognize what an unusual entry means.
- Documented outcomes. Record that the review happened and what was found, including when nothing was.
- A path to escalate. Reviewers need to know that raising a concern is expected, and exactly how to do it.
When the system makes review difficult
Some legacy systems produce audit trails that are incomplete, cryptic or impossible to filter. That isn’t a reason to skip review, but it is a reason to look at remediation: exporting audit trails into a reviewable format, adding procedural controls around the system, or capturing its data into a platform with a better audit trail.
Key takeaways
- Review audit trails for critical data with each record, before final approval.
- Focus on events that change the meaning of a result, not every line.
- Every change should have a recorded reason that makes sense.
- Reports, a clear SOP, checklists and trained reviewers make review workable.
- If a system makes review impractical, that’s a remediation priority.