What “tamper-evident” actually means for an audit log
Every reconciliation vendor says they have an audit log. Few can prove it wasn't edited. Here's what tamper-evident really requires — append-only storage, hash chaining, and a verify step — and what to ask a vendor.
"We have a full audit log" is one of those claims that sounds like a control but often isn't. An audit log you can quietly edit — or that an admin with database access can rewrite — is evidence of nothing. For reconciliation, where the log is the record of who decided a payment matched, that distinction matters to your regulator.
Append-only is the floor, not the ceiling
The first requirement is that audit records can be inserted but never updated or deleted. The strongest place to enforce that is the database itself — triggers that block UPDATE and DELETE on the audit table — so even application bugs or a direct SQL session can't quietly change history. Application-level "we don't expose an edit button" is not the same thing.
Hash chaining makes tampering detectable
Append-only stops the obvious edit. Hash chaining catches the determined one. Each record (or batch) is sealed with a cryptographic hash — typically SHA-256 — that incorporates the hash of the previous one. The records form a chain: change any entry and every hash after it no longer matches.
- An attacker can't alter one record without re-computing the entire chain after it.
- You can periodically anchor the chain so even a full-table rewrite is detectable.
- It works regardless of who has database access — the maths, not the permissions, is the control.
Hashing is useless if nobody ever checks it. Tamper-evidence requires a verify step — an endpoint or job that re-walks the chain and confirms it's intact. Ask the vendor to demonstrate it catching a row that was changed by direct database access.
What to ask a vendor
- Is the audit table protected from UPDATE/DELETE at the database level, or only in the app?
- Are records hash-chained? With what algorithm, and at what granularity?
- Is there a verify endpoint, and can you show it detecting a tampered row?
- Is every sensitive action logged — logins, uploads, match decisions, disputes, exports — with a UTC timestamp and the actor?
Kilter's audit log is append-only at the database layer, hash-chained under SHA-256 anchors, and ships with a verify endpoint that catches edits made even by direct database access. The full posture is on the security page.