Retention and deletion that is enforced, not documented

Why does a documented schedule not work?

Because it depends on someone remembering, and retention is a task with no deadline and no complainant. A policy stating that support tickets are kept for twenty four months describes an intention; a ticketing system configured to delete at 730 days is a fact. The first survives exactly as long as the person who wrote it stays interested, and the second survives reorganisations.

The regulation is written in outcome terms, which helps here. Article 5(1)(e) requires personal data to be kept no longer than necessary for the purpose, and Article 5(2) requires you to be able to demonstrate it. A configuration value is demonstrable evidence. A paragraph in a policy is a claim, and one that a regulator can disprove in a single query.

So convert every retention rule into a mechanism the store enforces itself, and treat any rule that has no mechanism as an open risk on the register rather than a completed control. That list is usually short, and it tells you where the real work is.

Where does a deleted record survive?

In more places than the deletion path visits. The copies below exist in nearly every non-trivial estate, they have independent lifecycles, and each one has its own mechanism for expiry. Working through this list against your own systems is often the moment the size of the problem becomes clear.

How do you handle backups you cannot edit?

You do not edit them. Backups are immutable on purpose and surgically removing a record from one would defeat their function, so the accepted approach has two parts: keep the backup retention window short enough that copies expire on a known schedule, and maintain a suppression list that is re-applied whenever a restore happens. A restore then reintroduces the record and the suppression removes it again before the data is served.

The UK regulator has long accepted that data can be put beyond use where deletion is not technically achievable, with conditions on access and further processing, and the same reasoning informs how supervisory authorities elsewhere approach backups. This is jurisdiction-sensitive, so record your reasoning and have counsel confirm it rather than treating it as settled everywhere.

The stronger engineering answer for high-sensitivity fields is crypto-shredding: encrypt each subject's sensitive fields with a per-subject key, and delete the key on erasure. Every copy of the ciphertext, including the ones inside immutable backups, becomes unreadable at once. It costs you key management complexity and it is the only mechanism that acts retroactively on data you cannot reach.

What keeps data alive in a container platform?

Volumes, snapshots and node storage, all of which outlive the workload. A PersistentVolume with a Retain reclaim policy stays after the claim and the pod are deleted, so decommissioning a service can leave its data in the cluster indefinitely with nothing referencing it. Volume snapshots have their own lifecycle and frequently no expiry at all. Both are invisible in an application-level inventory.

Container images are the second reservoir. A dataset copied into an image and removed in a later instruction remains in the earlier layer, and that image sits in a registry with tags, digests and often no cleanup policy. The same applies to a fixture file used for testing that happened to be a production extract. Registry garbage collection is a retention control, and almost nobody configures it as one.

Then the ephemeral paths that are not ephemeral: logs written to node filesystems rather than shipped, core dumps containing whatever was in process memory, and debug artefacts uploaded to a shared bucket by a crash handler. The practical routine is to set volume reclaim to delete unless there is a stated reason, apply lifecycle rules to snapshot and artefact storage, configure registry retention by age and tag, and disable core dumps in production images unless a specific investigation needs them.

How should deletion propagate across services?

Publish it as an event and require acknowledgement. A subject-deleted event that every service holding personal data subscribes to, with each consumer recording that it completed, turns deletion from a coordination exercise into a measurable one. The important half is the acknowledgement: without it you have a fire and forget message and no way to tell which of nineteen services acted.

Alert on the gap. Any deletion not acknowledged by every registered consumer within an agreed window should raise a ticket, because the failure mode here is silent and permanent. This one alert is the difference between a deletion path you believe in and one you hope about.

Make registration a platform requirement rather than a policy. A service that holds personal data must implement delete by subject and export by subject and register itself, checked at deployment. New services then arrive with the obligation already met, which is the only version of this that stays true as the estate grows.

What test proves deletion actually works?

Take a subject deleted ninety days ago and search for every identifier associated with them across every store you can reach. Not the deletion log: the stores themselves. Include the search index, the warehouse, the log platform for the full retention window, the object store including non-current versions, the support tool and any non-production environment.

Expect two or three hits. The log platform is the most common, because request logs and traces contain identifiers and were never wired to the deletion path. The warehouse is second, because loads append and nothing subtracts. Non-production environments are third, and they are usually the worst, since the data is older, the access is wider and the masking step was skipped once under deadline.

Run the same check monthly with an automated job and report the count. A metric of identifiers found after deletion, trending to zero, is evidence in the form regulators and enterprise buyers accept, and unlike a policy document it cannot be true in writing and false in production.