A tamper-evident record is one where a change made after the fact can be detected. It does not stop someone with access from changing the data. It makes the change visible to anyone who checks. A common way to do this is a hash chain, where each entry carries a fingerprint of the entry before it.
This page explains hashes and hash chains in plain language, the limits of the approach, and what a reviewer can actually confirm from a hash-chained record.
What a hash is
A hash function takes data of any length and produces a short, fixed-length output called a hash. NIST's glossary defines it as a function that maps a bit string of arbitrary length to a fixed-length bit string, and notes that a hash can be thought of as a fingerprint of a file or message.
Two properties make hashes useful for records:
- Collision resistance. NIST describes this as it being computationally infeasible to find two different inputs that produce the same output. In practice, that means a changed record produces a different hash from the original.
- One-way. NIST also describes it as computationally infeasible to find an input that maps to a given output. You cannot practically work backwards from a hash to the record.
So if you store the hash of a record today, and someone later changes even a small part of that record, recomputing the hash will give a different value. The mismatch tells you the record is not the one you hashed.
How a hash chain works
A single hash protects a single record. A chain links records together so that a change anywhere shows up from that point on.
- The first entry is written, and its hash is computed and stored with it.
- The second entry is written together with the first entry's hash. The hash of the second entry is computed over its own content and that previous hash.
- Each new entry repeats the pattern: its content, plus the hash of the entry before it, hashed together.
Now suppose someone edits entry two after entry five has been written. Entry two's recomputed hash no longer matches the value stored in entry three. Entry three's hash depended on that value, so it no longer matches entry four, and so on. Anyone who recomputes the chain sees exactly where it breaks.
This suits compliance records well. An audit trail is meant to be a chronological record that lets someone reconstruct a sequence of events, as NIST's glossary puts it. A hash chain adds a way to show that the sequence has not been rewritten since it was recorded.
Tamper-evident is not tamper-proof
The words matter, and it is worth being precise with anyone you show the record to.
- A chain can be rebuilt. Someone with full control of the system could alter an entry and then recompute every hash after it. The usual defense is to keep copies of the hashes somewhere else, such as exports held by the merchant or a third party. If an exported hash no longer matches the live record, the rewrite shows.
- Hashing does not make an entry true. If a buyer makes a false declaration, the chain faithfully preserves a false declaration. It proves the record was not changed, not that its content was accurate.
- Deletion is a separate question. If the whole log and every copy is destroyed, there is nothing left to compare. Independent copies are what make deletion detectable.
- It only covers what enters the chain. Data changed before it was written, or never recorded at all, is outside the protection.
For the same reasons, avoid words like immutable or tamper-proof. They overstate what the technique does, and a careful reviewer will notice.
What it shows a reviewer
Used properly, a hash chain lets a reviewer confirm three things:
- Integrity. The entries match what was recorded at the time, relative to a hash value they trust, such as one in an earlier export.
- Order. Entries appear in the sequence they were written, because each one depends on the one before.
- Completeness within the chain. An entry removed from the middle breaks the links around it.
In principle, a reviewer who has an export listing each entry with its hash, plus a description of exactly which fields were hashed and how, can recompute the hashes and compare them.
Questions to ask about any tamper-evident system
- What exactly is hashed in each entry: the full record, or only some fields?
- Which hash function is used, and is it documented?
- Can you export the entries and hashes, and verify them yourself outside the system?
- How are corrections handled? They should be new entries that reference the original, not edits.
- Where else are hashes held, so that a rebuilt chain would be noticed?
How Claddr uses this
Claddr stores every step of an order, including buyer checks, signatures, holds and payments, against that order, and chains each entry to the one before it, so a change after the fact breaks the chain. The record is tamper-evident, not tamper-proof or immutable. When you export a date range, the CSV lists every entry with its hash, and the PDF summarizes the controls in force. Keeping those exports is part of what makes a later rewrite detectable. If a reviewer wants to recompute the chain independently, ask Claddr which fields are hashed and how.
How Claddr's audit record works covers the export in more detail, and the Claddr security page has more on the platform. For the wider picture of what to record in the first place, see building a compliance audit trail and exporting compliance evidence for a review.