Tamper-Evident Audit Trails: How Hash Chaining Works
A hash-chained audit trail seals every record to the one before it: each entry's fingerprint is computed from the previous entry's fingerprint plus its own content — so editing any historical record breaks every fingerprint after it, visibly.
A normal log records events and trusts the recorder; a hash chain records events and verifies itself. This guide explains the mechanic and why it matters for evidence. The product doc: Unbroken Audit Trails; the control context: internal controls.
How the chain works, step by step
- Request submitted — record 1 created; its hash is computed from its content
- Approval logged — record 2's hash is computed from record 1's hash + record 2's content
- Every subsequent action extends the chain the same way
- Anyone edits or deletes record 1 — every hash from record 2 onward no longer matches
- The tamper is detected, not prevented: the chain doesn't stop the edit; it makes the edit impossible to hide
Why "detect" is the honest word
Vendors say "tamper-proof"; no system fully earns that word. The defensible property is tamper-evidence: an integrity check that any auditor can re-run, catching any change after the fact. Combined with the rule that no role — including administrator — can edit records in normal operation, the practical result: history stays history. And when corrections happen, they append rather than overwrite: Smart Revoke.
Frequently Asked Questions
What is a hash-chained audit trail?
A record sequence where each entry's cryptographic fingerprint incorporates the previous entry's — making any retroactive edit detectable across everything after it.
Can administrators edit the audit trail?
Not in a properly designed system — no role holds that power, and the chain would expose it if they did. Ask vendors this question directly.
Approvdit's audit trail is SHA-256 hash-chained — every action sealed to the last, tampering detectable, no role exempt. Book a live demo.