The Right to Erasure in a System With Backups and Event Logs

“We deleted the record” and “the record is genuinely, verifiably gone” are two different claims, and the gap between them lives almost entirely in backups and event logs — the two categories of data store that GDPR’s right to erasure assumes exist and that most erasure processes quietly fail to actually address.

I’ve written about GDPR as an architecture constraint generally. This is the specific, hard technical case that most erasure implementations get wrong: deleting a record from the primary application database is the easy ninety percent of the problem, and the remaining ten percent — backups and event logs — is where most organisations’ actual erasure capability quietly stops working.

Why backups genuinely resist deletion

A backup is, by design, an immutable snapshot — its entire value as a backup depends on it not changing after it’s taken, which is directly in tension with a request to selectively remove one record from it. Genuinely deleting a specific record from an existing backup, rather than waiting for that backup to age out of the retention window naturally, requires either restoring the backup, editing it, and re-saving it — expensive and operationally risky at any real scale — or accepting that the erasure isn’t complete until every backup containing that record has cycled out of retention.

The regulatory position on this specific tension is more pragmatic than most organisations assume: GDPR guidance generally accepts that data within existing backups can remain, isolated from active processing, until the backup’s normal retention cycle completes, provided the data isn’t restored or actively processed in the meantime. The requirement isn’t instantaneous removal from every physical copy — it’s a genuine, documented process ensuring the data becomes inaccessible for any active purpose and is removed as backups naturally cycle, not left indefinitely reachable under the excuse of “it’s just in a backup.”

Why event logs are the harder problem

Event logs and audit trails present a genuinely different challenge, because the log’s entire value — for security monitoring, for compliance evidence, for the audit-readiness discipline I’ve written about separately — often depends on retaining a complete, unaltered record of what happened, including references to specific individuals. Deleting a user’s identifier from a security log to satisfy an erasure request can simultaneously undermine the log’s evidentiary value for a genuine security investigation that hasn’t happened yet.

The workable pattern separates identity from event: pseudonymising the personal identifier in the log while preserving the event record itself — what happened, when, through which system — satisfies erasure’s intent by removing what makes the record about a specific identifiable person, without destroying the operational and security value the log exists to provide. This requires the log’s schema to have been designed with that separation in mind from the start, which is precisely why this belongs in the architecture, decided before the system is built, rather than attempted as a retrofit on a log format that was never designed to support it.

What a retrofit actually cost one organisation

A membership platform received its first substantial volume of erasure requests only after several years of operation, and discovered its security event logs had never separated identity from event — user IDs were embedded directly throughout, with no pseudonymisation layer and no clean way to redact them without potentially breaking the referential integrity other parts of the security tooling relied on. Building the separation retroactively required a genuine schema migration across years of accumulated log data, run carefully to avoid breaking active security monitoring during the transition. The same separation, designed into the logging schema from the platform’s first release, would have cost a modest amount of additional design time and none of the retrofit’s risk.

Why this all has to be designed, not discovered

An organisation that discovers, mid-erasure-request, that its backup and logging architecture was never built with this separation in mind is facing a considerably harder and more expensive problem than one that designed for it from the start — the same asset-visibility problem I’ve written about for GDPR generally, concentrated specifically in the two data categories every erasure process eventually has to confront.

Assessing whether a specific system’s backup and logging architecture can actually support a genuine, defensible erasure process — before a real request tests it — is exactly the kind of architectural gap analysis a technology control assessment is built to run.

Most organisations have never actually tested their own erasure process against a real request until the first one arrives — which is precisely the wrong moment to discover the backup and logging gap this piece describes.

A deliberate test — a genuine, low-stakes erasure request run against the actual system before a real one arrives — surfaces these gaps on a schedule the organisation controls, rather than one a data subject controls.

Erasure is one specific case of a much broader principle — see GDPR as an architecture constraint, not a legal footnote.

That test costs little and is worth treating as a standard part of any genuine audit-readiness practice, alongside the restore tests and access reviews already covered elsewhere on this site.