"Tamper-proof" gets thrown around in audit-log marketing the same way "military-grade" gets used in encryption marketing — loosely, and usually by products that don't quite earn the label. It's worth being precise about what it actually means, because the distinction matters in exactly one situation: when something has gone wrong, and someone needs to prove what happened to a regulator, a court, or a customer's lawyer.
The naive version: an append-only table
The most common starting point is a Postgres table with no UPDATE and no DELETE permissions for the application user. Events go in, nothing comes out except via reads. This is a fine first step. It's not tamper-proof.
The reason: the database administrator can still delete rows. The cloud provider's support team can restore a backup that omits inconvenient events. A determined insider with write access to the underlying disk can rewrite history and you'll have no way to prove they did. Append-only-by-convention is a trust statement, not a guarantee.
For most internal use cases, that's fine. Audit logs are read by the team that runs the system, and the team trusts itself enough not to require cryptographic guarantees against itself. But the moment a third party — a customer, an auditor, a regulator — is the audience, "just trust us" stops being a satisfactory answer.
Hash chains, briefly
The fix is older than computers. Each event is hashed, and that hash is included as an input to the next event's hash. If anyone modifies an event after the fact, the chain breaks: the modified event's hash no longer matches what the next event used as input, and every event from there onward is invalidated.
event 1 → hash(event_1) = h1
event 2 → hash(event_2 + h1) = h2
event 3 → hash(event_3 + h2) = h3
...
Verifying integrity is a single pass: walk the chain from the beginning, recompute each hash, confirm it matches. If anything was tampered with, the recomputation diverges at exactly the modified event. You can point to it precisely.
Why a regular database can't do this for you
A database can store the chain — it's just a column on each row — but it cannot compute or guarantee it. Hashing has to happen at ingest, in code that the application controls, before the event lands in storage. If the database is the one that hashes, then the database administrator is also the one in control of the chain, which puts you back where you started.
The hashing happens in your service. The hash gets stored alongside the event. Verification can happen anywhere — by the customer, by the auditor, by anyone with read access to the events.
What independent verification looks like
This is the part that distinguishes a serious implementation from a checkbox one. The audit log should expose an endpoint — call it /verify — that returns the chain's current state and lets any caller recompute it. The output is binary: every event verified, or here is the index where verification failed.
A customer's security team running this against their own data, weekly, with the result feeding into their existing monitoring, is the gold-standard answer to "how do you know your audit logs haven't been tampered with?" It's also the answer that closes deals with financial services and healthcare buyers, who are required to ask the question and very tired of vendors who don't have a real answer.
What auditors actually want to see
A SOC 2 Type II auditor isn't going to read your hash chain code. They will ask: who has the ability to modify or delete audit events? What controls prevent that? How would you detect tampering if it occurred? How is integrity verified, and by whom?
The answers that satisfy them, in order:
- A list of identities (human and service) with write access, kept short.
- An append-only storage layer plus a hash chain that provides detection independent of access controls.
- A verification endpoint that any party can run.
- A scheduled job that runs the verification and alerts on failure, with an evidence trail of past runs.
The first two are about prevention. The last two are about detection. SOC 2 wants to see both, because access controls fail and the audit log needs to detect that failure even when the team that runs it is the team that bypassed it.
When you don't need this
Internal tools, low-stakes consumer products, anything where the audit log is a debugging aid rather than a compliance artifact — none of this is necessary. An append-only table with sensible access controls is fine. The cryptographic chain only earns its keep when you're going to be asked to prove integrity to someone who isn't on your team.
But once that conversation starts — usually around the first enterprise contract — having the chain already in place is the difference between answering the question in five minutes and adding a quarter to your roadmap.