Tamper-Evident Audit Trails: Why Timestamps Aren't Enough
A log file is not an audit trail. Here's why hash-chained records are the only way to prove a document wasn't accessed between events.
"We keep an audit log" is not the same as "we have a tamper-evident audit trail." The difference matters if you ever need to prove something in court, or in front of a regulator.
The problem with plain logs
A standard audit log is a list of events: user X viewed document Y at time Z. Useful for debugging but weak as evidence. Why? Because a plain log can be edited. Anyone with database access can modify a timestamp, delete an entry, or insert a fake one, and you'd never know. In a legal or regulatory context, a log is only as trustworthy as the person or system maintaining it — which is a problem when the very person you might be investigating controls the log.
Enter hash chains
A tamper-evident audit trail uses cryptographic hash chains to make retroactive edits detectable. The idea is simple: each new log entry includes the hash of the previous entry. So entry 5's hash depends on entry 4, which depends on entry 3, all the way back to the beginning.
If someone modifies entry 3 — changes a timestamp, deletes a view event — the hash of entry 3 changes, which means entry 4's reference is now invalid, which breaks the chain at entry 5, 6, 7, and every subsequent entry. You can't edit one entry without rewriting every entry after it.
How we implement it
ShareAndGo's audit trail uses SHA-256 hash chaining per data room. Every audit event (view, upload, download, permission change, NDA acceptance) gets a hash computed from the event data and the hash of the previous event. The hashes are stored alongside the events. Verifying integrity is fast: walk the chain from the beginning and confirm each hash matches. If any single entry has been tampered with, verification fails at that point.
Breaking this would require either compromising the database AND recomputing every hash from the tampered point forward, OR compromising our signing infrastructure, OR both. It raises the bar from "any database admin can cheat" to "nation-state-level compromise required."
Why this matters in practice
You probably don't need this for most day-to-day use. But when a client pushes back on "did you send me this document?" and you need to prove it was viewed from their IP at 3:47pm on 14 March, you want a log that can stand up in front of a regulator. Regular logs can't; hash-chained trails can.