Audit trails: the difference between logging and evidence

Logging answers "what broke". Evidence answers "what happened".

Operational logs exist to help engineers diagnose faults. They are verbose, they rotate, they are frequently editable by the people who run the system, and they are usually retained for weeks. Every one of those properties is correct for their purpose and disqualifying for evidence.

An audit trail is a different artefact with different requirements: it records business acts rather than technical events, it is written as part of the act rather than alongside it, and it is retained on the document’s schedule rather than the log server’s.

Append-only, and why it is a schema decision

An audit trail that can be updated or deleted is a table somebody can quietly correct. Making it append-only is not a matter of not writing the update code — it is a constraint enforced by the database, so that a mistake, a migration or a support script cannot do what the application refuses to.

Hash chaining makes tampering detectable rather than merely discouraged

If each entry carries a hash of the one before it, the entries form a chain. Removing or altering an entry breaks every link after it, and the break is arithmetic rather than a matter of opinion.

This does not make tampering impossible; nothing does. It changes the question from "do you trust the people with database access" to "does the chain verify", which is a question anybody can answer for themselves.

The question to ask a vendor

Not "do you have an audit trail" — everybody says yes. Ask whether the audit trail can be edited, by whom, and how you would know if it had been. Ask whether the history shown in the interface is read from the same records an export produces, or from a second table that could disagree with it.