Tamper-evident audit logs: what they are, why they matter

A tamper-evident log is a log stored in a way that makes any later alteration detectable: an edited record, a deleted record, or a reordered sequence breaks a cryptographic structure that anyone can recompute. An ordinary audit log records what happened. A tamper-evident log does that and additionally proves the record has not changed since. The distinction sounds small and is not, because it is the difference between evidence an auditor must take on trust and evidence they can check by computation.

This explainer covers what tamper evidence actually means, why ordinary audit logs fail the scrutiny they are increasingly put under, how the cryptographic machinery works in plain terms, and what the property does and does not buy you. It is written for the engineer or compliance lead who keeps meeting the phrase in framework language and vendor copy and wants the substance behind it.

What does tamper-evident actually mean?

A tamper-evident log is a chronological record of events stored with cryptographic structure, typically a hash chain and periodically signed checkpoints, such that any alteration, deletion, or reordering of past records is detectable by recomputation.

Three neighbouring terms get used interchangeably and should not be, because they make different claims:

The counterintuitive part is that the weakest-sounding claim is the strongest position in front of an auditor, regulator, or counterparty. Tamper-resistant and tamper-proof are claims about what should not have been possible, and both ultimately rest on trusting whoever operates the storage. Tamper-evident is a claim about what can be checked, and checking requires trusting nobody. The properties also compose: a tamper-evident log kept on write-once storage with restricted permissions is better than any one alone. But if you can only make one claim about your records, detectability by computation is the one that survives hostile questioning.

Why ordinary audit logs fail scrutiny

The default audit log in most software is a table in the application's own database, written by the application, administered by the same team whose actions it records. Anyone with production database access can rewrite that history in one statement, and nothing would notice. This is not a theoretical concern in either of the two situations where audit logs actually get examined.

The first is an audit or investigation. The auditor's sharpening question, covered in our guide to preparing SOC 2 audit evidence, is no longer "do you have logs" but "how do you know these records are the records". A log that the operations team could have quietly edited carries the evidential weight of the operations team's word, however honest that team is, because the auditor has no way to distinguish the honest case from the other one.

The second is an actual incident. Deleting or doctoring logs to cover tracks is standard attacker tradecraft and the first move of a malicious insider, and the insider case is the one access controls cannot solve, because the people being audited are frequently the people who hold the access. A log protected only by permissions answers the question "who could have altered this" with a list of names, and the list is never empty.

Compliance frameworks have converged on the same worry from different directions. PCI DSS requires change-detection mechanisms on log data itself. ISO 27001 requires logs to be protected against tampering. SOC 2 auditors must judge whether records can be relied on. The SEC's 2022 amendments to Rule 17a-4 added an audit-trail alternative to WORM storage that effectively describes a tamper-evident log, covered in detail in our Rule 17a-4 guide. The full mapping across frameworks is in our guide to audit log requirements. None of them mandates a specific technique, but each is asking the same question, and "the table has restricted permissions" is a weakening answer to it.

How cryptography makes a log tamper-evident

The machinery is three ideas stacked on each other, each covering a gap the previous one leaves.

Hash chaining links each record to all history before it. Every event is hashed, and each event's hash incorporates the hash of the event before it. The consequence is that no record can be edited, removed, or reordered in isolation: any change to a historical record changes its hash, which changes the next record's hash, and so on to the end of the log. Recomputing the chain from the start and comparing against the stored values reveals both whether history is intact and, if not, the exact record where it broke.

Merkle trees make proofs practical at scale. A hash chain proves integrity of the whole log, but proving that one specific event is part of the log should not require recomputing millions of hashes. A Merkle tree hashes events pairwise up to a single root, and an inclusion proof, a path of hashes from one event up to that root, shows a specific event is committed under the root using only a handful of hashes. Consistency proofs do the same job between two points in time, showing a later log still contains everything the earlier one did, in the same order, which is how deletion of an entire range gets caught.

Signed checkpoints pin the history to a moment and an identity. A hash chain alone could be quietly recomputed end to end by whoever operates the log. So the log periodically seals recent events into a checkpoint, and the checkpoint's Merkle root is signed with a private key, giving a compact, dated, cryptographically attributable statement: this was the state of the log at this moment. Once a checkpoint has been signed and shared, the history under it cannot be rewritten without producing a signature mismatch. Anchoring checkpoints externally, publishing them to a transparency feed or a timestamping service, closes the remaining loop by putting copies where the operator cannot retro-edit them.

This is the design Sigilbase implements as a service: every event is SHA-256 hash-chained on write, sealed into Merkle checkpoints signed with Ed25519 keys, and exportable as an evidence bundle that an auditor verifies offline with an open-source standalone verifier, so the integrity claim rests on computation rather than on trusting us or you.

Traditional logs vs cryptographically secured logs

The last row is the practical difference. Both logs may well contain identical, equally honest records. Only one of them can prove it.

What tamper evidence does not do

The property is precise, and overselling it undermines the credibility it exists to provide. A verified log proves the records have not changed since they were written. It does not prove the records were true when written: a system that logs a falsehood logs it immutably. It does not identify people, since the actor field contains whatever the writing system claimed. There is a window between an event being written and being sealed into a signed checkpoint, and tamper evidence covers the sealed history, not that gap, which is why short sealing intervals matter. And a verified export proves the exported range is intact, while proving the range is the whole story additionally needs consistency proofs or external anchoring. Any vendor, ourselves included, should be able to state these limits plainly; treat it as a red flag when one cannot.

Where to start

If your audit logs are currently a database table, the ladder runs from restricted write permissions, through write-once storage, to cryptographic tamper evidence, and each rung is a real improvement over the one below. Which rung your records need depends on who will examine them and how hostile the examination might be: internal debugging can live low on the ladder, while records that will face an auditor, a regulator, or a dispute counterparty belong at the top. For the build-it-yourself path, we have a companion guide to implementing provable audit logs that walks the design step by step; for the evaluation path, our comparison of cryptographic audit log solutions covers the managed services and open-source building blocks side by side. Whichever you choose, the guarantees only cover events that arrive, which is why the producer side, covered in our audit event ingestion API best practices, matters as much as the log behind it.

Primary sources worth reading: the PCI DSS standard (Requirement 10), ISO/IEC 27001:2022 (Annex A 8.15), and the AICPA Trust Services Criteria. For how the mechanisms above translate into framework language, see our guide to audit log requirements for SOC 2, ISO 27001 and PCI DSS.