How do you make a stored compliance evidence record tamper-evident to an auditor?

## The objection you are answering In a walkthrough, an auditor's second question — after "show me the record" — is "how do I know this was not edited afterwards?". A screenshot cannot answer it, and neither can a database row that the team operating the control can update. Tamper-**evidence** is the achievable goal: you cannot stop a sufficiently privileged person from trying, but you can arrange things so that any change leaves a mark somebody else will see. ## Layer one — the individual record Serialise the record canonically (a fixed field order and encoding, so the same content always produces the same bytes), hash it, and store the hash. Now an edit to any field changes the hash. On its own this is weak, because whoever can edit the record can also recompute and rewrite the hash. It matters as the building block for the layers above it. ## Layer two — the sequence Hash chaining fixes the weakness that a per-record hash cannot see deletions. Each record includes the hash of the previous record in the store, so the records form a chain. Now three things become detectable: editing a record breaks every hash after it, deleting a record leaves a gap where a predecessor hash points at nothing, and reordering breaks the same links. Verification is mechanical and anyone can do it — walk from the first record forward, recompute, compare. The honest limitation: a chain is only as good as its anchor. If the party who can edit records can also rebuild the whole chain from scratch, they can produce a perfectly valid chain that tells a different story. Chaining detects *tampering with a chain you already trust the head of*; it does not by itself prevent wholesale re-creation. ## Layer three — anchoring the chain to a time you cannot move So the head has to be committed to somewhere outside the producer's control, at a time that cannot be backdated. In practice that means one or more of: signing the chain head with a key the pipeline holds only for the duration of the run and cannot use again; sending the head to a system administered by a different team; or timestamping it with an external timestamping service. The property you want is simple to state — at the end of March, a value existed that fixes every record written up to that point, and it was witnessed by somebody who is not you. ## Layer four — storage that refuses to forget All of the cryptography is a detection mechanism. Retention is a prevention mechanism. Write evidence to append-only, write-once storage with an object-lock retention period, set from the framework's required retention for that control's evidence, and grant the producing pipeline append-only permission. Inside the window, the object cannot be overwritten or deleted, including by an administrator. Two consequences to be honest about in an interview: you are committing to pay for that storage for the whole window, and you cannot delete an object you later regret writing — so do not put anything in the record that you would need to remove, and think about what a legal hold on top of the retention lock would mean. ## Who holds the key A signature is only as meaningful as the answer to "who could have produced it?". If the signing key sits in an environment variable in the same pipeline that produces the evidence and can be read by anyone who can edit that pipeline, the signature adds ceremony rather than assurance. Keep the key in a managed key service where use is logged and the identity that used it is recorded, issue it to the workload for the run rather than to people, and separate the ability to administer the key from the team that operates the control. ## What this does and does not prove It proves that the object you are looking at is byte-for-byte what was written, at the position in the sequence it claims, before the anchoring event. It does **not** prove the record was accurate when it was written — that depends on where the input came from and whether it faithfully described the resource. It also does not prove that all the records exist that should exist; completeness is a question about the population being evaluated, not about integrity. A candidate who runs these three claims together is making the most common mistake in this area: treating an integrity mechanism as though it validated content. ## Making verification somebody else's job The last practical step is to hand the auditor the procedure rather than the conclusion. Document the canonicalisation, publish the verification key, and provide a tool that recomputes and walks the chain. Evidence you have to interpret for the auditor is weaker than evidence they can check without you in the room.