Who Changed This? Why You Need an Audit Trail

One day a figure comes out wrong. An order goes missing, or a price changes at a moment nobody can account for. At that point only one question is left. Who did this.

An audit trail exists to answer that question later. Its value shows up when something has gone wrong, which is exactly the moment it is too late to start building one.

It is not about finding someone to blame

This is the reaction we get most when the subject comes up. The team feels watched.

The aim is not to catch anyone, it is to find where the error started. When a stock figure does not reconcile, knowing who changed it and when solves the problem in minutes. Without a record the same question stays open for days.

In practice the place it helps most is debugging. A customer claims one thing, you remember another, and the record can prove either of you right.

Recording everything does not work

The first instinct is usually to record everything. That produces noise, and the line that matters disappears underneath it.

What gets recorded is the actions that change state. Deletions, permission changes, price and amount changes, exports and failed sign-in attempts. Recording page views and every click builds a pile nobody looks at.

We measured this on one panel. Of more than eight thousand events collected, almost all were screen views. The signals worth having were buried underneath.

From what to what

Knowing that a record changed is not enough. On its own, the fact that something changed means nothing when a dispute comes up.

The before and after are kept. What the price was and what it became. Which state the order was in and which state it moved to. Without that, the record is just a timestamp.

Shared accounts make the question unanswerable

If the team shares one administrator account, there is no answer to who did it. You are keeping a record and all it says is admin.

This is why we recommend named accounts. A shared token works in a two person team and becomes unanswerable when a third person arrives. It also means changing everyone password the day somebody leaves.

A log that stays on the box does not exist

We stress this one. The first thing an intruder does after taking a server is clear the log.

The record should be append only and not editable through the application. And it should leave the machine with the nightly backup. A record sitting on the same disk stops being evidence the moment that disk is compromised.

Collected and never looked at

This is the most common situation we find. The system collects records, the table grows, and no screen ever shows them.

We measured exactly this on one panel. The logging endpoint existed, data was accumulating, and not one line in the interface called it. So the record was technically kept and practically absent.

Showing the entries with filters is the only reason keeping them makes sense.

Logs carry personal data too

This gets overlooked. A log line holds a user id, an IP address and sometimes an email. So the log is itself data that needs protecting.

How long it is kept gets written down, and expired entries are removed. Otherwise the thing kept for security becomes a risk in its own right. Passwords, tokens and full card details should never reach a log line either. Dumping the whole request while catching an error means writing secrets to disk in plain text.

How long should it be kept

There is no single right answer, it depends on the work. For financial records statutory retention periods decide it. For technical logs a few weeks is usually enough.

What matters is that the period is written down and actually enforced. A record kept indefinitely eventually becomes a liability.

Will it slow things down

Built properly it is not noticeable. What slows things down is recording every request and putting the write inside the main operation.

Only meaningful actions are recorded, and the write is kept off the critical path. Confirming an order should not have to wait for a log entry.

Can it be added later

Yes. The hard part is not the past but the future.

You have to decide which actions to record and wire them in from one place rather than scattering the calls through the code. Logging spread across a codebase always ends up incomplete, because whoever writes the next screen forgets to add it and that omission stays silent.