Audit Logs: Knowing Who Did What, and When It Matters Most

What an audit log actually is

An audit log is a permanent record of who did what, and when, inside your application. Think of it as a ledger: a user changed a price, deleted a record, logged in from a new device, or exported a customer list.

It is not the same as general application logging, which developers use to debug errors. An audit log is written for people, not machines, and it answers business and security questions rather than technical ones.

The goal is simple accountability. When something changes that shouldn't have, you want to trace it back to a person and a moment without guesswork.

Why it matters before anything goes wrong

Most businesses only wish they had an audit log the day they need one. A customer disputes an order change, a record vanishes, or a figure in a report looks wrong, and nobody can say how it happened.

With a proper log, these questions take minutes rather than days. You can see that an admin updated a field at 14:32, or that an integration overwrote data overnight, and move straight to fixing it.

It also changes behaviour. When your team knows actions are recorded, accidental sloppiness drops and genuine mistakes become easier to catch early.

Where it earns its keep

Audit logs matter most anywhere money, personal data, or permissions are involved. Ecommerce order edits, refunds, pricing changes, user role changes, and data exports are all worth recording.

For businesses handling personal data, logs support your obligations under UK GDPR. If there's ever a question about who accessed what, you have evidence rather than assurances.

They are also invaluable for team accounts with multiple users. The larger the team, the harder it is to know who touched what, and the more a log repays the effort of building it.

Doing it properly, not just ticking a box

A good audit log is tamper-resistant and append-only. If a user can quietly edit or delete the record of their own actions, the log is worthless at the exact moment you need it.

Record enough context to be useful: the actor, the action, the affected record, the before and after values where it matters, and a reliable timestamp. A line that just says "record updated" rarely helps.

Equally, don't log everything. Capturing every page view or trivial action creates noise that buries the entries that actually matter, and can itself become a privacy liability.

The honest caveats

Audit logs are not free. They add storage, need a retention policy, and require thought about who can read them, since the log itself often contains sensitive information.

They are also not a substitute for good permissions. A log tells you someone did something they shouldn't have; it doesn't stop them. The two work together, not in place of each other.

And if nobody ever looks at the log or sets up alerts, it becomes a silent archive. The value comes from making it searchable and, for the riskiest actions, actively monitored.

Building it in from the start

Audit logging is far easier to design in early than to bolt on after launch, when you're trying to reconstruct history that was never recorded. If you're building anything handling data, money, or user accounts, it's worth planning now.

We build audit trails into the bespoke platforms and applications we develop, sized sensibly to the risk rather than logging for its own sake. If you're not sure what your system should be recording, we're happy to talk it through.

Related reading: the security basics every web app needs.

Thinking about this for your business? Contact us.