Designing for Forgetting: Making Data Erasure a Product Feature, Not a Support Ticket

Most UK software teams know that individuals have a right to erasure under the UK GDPR. Far fewer have designed for it. The right sits in a policy document, the policy points to a support process, and the support process ends with an engineer opening a database console and hoping they have found every table. That is not a compliance posture; it is a recurring incident waiting for a customer to trigger it.

The statutory clock is one month from receipt of a request, extendable by up to two further months where the request is genuinely complex. A month sounds generous until the first request arrives and nobody can say with confidence where the data lives.

The request that exposes the design

A customer emails asking to be forgotten. In a well-built product, this is a short, auditable workflow: identity confirmed, scope agreed, deletions cascaded, processors notified, confirmation issued. In a typical product, it is a fortnight of archaeology across a production database, a data warehouse, an email platform, a CRM and three supplier dashboards.

The difference is not legal expertise. It is product design. Erasure, access and portability are user-facing capabilities, and capabilities need owners, interfaces, error states and tests. Treating them as legal administration means they are rebuilt from scratch every time, at the worst possible moment.

Start with a map, not a delete statement

You cannot remove what you have not catalogued. Before writing a single deletion routine, produce a practical data map covering the places personal data actually accumulates:

• Primary application tables, including soft-deleted rows and audit tables.
• Derived stores: caches, search indexes, materialised views, reporting tables.
• Event streams and message queues, including dead-letter queues nobody monitors.
• Application and infrastructure logs, error trackers and session recordings.
• Analytics, marketing and CRM platforms, often owned outside engineering.
• Backups, snapshots and disaster-recovery copies.
• Third-party processors, from email delivery to payment providers.

For each location, record what is held, why, the lawful basis, the retention period and who owns it. This map is the single most valuable artefact in the whole exercise, because it also underpins subject access requests, breach response and the data protection impact assessments that enterprise buyers increasingly demand during procurement.

Designing the deletion workflow

A workable erasure feature has four moving parts. First, verification: confirm the requester is who they claim to be, using a proportionate method rather than a full identity check that would itself require collecting more data. Second, scope: show the requester what will be deleted and what will be retained, and why. Some records may need to survive for legal, tax or fraud-prevention reasons, and saying so plainly is better than silently keeping them.

Third, execution: cascade deletions through related tables, honouring referential integrity, and decide deliberately between immediate hard deletion and a short, time-boxed soft-delete window. Fourth, evidence: produce a confirmation the customer can keep and your team can produce to a regulator.

Anonymisation is a legitimate alternative where the remaining data serves a genuine purpose, such as aggregate usage statistics. It is not a synonym for deletion, and pseudonymised records that can be re-linked to an individual do not satisfy the right. Be precise about which one you are doing.

Export before you erase

Erasure rarely arrives alone. Subject access and portability requests use much of the same plumbing, so build the export alongside the delete. A machine-readable export of the individual's data, generated from the same map, gives the customer something useful and gives your team a rehearsal for the harder workflow. It also makes the deletion scope tangible: if you can export it, you know where it lives.

Backups: the honest position

Backups are the question that derails otherwise sensible discussions. Most backup systems are not designed for surgical per-record deletion, and pretending otherwise leads to fragile scripts and false assurances.

The defensible approach is to rely on rotation. Document the backup retention period, ensure deleted records are not restored into live systems, and maintain a deletion register that can be replayed against any restored dataset before it returns to service. If your retention period is thirty-five days, say so, and explain that residual copies expire on a known schedule. Transparency here is far stronger than a claim of instantaneous, total erasure that nobody can evidence.

The long tail of processors

Every supplier holding personal data is part of your deletion surface. Contracts should require deletion on instruction and on termination, but contracts are not mechanisms. Build the operational path: documented delete endpoints, retries for failed calls, webhook confirmations, and a named contact for the suppliers that have no API at all. Keep a sub-processor list and review it when suppliers change. The awkward cases — support tickets, email archives, call recordings — are usually the ones that turn a two-day task into a two-month one.

An audit trail without hoarding

Accountability requires evidence, but the audit log must not become a second copy of the data you just deleted. Record the request identifier, date received, verification method, scope, systems actioned, completion date and any lawful retention exceptions. Avoid storing the deleted content itself. Set a retention period for the log and apply it.

Making the operation boring

A runbook, a named owner and an internal service level of, say, fourteen days against the statutory thirty will do more for compliance than any policy rewrite. Track time-to-fulfil as a product metric. Rehearse quarterly with a synthetic account so the workflow does not rot as schemas change. Include erasure in onboarding for support staff, who are usually the first to see a request.

A practical checklist

• Data map covering databases, derived stores, logs, analytics, backups and processors.
• Verified, self-service request route with a documented fallback.
• Deletion cascade with referential integrity and a defined soft-delete window.
• Machine-readable export built on the same data map.
• Backup rotation documented, with a deletion register for restores.
• Processor deletion paths tested, not just contracted.
• Audit log with minimal identifiers and its own retention rule.
• Internal SLA, owner and quarterly rehearsal.

The commercial case

Erasure is increasingly a sales issue. UK enterprise buyers ask about data subject rights in security questionnaires, and a confident, evidenced answer shortens procurement. Conversely, a slow or muddled response to a request is exactly the kind of detail that surfaces in a complaint to the Information Commissioner's Office, or in a renewal conversation.

The cost argument is simpler still. Ad-hoc requests consume senior engineering time, carry real risk of missed records and produce no reusable asset. A designed workflow costs roughly the same once and then runs quietly. Data rights are part of the product. Build them that way, and forgetting becomes a feature rather than a fire.