Audit Trail Review: Writing a Procedure That Survives an Inspection
An audit trail that is enabled but never reviewed is one of the most commonly cited gaps there is. A defensible procedure names six things: scope, frequency, reviewer, method, escalation and record. Full review of every entry is impossible, so the sampling rationale is what has to be written down.
The gap usually opens for an understandable reason. The trail gets enabled during validation, confirmed as non-disableable, documented, and ticked off. Nobody decides who opens it afterward, because enabling felt like the requirement.
This guide covers how to scope a review by risk, the six elements a procedure needs, the signals worth following, and how to keep the routine alive on a live study. It sits under what you own and what the vendor owns in eClinical validation.
After reading this you will be able to:
- Scope a review that is both meaningful and actually performable
- Justify a review frequency rather than picking one
- Recognize the four signals that separate a review from a scroll
- Produce a record that answers the inspection question directly
Scoping by Risk
The first decision is what you are reviewing, and the honest constraint is that you cannot review all of it.
The second row carries most of the weight. A change made after initial entry, with no reason recorded, is the classic data integrity question, and it is the one an inspector reaches for first. Reviewing all of those, and sampling the rest, concentrates effort where the questions come from.
Deletions deserve the same treatment for a different reason: removing a record is harder to explain than correcting one, and the explanation needs to exist before anyone asks.
Six Elements of a Defensible Procedure
The one most often missing is escalation. A procedure can define scope, frequency, reviewer and method and still leave the reviewer with no stated basis for deciding that something is worth raising. Without it, two reviewers produce different outcomes from the same data, and neither can explain why.
The frequency element needs a justification rather than a number alone. "Monthly" invites the question of why monthly, and the answer should connect to risk and to how much the data changes, not to what fitted the calendar.
What You Are Looking For
The second signal is the one worth dwelling on. A burst of edits shortly before a database lock or a submission is not automatically a problem, and it is always worth understanding. Sometimes it reflects a monitoring visit that found a systematic entry error. Sometimes it reflects pressure to make data look clean rather than to make it correct, and that distinction is exactly what a review exists to draw.
The third signal frequently resolves into an account problem rather than a behavior problem. A single login responsible for a disproportionate share of changes is often a shared account, which breaks attribution across every other requirement as well, as covered in what inspectors ask to see on Part 11.
Keeping the Routine Alive
Most review programs do not fail at the design stage. They fail in month four, when the first reviewer leaves or the export turns out to take two hours to prepare.
Three design choices help. Attach the review to a meeting that already happens rather than creating a new one. Keep the sample small enough to complete in a sitting, because a review that takes a day gets postponed and a postponed review becomes an annual review. And check early that the export is actually usable: a trail that can only be read one record at a time in a web interface will not support any sampling method you design.
It is also worth separating the routine review from triggered review. A signal from centralized monitoring, a complaint, or an unexpected pattern should be able to prompt a review outside the schedule, and the procedure should say so.
Where This Sits in Data Integrity
Audit trail review is one control among several, and it is the one that evidences several of the ALCOA+ principles at once. Attributable, because the trail names who. Contemporaneous, because it timestamps when. Original and accurate, because it shows what changed from what.
Reviewing the trail is therefore not a standalone compliance task but the mechanism by which those principles become demonstrable rather than asserted. How the principles apply across a working data flow is covered in applying ALCOA+ to a real clinical data workflow.
Clinera EDC exposes the trail in a form that supports sampling rather than record-by-record browsing, and clinical and R&D AI covers where automated signal detection helps with volume without replacing the reviewer’s judgment.
References
- 21 CFR Part 11, Electronic Records; Electronic Signatures. US Code of Federal Regulations, Title 21, Part 11. www.ecfr.gov
- Annex 11, Computerised Systems. EudraLex Volume 4, Good Manufacturing Practice guidelines. health.ec.europa.eu
- ICH E6(R3) Good Clinical Practice. International Council for Harmonisation, adopted 6 January 2025. www.ich.org
This guide describes process and regulatory expectations in general terms and is not legal or regulatory advice. Confirm the current version and applicability of any standard or guidance for your study and region.
Frequently Asked Questions
Is enabling the audit trail enough?
No, and this is one of the most commonly cited gaps. Enabling satisfies the technical requirement that changes are captured. The procedural requirement is that someone reviews them: which records, how often, by whom, what counts as a signal, and what the output of each review was. An audit trail nobody has opened since go-live demonstrates only that the data was available to be checked.
How often should audit trails be reviewed?
There is no universally mandated interval, which means you set one and justify it. Frequency should follow from risk: changes to primary endpoint data, deletions and edits made by non-site users warrant review every cycle, while routine entry corrections can be sampled less often. Many teams align the review with an existing rhythm such as monthly data review, which makes it far more likely to actually happen.
Do we have to review every entry?
No, and attempting to is how review programs collapse. On a study of any size the volume makes full review impossible, and a procedure that promises it will not be followed, which is worse than one that promises less and delivers. Risk-weighted sampling is the accepted approach. What matters is that the sampling rationale is written down, because the rationale is what an inspector examines.
Who should perform the review?
Someone with enough independence that they are not reviewing their own work, and enough knowledge to recognize a signal. In practice that is usually data management reviewing site entries, with quality reviewing the data management actions. The reviewer does not need to be from a separate department, but a procedure where the person making most of the changes also reviews them will not hold up.
What should a review record contain?
The period covered, the scope and sample selected, who performed the review and when, what was examined, any signals identified, what was done about them, and the conclusion. The record is the deliverable: a review that happened but produced nothing retained is, for inspection purposes, a review that did not happen. Keep it short enough that producing it does not discourage the review itself.
Can Nirmitee Healthtech help us write an audit trail review procedure?
Yes, and the output is a procedure plus the first completed review rather than a document on its own. Writing the procedure is the easy half. Running it once surfaces the practical problems, such as the export being unusable, the sample being unworkable, or the reason-for-change field being optional. Clinera EDC exposes the trail in a reviewable form, and the procedure works on whatever system holds your data.
