Audit trail: proving what happened without relying on memory

An audit trail answers a question that arrives late and urgently: who did this, when, and what did it look like before. It is the difference between an answer and a reconstruction — and reconstructions made from memory and inbox searches are both slow and, in any dispute, worth very little.

What an audit trail has to capture

• Who — an identified individual, which is why shared logins destroy the whole mechanism.
• What changed, including the previous value. "Record edited" is a notification, not a trail.
• When, with a timestamp in a known timezone, because hours matter in a dispute.
• Where from, where it is relevant — the device, address or integration that made the change.
• Why, where your process requires a reason: approvals, deletions, overrides.
• Failed attempts as well as successful ones. The pattern of refused access is often the more interesting record.

The mistake that makes one worthless

Letting the people whose actions are recorded edit or delete the record. An audit trail that an administrator can quietly amend proves nothing, and that is precisely what an external reviewer tests first. Append-only is the property that matters — corrections are added as new entries rather than by changing old ones, and even deleting a record is itself an entry. If your trail does not have that property, say so honestly rather than describing it as an audit trail.

Record deletions most carefully of all. An unlogged deletion and a data loss look identical afterwards, which is why "the record is gone" is a far worse position than "the record was deleted on this date by this person for this reason".

How long to keep it

1. Match the retention of the trail to the retention of what it describes, at minimum — a record kept for seven years with a trail kept for ninety days is unevidenced for most of its life.
2. Keep access logs long enough to investigate something discovered late; breaches are typically found months after the fact.
3. Store the trail separately from the data it describes, so one deletion does not remove both.
4. Decide who may read it, because a trail is itself sensitive — it shows who looked at what.
5. Test retrieval once a year: produce the full history of one record and time it.

What it is not for

It is not a performance management tool, and using it as one is the fastest way to lose the organisational consent it depends on. The moment people believe the trail exists to catch them, they work around the systems that produce it — and the trail stops describing reality, which is the only property that made it useful.

Ettex Records keeps the change history per record with the person, timestamp and previous value, alongside the data rather than in a separate system. Where the question is who opened something rather than who changed it, access logging in storage answers the other half, and most real investigations need both.