What auditors really look for in digital audit trails
Ask a monitor what a good audit trail looks like and they will probably say something like: "I should be able to open it and understand exactly what happened without having to call anyone."
That is a useful benchmark. Audit trails in digital trials are not just a regulatory checkbox. A joint workshop between the FDA and the MHRA on data integrity in global clinical trials put audit trails alongside data blinding and GCP standards as one of the three areas regulators focus on most, precisely because an audit trail is the primary evidence that a study was run with integrity. The ones that hold up under scrutiny share a few consistent characteristics.
The basics every system needs
At minimum, an audit trail should capture:
- Who took each action, linked to a specific, verified user
- When the action occurred, with accurate timestamps rather than server-rounded times
- What changed, including the old value, the new value, and the reason for any edit
These are not controversial. Every system worth using should do this. What separates good audit trails from poor ones is what happens beyond the basics.
What auditors actually read for
Context is what turns raw log data into a story. A well-maintained audit trail reflects normal study operations: it shows patterns in form completion timing, how queries were raised and resolved, and whether data entry followed a reasonable rhythm.
It also helps answer the harder questions. Was a late entry due to participant unavailability or a site that missed the window? Did a data correction happen immediately after an error was spotted, or weeks later just before a monitoring visit? The FDA-MHRA workshop's framing is useful here: inspections exist to verify data integrity and protect participants at the same time, and an audit trail is one of the few places where both of those questions can actually be answered from the same record.
The design problem: too much, not too little
Most audit trail failures are not gaps. They are noise.
| Failure mode | What it looks like | Effect on reviewers |
|---|---|---|
| Over-logging | Every click, page load, and keypress recorded | Real signals buried under thousands of irrelevant rows |
| Under-labelling | Changes logged without a stated reason | Reviewer has to guess intent rather than read it |
| Poor filtering | No way to isolate one form, user, or date range | Every review starts from a full export rather than a targeted question |
| Late surfacing | Corrections mixed into a general activity feed | Genuinely important edits look no different from routine ones |
Good systems avoid all four by logging actions that affect data rather than every interaction, making logs filterable by form, user, date range, and action type, and surfacing corrections and late entries prominently rather than burying them.
What a healthy audit trail looks like in practice
A good audit trail should feel, to use an odd word, boring. It should show the expected: entries made on time, queries raised and answered within reasonable windows, corrections documented with clear reasons.
If it shows that pattern, it means the study ran as intended. And if something unusual appears, the trail gives reviewers exactly what they need to understand what happened and decide what to do next, without a phone call to the site to fill in the gaps.
That is what auditors are really looking for: not a perfect log, but a traceable one.