Tamper-Evident Audit Logs and Hash Chains

Why a plain log isn't enough

An audit log answers "who did what, when." But an auditor's follow-up question is sharper: how do I know this log wasn't edited after the fact? A regular database table full of audit rows is trivially mutable. Anyone with write access — or a compromised attacker — can UPDATE a row, DELETE an incriminating event, or backdate an entry. If the log can be silently rewritten, it proves nothing about the past. Tamper-evidence is the property that fixes this.

Note the word: tamper-evident, not tamper-proof. You generally cannot make data impossible to alter. What you can do is make any alteration detectable. That distinction is the whole design.

Hash chains, briefly

The core technique is a hash chain, the same idea underneath blockchains but far simpler in practice. Each log entry stores a cryptographic hash computed over its own contents plus the hash of the previous entry:

hash(n) = SHA-256( entry(n) || hash(n-1) )

Because each hash folds in the one before it, the entries form a chain where every link depends on all the links behind it. Change entry 500's contents, and its hash no longer matches — and so does every hash from 501 onward. A single edit anywhere invalidates the entire tail of the chain. You cannot quietly fix one row; you would have to recompute every subsequent hash, and if you have published or externally anchored any later hash, even that fails.

Making it append-only

The hash chain gives you detection. Append-only storage reduces the opportunities to tamper in the first place. In Postgres you can approximate this with:

• Revoked UPDATE/DELETE privileges on the audit table for application roles; only INSERT is granted.
• Triggers that reject any UPDATE or DELETE outright.
• Computing each row's hash in the insert path so the chain is maintained automatically.

Append-only plus hash-chained is the combination auditors like: the design discourages tampering, and the chain catches it if someone with elevated privilege does it anyway.

Anchoring for stronger proof

A chain proves internal consistency, but an attacker who can rewrite the entire table could recompute every hash and rebuild a plausible fake chain. The defense is anchoring: periodically publish the latest hash somewhere the attacker cannot retroactively change — a separate append-only store, a signed daily digest emailed to auditors, a trusted timestamping service, or a public ledger. Once hash(N) is anchored externally, no one can rewrite history up to N without contradicting the anchor. Even a modest anchor, like recording the day's tip hash in an out-of-band system, dramatically raises the bar.

What it proves — and what it doesn't

Be honest about the guarantees, because overclaiming is its own risk:

• It proves the log has not been altered since it was written, and that no entries were deleted or reordered within the chained range. Given an anchor, it proves this even against a privileged insider.
• It does not prove the entries were truthful when written. Garbage in, cryptographically-preserved garbage out. If your application logs the wrong actor, the chain faithfully protects that mistake.
• It does not prevent tampering; it makes tampering visible. Detection still requires that someone actually verify the chain.
• It does not, alone, prove timing. Sequence is preserved, but wall-clock time is only as trustworthy as your timestamp source and any external anchoring.

Where this fits compliance

HIPAA's integrity requirement and SOC 2's monitoring and logging criteria both benefit from audit trails you can demonstrate are intact. A hash-chained, append-only log turns "trust us, we didn't edit it" into "here is the verification, run it yourself." That is a far stronger position in front of an auditor or an incident investigator. KollGuard uses append-only, hash-chained audit records for exactly this reason: so the trail of findings and actions carries its own tamper-evidence rather than relying on trust.