Definition · Plain-language
Audit trail
An audit trail is the secure, time-stamped electronic record of who created, changed or deleted data, what they changed, and when.
The step most authors miss
Doing CRediT right? Don’t stop at the statement.
A CRediT statement credits you inside one paper. The recognition CRediT was built for happens when those roles are tied to you, persistently. Sign in with your ORCID — free — and claim your CRediT contributions on casrai.org, the home of the standard. They become a verified, portable part of your identity, not a line that disappears into one PDF.
Free: claim your contributions, then export a journal-ready CRediT statement, schema.org structured data, JATS XML, CSV or BibTeX — and preview your public profile. A membership publishes that profile publicly and verifies the journals you serve.
What an audit trail records
An audit trail captures the metadata around a data action: the identity of the user, the nature of the action (creation, modification or deletion), the original and new values where data changed, and a reliable date and time stamp. For changes to critical data it should also capture the reason for the change. Crucially, it is generated by the system rather than the user, and it preserves the previous values, so the full history of a record can be reconstructed and the current value is never the whole story.
Why it underpins data integrity
Audit trails make electronic data trustworthy. They support several ALCOA attributes directly: actions are attributable to a specific user, and time stamps show they were recorded contemporaneously. By preserving original entries alongside changes, the audit trail lets a reviewer or inspector see whether data were altered, by whom, and why — which is how an organisation demonstrates that results were not quietly “tested into compliance”. This is why audit-trail review has become a routine part of data-integrity oversight.
Regulatory expectations
Under 21 CFR Part 11, audit trails are expected for electronic records in regulated systems, must be secure and computer-generated, and must be available for inspection. Regulators expect organisations not merely to enable audit trails but to review them — risk-based audit-trail review of critical data is now a standard expectation. The audit trail must be protected from alteration and retained for at least as long as the underlying records, so that the evidentiary value of the trail is preserved throughout the record’s life.
Key facts
At a glance
- Definition: secure, time-stamped record of who did what to data and when
- Generated by: the system, not the user
- Captures: user, action, old/new value, date/time, reason
- Authority: 21 CFR Part 11 (electronic records)
- Supports: ALCOA — attributable, contemporaneous
- Expectation: must be reviewed, secured and retained, not just enabled
Common misconceptions
What people often get wrong
Often heard: An audit trail just needs to exist; nobody has to look at it.
Actually: Regulators expect risk-based audit-trail review of critical data, not merely that the function is switched on.
Often heard: An audit trail can be edited or switched off by users when convenient.
Actually: It must be secure and computer-generated, protected from alteration, and retained for at least as long as the underlying records.
Often heard: The audit trail only matters for the final reported value.
Actually: It preserves original entries and every change, so the full data history — including superseded values and reasons — can be reconstructed.
Going deeper
