What an audit trail is actually for

Most people, asked what an audit trail is for, will say something about accountability or catching wrongdoing.

That is a small part of it, and it is the part that makes audit trails unpopular with the people who have to work under them. The larger and more useful purpose is reconstruction: being able to say, later, what the state of the world was at a particular moment and what somebody knew when they acted.

Framed that way, the audit trail protects the person who made the decision at least as much as it protects the organisation.

The question it exists to answer#

Not who did this. The much harder question is:

Why was this reasonable at the time?

A decision made a year ago was made on information available a year ago. If your records only hold the current state, then every past decision is judged against facts that arrived afterwards, and every past decision looks worse than it was.

An audit trail that captures the state at the time of the decision — what the order said, what had been received, what the balance was, which version of the document was signed — makes the reconstruction possible. Without it, defending a correct decision is a matter of memory and confidence.

What has to be in an entry#

Five things, and the fourth is the one usually missing.

Who. Including, where relevant, on whose behalf. A delegated action recorded under the stand-in's name loses the fact of delegation permanently.

When. Server time, not client time. A client clock is under somebody's control.

What changed. Both sides — the value before and the value after. A trail that records only the new value cannot answer the most common question, which is what it used to be.

Why. A reason, where one is required. This is the field that turns a log into a record, and it is the one systems skip because it needs a human.

On what basis. Which version of the document, which rule, which computation. A payment approved against a total that has since been revised needs to record the total it was approved against.

The reason that never arrived#

A concrete failure from our own system, because it shows how easily the fourth field is lost.

Reversing a stock entry required a reason, and the interface asked for one. The reason never reached the audit trail — because the trail reads the reason from the record's new state, and no reason was ever handed to it.

So every cancellation would have been recorded as having happened for no stated reason. The prompt was there, the person typed an answer, and the answer went nowhere.

Nothing errored. The trail was full of properly formed entries, each complete except for the only field anybody would ever want. This is the ordinary shape of audit-trail defects: they do not look like failures, they look like records.

Append-only, or it is not a trail#

An audit trail that can be edited is a document, not a trail.

This is not a matter of degree. If the entries can be revised, then the trail tells you what somebody most recently wanted it to say, which is precisely the thing you were trying to avoid depending on.

The practical form is that entries are only ever added. A mistake in the trail is corrected by a new entry describing the correction, not by fixing the old one. The full argument, including why this is also better for ordinary day-to-day questions, is in append-only records.

Ours is a hash chain, which means each entry incorporates a fingerprint of the one before it. The practical consequence is that no entry can be inserted, removed or altered without breaking every entry after it — including by somebody with database access. It also means a hand-written entry is impossible, which is a constraint we ran into and then decided to keep.

What it must not become#

Three failure modes turn an audit trail into an expense with no benefit.

A log of everything. If every read, every page view and every keystroke is recorded, the trail is enormous and the decisions are buried. Record the decisions and the changes, not the traffic.

A trail nobody can read. A table of field names and identifiers is technically complete and practically useless. If answering an ordinary question requires an engineer, then the trail is not available to the people who need it, and its existence is theoretical.

A trail that is only consulted in disputes. A record read once a year is a record nobody notices is broken. Ours had a missing reason field for a long time precisely because nothing routinely depended on it.

The remedy for the third is to make the trail part of ordinary use. If the history of an order is visible on the order — who did what, when, why — then people read it weekly, and defects in it get noticed by users rather than by auditors. If you are buying rather than building, that is also the thing to make a vendor show you — ask to see the audit trail before you sign.

It protects the approver#

Worth stating separately, because it changes how people feel about being recorded.

Somebody who approved a payment correctly, on the information available, should be able to demonstrate that in two years. Somebody who signed a document should be able to show which version they signed. Somebody who accepted a delivery should be able to show what they recorded on the day.

Without a trail, all of those people are relying on their own recollection and on the goodwill of whoever is asking. With one, they have evidence — and what that evidence has to consist of when a department or an auditor asks years later is the paper trail a query demands.

That is a large part of why people are willing to sign things at all, and it is worth saying out loud when a trail is introduced — because the alternative framing, that the system is watching them, is both available and corrosive.

The related question of the document itself#

An audit trail records what happened to a record. It does not, by itself, prove that a document is the document that was signed.

That is a different mechanism — tamper-evident documents — and the two are complementary. The trail says a signature was applied at a time by a person. The document's own fingerprint says this is the thing that was signed.

The short version#

An audit trail exists so that a past decision can be reconstructed, including by the person defending it.

Record who, when, what changed on both sides, why, and against which version. Make it append-only, or it records only the most recent intention. Keep it small enough to be readable and visible enough to be read routinely.

And check, in your own system, that the reason field actually arrives. Ours did not, for a long time, and every entry looked perfectly fine.