An immutable log and the right to be forgotten

#Why chain the log

An audit log an administrator can edit is evidence of nothing. If the credentials that perform an action can also remove the record of it, the log answers no question worth asking.

Linking each event to its predecessor by hash makes any modification detectable, which is the technique digital timestamping has used since the early 1990s [1] [2]. Change one field and every hash after it fails to match. Delete an event and the chain has a hole at a nameable index.

This does not prevent tampering. Nothing prevents somebody with database access from writing to the database. It makes tampering detectable, which is what auditors are asking about, and it forces an attacker to rewrite every subsequent event plus any exported chain head. Secure audit log design has addressed exactly this adversary for a long time [3].

#Then the lawyer arrives

The right to erasure gives a person the ability to have their personal data removed [4]. An append-only hash-linked log exists to ensure nothing is ever removed. These are not compatible in their naive forms, and I spent a while convinced I was missing a trick.

The resolution is crypto-erasure, and it is not my idea. Personal data in an event is encrypted under a key belonging to that data subject. The event body in the log is ciphertext, and the key lives outside the log.

An erasure request destroys the key. The ciphertext stays where it is with its hash unchanged, so the chain verifies end to end, and the plaintext is unrecoverable by anyone.

You delete the key, not the record. The trail keeps its integrity and the data subject gets an outcome that is, in practice, indistinguishable from deletion.

#Three conditions that are easy to miss

Key destruction has to be real. The claim rests entirely on the key being gone everywhere it existed, including backups of the key store, which is exactly where keys quietly survive. Sanitisation guidance exists because deleted and unrecoverable are different states [5]. I can enforce what the library does. I cannot enforce that your key vault's soft-delete window is not thirty days.

Metadata stays in the clear. Timestamps, actor identifiers, resource types and action names remain readable, because a log you cannot query is not a log. So the fact that a person performed an action at a time survives erasure even though what they did is gone. Whether that is itself personal data is a question for a lawyer, and the answer depends on the data.

Hash algorithms have a lifetime. A chain built today may need verifying in twenty years. The format carries an algorithm identifier so a future chain can start under a different one, and the old segment remains verifiable only under the old algorithm.

#What it buys day to day

Compliance reports become a query rather than a text mining project, because the event shape is fixed: actor, action, resource, outcome, scope, timestamp. Every request to add a free-form field has been refused, and that refusal is why the reports work.

The unexpected benefit was cultural. Once engineers trusted that the log could not have been quietly edited, they reached for it during incidents instead of reconstructing from application logs. It became the first thing consulted rather than something produced for an auditor once a year.