Tamper-Evident Audit Log

A tamper-evident audit log is a record of system activity constructed so that any alteration after the fact can be detected. It does not prevent modification — it makes modification visible, usually by chaining each entry to a cryptographic hash of the one before, so that changing any entry breaks every hash that follows.

Why an ordinary log is not enough

Most logs are files, and a file can be edited by anyone with sufficient privilege — including, in the scenario that matters, an attacker who has just obtained that privilege, or an insider with a reason to remove a line. A log that can be silently rewritten proves what happened only if nobody wanted it to say otherwise.

That gap is tolerable for operational logs and not for evidence. When a supervisor asks what a system permitted on a given date, the answer is only worth as much as the assurance that the record was not adjusted before they asked. This is the difference between telemetry and evidence, and it is why runtime governance treats the record as part of the enforcement operation rather than a byproduct of it.

How it works

The common construction is a hash chain. Each entry includes a hash of the previous entry, so the log forms a sequence in which any modification invalidates everything downstream. Detection is then a matter of recomputing the chain.

Three properties turn that mechanism into something usable as evidence. Append-only storage, so the ordinary path cannot rewrite history. Independent anchoring — periodically publishing a digest somewhere the log operator does not control, which is what prevents an operator with full access from reconstructing a consistent but false chain. And completeness, meaning a gap is as detectable as an edit; a chain proves entries were not altered, not that entries were not omitted, unless sequence is enforced.

What each entry has to carry is equally important: the actor including when the actor is an agent, the policy version in force, the decision, and the time. A record that omits the policy version can show what happened but not what rule produced it.

What it is for

The use case is examination rather than debugging. A supervisor under FINRA Rule 3110 asking who supervised a piece of conduct, an auditor testing whether a documented control actually operated, an incident investigation establishing what an agent was permitted to do before it did something unexpected — all three require a record whose integrity is demonstrable rather than asserted.

Retention follows the regulation rather than the storage budget, which is why a vendor-imposed retention ceiling is a governance constraint and not a pricing detail: HIPAA documentation runs to six years, SOX to seven, and several supervisory contexts longer. The mechanism is documented here, its use in examination readiness here, with sample examination reports showing the output and policy as code supplying the version identifier each entry carries.

Related terms

Policy as code · FINRA Rule 3110 · NYDFS Part 500 · Runtime governance · Full glossary