"Audit trail" appears in every compliance checklist and most software brochures, and is rarely defined. Here is the definition that matters: a chronological record of actions taken in a system — who, what, when, on which record — that the people performing the actions cannot alter. The last clause is the whole point.
What it is for
- Answering "who changed this?" — the everyday use. The status was Completed; now it is On hold. Who, when, and what else did they change?
- Proving a sequence of events — the document was uploaded on the 3rd, shared with the client on the 4th, downloaded by them on the 5th. That sequence is evidence in a dispute about what the client knew and when.
- Detecting misuse — someone opened forty client files in an hour at 2am. The trail is what makes that visible.
- Satisfying regulators and auditors — most data-protection, financial and professional regimes require the ability to show who accessed personal or sensitive data.
- Access requests and incident response — "what data did we hold about X and who saw it?" is a query against the trail.
What makes an audit trail trustworthy
- Written by the system, automatically. Not a log people are asked to fill in.
- Not editable by users — including administrators. An audit log an admin can tidy up is a diary, not evidence.
- Server timestamps. The time comes from the server, not from a device whose clock can be changed.
- Complete for the actions that matter — sign-ins, views and downloads of files, edits, shares, permission changes, exports, deletions, failed authentication attempts.
- Attributable to a person — which requires that people do not share accounts.
- Retained for at least as long as the records it describes, and exportable.
Two layers, both needed
Most good systems keep two views. A human-readable timeline per record — "Maria added the check-out report", "status changed to Completed" — that people read every day. And a lower-level audit log that records everything including the things a timeline would clutter: each sign-in, each file view, each permission change. The timeline is for working; the log is for proving. In Herarx both exist and neither can be edited by the people they describe; we describe how legal teams use them in the case timeline as evidence.
How to read one
Start from the record, not from the log. Open the matter, read its timeline for the human story, then drop to the audit log for the specific question: "show me every access to this file". Filter by person when the question is about a person; by date range when it is about a period. Export the filtered view with the records it concerns, and it becomes the chronology in a bundle.
Questions to ask any vendor
- Can any user or admin edit or delete audit entries?
- Are file views and downloads logged, or only edits?
- Where do the timestamps come from?
- Can I export the log for one record, one person, one period?
- How long is it kept?
A vendor who cannot answer the first question with a flat "no" does not have an audit trail. They have a log.
