Who Changed This?

Something is wrong. A price is off, a record got deleted, an account has permissions it shouldn't, and the only question that matters is the simplest one: who did this, and when? You go looking for the answer, and it isn't anywhere. The change happened, the system dutifully applied it, and it kept no memory of who asked or why. That's the moment you wish you'd built auditing, and it's always a moment too late.

Logging is not auditing

These get conflated, and they shouldn't be. Application logs are for developers: a running commentary of what the system did, useful for debugging, noisy, and usually thrown away after a few weeks. They answer "why did the server error at 2am."

An audit trail is a different thing with a different job. It's a durable, trustworthy record of who did what to which piece of data, and when. It answers "who changed this customer's plan," months later, to someone who isn't a developer and may be a lawyer. Logs are for diagnosing the system. Audits are for holding people accountable, and that difference drives every decision about how you build them.

Who, what, when, and to what

The anatomy of an audit entry is small and worth getting right. Every entry answers four questions: who did it, the actor, an actual identity, not "the system"; what they did, the action; what they did it to, the specific record; and when. The genuinely useful ones add a fifth, the before and after, so you can see not just that a value changed but what it changed from and to.

Get those five and you can reconstruct the story of any record: created here, edited there by this person, deleted by that one. Miss the actor, or miss the before-and-after, and you have a note that something happened, which is nearly useless in the moment you actually need it.

Append-only, or it isn't a trail

Here's the property that separates a real audit trail from a table that pretends to be one: it has to be append-only. You add to it, and you never edit or delete what's already there. If someone can quietly alter the audit record, then it isn't evidence anymore, it's a suggestion, and the first thing a bad actor does after doing the thing is erase the record of having done it.

In practice that means the audit log lives somewhere its own application can't rewrite: a separate store, restricted permissions, no update and no delete, sometimes shipped off to a system the main app can't touch at all. It should be at least as hard to tamper with the trail as it is to do the thing the trail records. Otherwise you've built a lock with the key taped to it.

Don't log the secret

One trap worth naming, because it turns a safety feature into a liability. An audit trail is a detailed, permanent, high-value record, which makes it a target and a compliance problem if you fill it with the wrong things. Don't write passwords, full card numbers, or sensitive personal data into it. Record the fact and the reference, that this actor changed this field on this record, not the secret contents. The trail should tell you what happened without becoming the juiciest thing to steal in the whole system.

Build it before you need it

The thing about all of this is that you cannot add it retroactively. You can't audit what already happened, only what happens from now on. And the demand for it arrives without warning: a dispute, a breach, a "who deleted the account," a regulator, a customer swearing they never authorized something. On that day, the trail either exists or it doesn't, and there is no building it backward.

So the move is to decide, early and deliberately, which entities actually matter, the money, the permissions, the things people will one day argue about, and record who-what-when-and-what-changed for those from the start. It's a little work up front for a question you can't yet see coming, but will. Auditing is insurance, and like all insurance, the only time to buy it is before.