Gone but Not Forgotten: The Deletion Evidence UK Apps Struggle to Produce

There's a moment in most app teams' lives where someone in legal or a buyer's procurement pack asks a simple question: 'Show me what happens when a user deletes their account.' And the room goes a bit quiet. Not because nobody knows — because the person who knows is on holiday, and the answer lives in four different systems and a Slack thread from March.

Account deletion is one of those features that ships in a sprint and then quietly rots. Apple has required in-app deletion for apps with account creation for a while now, the ICO expects you to honour erasure requests within a month, and your privacy notice probably says something confident about it. The gap isn't the button. The gap is the proof.

This is a guide to closing that gap without hiring a consultant or building a compliance platform. It's a day or two of work, repeated a few times a year.

Start with the request, not the settings screen

Most teams document deletion from the UI backwards. Flip it. Take a blank page and draw the journey from the tap onwards: settings screen, confirmation dialog, API call, identity service, the job that actually runs the delete, the queue it sits on, and every system that receives a signal afterwards.

If that diagram takes more than twenty minutes and involves someone saying 'I think Segment handles that', you've found your first issue. The diagram is the skeleton of your audit, and it should live in the same repo as the code, not in someone's head.

The places a deleted account quietly survives

Nine times out of ten, the primary database is fine. It's the edges that leak. The usual suspects:

• Soft-delete flags. A row marked deleted_at is not deleted. It's hidden. Fine for a two-week grace period, not fine as a permanent resting place for an email address.
• Backups and point-in-time recovery. You cannot surgically remove one person from a nightly snapshot, and you shouldn't pretend otherwise.
• Analytics and event pipelines. Amplitude, Mixpanel, GA4, Snowplow — user IDs, device IDs and property blobs that never got told about the deletion.
• CRM and marketing tools. Braze, HubSpot, Mailchimp. Some records need to survive as a suppression entry so you don't email a ghost. That's defensible; a full profile is not.
• Support desk. Zendesk or Intercom tickets, attachments, screenshots of the account page, call recordings, CSAT free text.
• Logs and error tracking. Sentry events, APM traces, request logs with query strings. Usually short-retention, which is your friend — if the retention is actually set to what you think.
• The sprawl. BI dashboards, warehouse copies, CSV exports on someone's laptop, a partner's staging environment, that one Lambda holding a cache.

Warehouses deserve a special mention, because time travel and cloning features mean a row you deleted three weeks ago can reappear during a restore. If you use Snowflake, BigQuery or Databricks, check the retention windows on the tables that hold personal data.

Build a canary account and follow it round

Theory is lovely. Testing is quicker. Set up a test account with a throwaway address on your own domain, behave like a real user for a week — place an order, raise a ticket, trigger a push, abandon a basket — then request deletion through the live UI.

Before you press the button, note the identifiers in every system: internal user ID, email, device ID, order reference, ticket number. After deletion, go looking for residue at day one, day seven and day thirty. Screenshot what you find, with timestamps visible. That evidence pack is worth more than any policy document, because it shows the thing working rather than the thing being described.

Expect two or three surprises. Most teams find their analytics tool is still holding events, because nobody wired the deletion webhook through to it.

Be honest about backups

The mature answer to backups is a retention statement, not a promise of surgical erasure. Something like: backups are kept for 35 days, are encrypted and access-controlled, are not used for any other purpose, and if a restore is required the deletion is reapplied as part of the recovery runbook before the system goes live again.

That last clause is the one that gets missed. A restore that silently resurrects deleted accounts is a data protection incident wearing a cape. Write it into the runbook, and test it once — even in a staging environment — so you know the reapplication step actually exists in code.

Test your processors, not just yourself

Your deletion isn't done when your job finishes. It's done when every processor has confirmed. Pick your top five by risk, not by count: the one holding the most personal data, the one with the murkiest sub-processor list, the one you inherited and nobody has reviewed since.

Ask each a direct question: 'If we send you this identifier, when is it gone, and can you confirm in writing?' Then actually send one. Keep the reply. Note the date. If a processor's documentation has a deletion API, use it and log the response code — that's better evidence than an email.

Aggregated, non-identifying data is a different conversation and usually fine. The trap is calling something aggregated when it still has a user ID column.

The support desk is where most teams fail first

Free text is the enemy. A ticket saying 'customer asked us to close their account, here are their details' is a personal data record that outlives the account by years. Add in screenshots, call recordings and emailed attachments and you've got a shadow profile nobody owns.

Practical fixes: a deletion macro that links the ticket to the request record rather than pasting details, a retention rule that closes and purges tickets after a defined period, and a rule that attachments containing account screenshots get redacted. It's unglamorous work, and it's exactly what an auditor will spot.

Keep the evidence small enough that you'll actually keep it

You don't need a compliance platform. You need one sheet with a row per request: request ID, date received, systems hit, timestamps, who confirmed what, screenshots filed, exceptions noted. Add a column for 'residue found' — that's where the learning lives.

Two things trip people up here. First, the evidence itself is personal data, so give it a retention period and access control. Second, legal retention can override erasure: HMRC expects you to keep transaction records for six years, and fraud prevention and legal claims are legitimate reasons to keep some things. The trick is scoping — the invoice survives, the marketing profile and browsing history don't.

Run it as a drill, not a project

A quarterly ninety-minute drill, where one person runs the canary account and another watches, will find more than a one-off audit ever does. Rotate who runs it, so the knowledge isn't concentrated. Feed the gaps back into the retention schedule and the record of processing.

None of this is glamorous. It won't demo well. But when a procurement team, an ICO query or a nervous enterprise client asks you to prove the deletion works, you'll have something better than a confident answer — you'll have a paper trail with dates on it. That's the difference between a promise and a process.