An audit log is only evidence if it cannot be edited. That is the entire value proposition, it is what a security reviewer is checking for, and it is why append-only appears in every design document on the subject.
Then a deletion request arrives, and personal data in that immutable record is now in tension with an obligation your legal team cannot negotiate away. The conflict is real, but it is much smaller than it first appears, and almost all of the difficulty comes from having written more into the log than the log ever needed.
Store references, not copies
An audit entry has to answer who did what, to what, when, and from where. None of those require a copy of the person's name and address embedded in the row. An actor identifier resolves to a user record; a target identifier resolves to a resource. The log holds the relationships, and the personal data lives once in the tables built to manage it.
That single decision converts the erasure problem into an ordinary one. Deleting or anonymising the user record removes the personal data from the system; the audit entries remain intact, still enumerate the actions, and still support an investigation, with an actor who now resolves to a deleted subject rather than to a name. The chain of events is preserved, which is what the security requirement actually asked for.
The requirement is that the record of an action cannot be altered. It was never that the record must contain the person's name.
What leaks in anyway
The identifiers are the easy part. Personal data arrives through the fields nobody classified: an address in the target of an invitation event, a device string, an address in a search query captured for debugging, a free-text description generated by string interpolation. Diff payloads are the worst offender, because a before and after of a profile edit is precisely a snapshot of personal data, sitting in the one table you promised never to modify.
Decide what a diff may contain rather than recording the whole object. Field names changed, without values, is enough for most audit purposes and carries almost no data. Where values genuinely matter — a permission or a role changed — record those specific fields by name. And treat network addresses honestly: they are personal data in most jurisdictions, they are also the most useful signal in an investigation, so give them their own retention period rather than pretending the question does not exist.
- Never interpolate user-controlled text into a log message; put it in a typed field or drop it
- Record which fields changed rather than their before and after values, unless the value is the point
- Treat network address and device string as personal data with their own retention clock
- Classify every field when it is added, not during the compliance review a year later
Two clocks, and they are not the same clock
Retention and erasure look similar and behave differently. Retention is a schedule you run: entries older than a stated period are removed or aggregated, uniformly, without anyone asking. Erasure is a request about one person, arriving at an unpredictable time, and it must be satisfied without disturbing everybody else's records.
Keeping them separate makes both simpler. Retention becomes a job over a timestamp index. Erasure becomes an operation on the user record and any denormalised copies, leaving the log structurally untouched. Where a legal basis lets you keep certain security events beyond an erasure request — and there usually is one for exactly this — write down which categories and why, because that is the sentence a reviewer will ask you to produce.
Crypto-shredding, and its honest limits
Where personal data genuinely must sit inside an immutable record, the standard technique is to encrypt it under a key held per subject and destroy the key on erasure. The ciphertext remains, the row is unmodified, and the content is unrecoverable. It satisfies both constraints on paper and it is a legitimate design.
It is not free, and the limits are worth stating plainly to whoever proposes it. You now have a key per subject to store, back up and rotate, and a backup taken before the key was destroyed still contains a recoverable copy unless the backup encryption is arranged with the same care. Structure and metadata around the ciphertext can re-identify a person on their own. Use it where it earns its keep, and reach first for the far cheaper option of not putting the data there.
- One key per subject, and a documented plan for backups taken before destruction
- Remember that timestamps, addresses and sequence can re-identify without any plaintext
- Reading the audit log is itself an event worth recording, especially by your own staff
- Give customers export and their own retention control; it answers several questionnaire rows at once
Everything here, already built
Sign-in, enterprise SSO, directory provisioning, roles and an audit trail behind one API. Start with the quickstart and have a working sign-in this afternoon.