Audit trail

What is an audit trail?

An audit trail is an immutable, time-ordered record of who did what, when, and to which record. Every accountable action, an approval, an edit, an export, a login, becomes one entry.

The value is reconstruction. When a customer says they never approved an order, or a job rewrites a hundred rows overnight, the trail shows what happened instead of guesswork. It is the flight recorder beside your process.

It is also how you prove a claim. Under the GDPR accountability principle in Article 5(2), a controller has to demonstrate that it followed the rules, and a trustworthy trail is usually that evidence.

What a usable entry contains

A line that says "record changed" is useless. A usable entry answers who, what, when, and to what, and shows the change itself. ISO/IEC 27002 control 8.15 sets out the same shape for event logs. It names the actor (the specific account or application that acted), the action (created, updated, deleted, approved, exported), and the target record by identifier. It records a timestamp with time zone, the before and after values, and the source IP, device, or calling system.

One entry might read: jan@acme.be approved invoice INV-2043 at 14:22, submitted to approved, from an office IP. Log context and identifiers, not full personal data or tokens.

What makes an audit trail trustworthy

A record you can quietly edit proves nothing. A few properties separate an audit trail from an ordinary log.

Append-only and tamper-evident. Entries are added, never changed in place. ISO 27002 recommends append-only or read-only storage and cryptographic hashing, and even an administrator must not be able to erase the record of their own mistake.

Separated from the data it audits. The trail lives apart from the records it describes, so the action that changes a row cannot rewrite that row's history.

Retained long enough. Microsoft Purview keeps unified audit records for 180 days on the standard tier, and up to a year, or ten years with an add-on license, on premium. That is a data retention decision, not an accident.

Watched, not just kept. A trail nobody reads only helps after an incident. If someone exports twelve thousand customer records at 02:14 from outside the office, a stored entry tells you next week; an alert tells someone tonight. Decide which actions are sensitive, approvals, bulk exports, permission changes, mass deletes, and alert on those in real time. Approval workflow and data governance both rest on this.

Audit trail versus event sourcing and application logging

Event sourcing

Both are ordered lists of what happened. The difference is where the truth lives: in event sourcing the event store is the state, and you rebuild the current record by replaying its events. An audit trail sits beside the state. Lose the trail and the system still runs; lose the event store and you have lost the data.

Application logging

Application logs are technical: errors, latency, and status, for engineers, kept for days. An audit trail is about accountability. "User X exported every customer record" is audit information; an API timeout on the same request is a technical log.