How Does an Audit Trail Become Tamper Evident?

"Our audit records cannot be altered" is a common line in product presentations. When an auditor hears it, the follow up question is always the same: how? This article covers the technical answer to that question and where the answer stops.

Immutable, or Tamper Evident?

The term needs correcting first. A row written to a database can technically be changed by someone with enough privilege. The realistic goal is not to make change impossible but to make it detectable. The industry term for this is tamper evident.

The distinction matters because an immutability claim can be disproved in front of an auditor, and one disproved claim casts doubt on the rest. Saying that any change will be detected and can be verified in a specific way is both true and stronger.

How a Hash Chain Works

When each audit record is written, the content of the record and the digest of the previous record are hashed together. The result becomes this record's digest and feeds into the next one, linking the records to each other.

The value of this structure is that anyone altering a record in the middle must recompute its digest. That digest already fed into the next record, so every digest after it changes too. Silently altering one row is not possible; the whole chain would have to be rewritten.

The second element that strengthens the chain is a key. When the digest is computed with a secret key (a method known as HMAC), someone without the key cannot produce a valid digest. That is why the key must live on the configuration side rather than in the database: whoever reaches the database should not reach the key.

Why a Separate Copy Is Needed

A hash chain makes alteration detectable but does not solve deletion on its own. Someone who deletes the last five records can leave the remaining chain consistent. That is why records should be copied to a second location, ideally one with different access rights.

The copy must contain the complete row. Copying only a few fields leaves the gap of saying that a field was never in the copy anyway. The copy and the main record must be comparable row by row.

Verification: From Claim to Proof

The most important part of the design is an executable verification. It should check three things:

• Is each record's digest consistent with its content?
• Does the chain continue without a break?
• Do the main record and the separate copy match exactly?

The result should not be a binary answer. Instead of pass or fail, it should list the rows that do not match. What matters in an audit is seeing which record broke and where.

Limits Worth Admitting Honestly

A database administrator can do anything. Someone with sufficient privilege can delete rows. A hash chain does not bring them back, it only makes the loss visible. This is why permission management and the separate copy matter more than the cryptography.

If the key is lost, verification is impossible. Key management is the most fragile part of this design. Backup, storage location and rotation procedure for the key should be written down from the start.

An unrecorded action cannot be protected. Even the strongest chain cannot protect a record that was never written. A screen left out of scope or a direct intervention on the database stays outside the chain. The list of which actions produce records deserves more discussion than the cryptography does.

Frequently Asked Questions

What is the difference between immutable and tamper evident?

Immutable claims the record physically cannot be changed; on a general purpose database that claim is usually not true. Tamper evident is a more honest goal: the record can be changed, but the change surfaces in a provable way. The second is what actually helps in an audit.

What happens if a database administrator deletes the audit trail?

A broken chain makes it visible: a gap remains where the record was and the link of the following records can no longer be verified. A copy written to a separate database stops the deletion being completed with a single privilege. Neither makes deletion impossible; together they stop it from going unnoticed.

Is a hash chain enough without a signing key?

It is not. Someone with access to the database can recompute a chain that has no key from end to end and leave no trace. Signing the chain with a key is exactly what stops the person you are trying to catch from rebuilding it. The key must live in the application, not in the database.