Deleted from the database - alive in the backups

Every company has a retention policy. It lives in a document somewhere, probably last updated when someone realised the audit was coming, and it says something confident like "personal data is deleted after 90 days," a number chosen to sound impressively short rather than derived from any documented purpose limitation analysis. Management nods. Legal signs off. The document is filed.

The data, meanwhile, is immortal. Particularly in the backups, which nobody mentioned during the policy meeting, and which have been quietly retaining everything for the last three years.

This is the gap nobody talks about: the difference between having a retention policy and actually enforcing one. Writing the policy takes an afternoon. Enforcing it across a real production system (databases, backups, logs, third-party processors, archived exports, data warehouses, shadow copies) takes considerably longer and surfaces architectural decisions you probably did not make with deletion in mind.

Why most retention enforcement fail before it starts

The core problem is that data accumulates in more places than the people who wrote the policy knew about. They were thinking about the main database. They were not thinking about the logging pipeline capturing request bodies containing user data, retained indefinitely because nobody set a log rotation policy that actually runs. Or the analytics warehouse where raw event data was dumped eighteen months ago for a project that never shipped, still containing full user identifiers because pseudonymisation was "on the roadmap." Or the nightly database backup kept for ninety days, which means data you deleted from your live database on day one is sitting intact in a backup until day ninety-one, possibly longer if someone manually archived a copy before a major release "just in case."

Your retention obligation also extends to every third-party integration you mapped in the previous post. If you delete a user from your system but your CRM still has their record, your error monitoring tool still has their stack traces, and your AI model API still has their conversation history in a fine-tuning dataset, you have not actually deleted anything. You have just deleted the copy you control.

And then there is the CSV someone exported for a one-off analysis and saved to their laptop. You cannot automate your way out of that one, but you can make it a disciplinary issue rather than a technical afterthought.

Deletion, anonymisation, pseudonymisation: why the distinction matters

Before writing a single line of deletion code, decide which approach you are actually taking, because they are genuinely different and GDPR treats them differently.

Deletion means the data is gone. If someone submits a Subject Access Request after deletion, the correct answer is "we hold no data about you." Clean, simple, and the hardest to implement cleanly at scale.

Anonymisation means the data still exists but can no longer be linked back to any individual. Not by you, not by anyone, not even with additional datasets or reasonable effort. If you get this right, GDPR no longer applies to the anonymised data. You can keep it indefinitely. Use it for analytics, QA datasets, model training, load testing, whatever you need. This is not a loophole. It is the intended solution. GDPR actively encourages anonymisation precisely so organisations can retain data for legitimate secondary purposes without the retention clock running. The regulation wants you to do this. It just wants you to do it properly.

The catch is that proper anonymisation is harder than it looks. Stripping a name and email from a record is not anonymisation if the remaining fields (age band, postcode, job title, account creation date) are specific enough that a determined person could identify the individual anyway. This is called re-identification risk, and underestimating it is how anonymisation projects quietly become pseudonymisation projects that fool nobody, least of all a regulator.

Pseudonymisation (replacing direct identifiers with tokens while keeping a mapping table somewhere) is useful operationally and GDPR gives you credit for doing it, but it does not satisfy a deletion obligation on its own. The individual is still identifiable via the mapping table. Deleting the mapping table helps but is not guaranteed to be sufficient either, because the pseudonymised records may still be re-identifiable through other attributes in the dataset. If you are planning to rely on pseudonymisation to satisfy retention obligations, get a proper opinion before you ship the job rather than after.

The practical split for most builders: delete personal data you no longer need for the original purpose, anonymise data you have a genuine legitimate reason to retain for secondary purposes like QA, testing, and model improvement. Do the anonymisation properly: strip direct identifiers, assess re-identification risk against the remaining fields, document your assessment. If you cannot do that confidently, delete instead. Getting anonymisation wrong and calling it done is worse than not trying.

How to actually implement deletion

Start by mapping every place a user's data lives. Not the places you think it lives. The places it actually lives. Run the exercise the same way you ran the integration audit in the previous post: start with what is observable (database tables, log destinations, third-party integrations), not with what the architecture diagram says.

For each location, answer three questions. Can you delete or anonymise on demand? Can you automate that deletion on a schedule? Can you verify that the deletion happened?

The third question is the one most teams skip. A deletion job that silently fails and reports success is worse than no deletion job at all, because you now have a compliance record claiming data was deleted when it was not. Build verification in from the start. Log the deletion, log the count of records affected, alert on zero-count deletions for users who should have had data.

For your main database, deletion is usually straightforward: a scheduled job keyed on created_at or last_active, with a soft-delete period if your support team needs a recovery window. The soft-delete period is a retention period too. Define it explicitly and enforce it.

For logs, set retention policies at the pipeline level, not as a manual cleanup task. If your logging infrastructure supports it, filter PII out of log entries at ingestion rather than trying to delete it later. Deleting specific records from a log stream retroactively is painful. Not writing them in the first place is much easier.

For backups, accept that you will have a lag. If your backups are retained for thirty days, data deleted from your live system will persist in backups for up to thirty days. Document this. It is generally acceptable under GDPR provided your retention policy accounts for it and you are not using backups as a way to circumvent deletion obligations. What is not acceptable is keeping backups indefinitely because nobody ever reviewed the retention setting on the backup job.

For third-party processors, deletion requests need to flow downstream. This means either automated API calls to trigger deletion with each processor, or a documented manual process with a completion record. Most major vendors support deletion APIs. Use them. For vendors that do not, that is a conversation to have before you rely on them for anything involving personal data.

The backup problem in plain terms

Backups deserve their own paragraph because they are where most retention programmes quietly fall apart

A backup is a point-in-time snapshot. When you delete data from your live system, that deletion does not propagate to existing backups. The deleted data still exists in every backup taken before the deletion. This is fine and expected. The question is how long those backups are kept.

The answer at most companies is "longer than anyone realised." Backup retention settings get configured once and forgotten. Storage is cheap. Nobody audits the backup retention policy against the data retention policy. The result is a graveyard of point-in-time snapshots containing the personal data of users who deleted their accounts years ago.

Review your backup retention settings now. Align them with your data retention policy. If your policy says data is deleted after ninety days, your backups should not be retained for a year. And if you receive a deletion request for a specific individual, note in your records that the deletion will be complete once the relevant backup window expires. That is the honest answer, and it is defensible.

What good looks like

A retention programme that actually works has four properties:

It is automated. Manual deletion processes fail because people forget, get sick, leave the company, and inherit the deletion backlog of whoever left before them. If it is not automated, it is not a retention programme. It is a good intention.

It is verified. Every deletion job produces a record of what was deleted, when, and how many records were affected. Anomalies trigger alerts. The verification record is retained. Yes, there is some irony in keeping records about your deletion records, but this is what audit evidence looks like.

It covers the full data estate. Main database, logs, backups, third-party processors, data warehouses, exported files where possible. Retention enforcement that only touches the main database is not retention enforcement. It is tidying one shelf while the rest of the house accumulates.

It is tested. Run a deletion job against a test dataset before you run it against production. Verify the outcome. Do this every time the job changes. "The deletion job runs" and "the deletion job works correctly" are different statements and you want evidence for both.