Data deletion is a workflow across copies, holds and restores

A customer record can disappear from the application while remaining available in yesterday’s export. For the data platform lead, that is an unfinished deletion: the application owner has completed one task, but the organisation still has another usable copy.

The practical challenge is to translate an approved retention rule into actions across systems with different owners and deletion mechanisms. A single success message cannot describe all of them. The workflow needs to say which copies were removed, which are being retained for an authorised reason, and what prevents an old copy from returning to service.

Start with the rule and its trigger

Take one data class and one business process first. Obtain the approved purpose, retention period, event that starts the clock and treatment of exceptions. “Delete after seven years” is not executable until the team knows whether that means seven years after creation, contract termination or another event.

The ICO’s storage-limitation guidance explains that UK GDPR does not set specific retention periods for different data types: organisations must justify how long they need the data for their purposes. The platform team should implement the rule agreed with the accountable data and legal owners, including applicable sector requirements. It should not infer a period from a software default.

Scheduled expiry and an individual erasure request can share execution machinery, but they need separate decision inputs. A hold, an approved retention requirement and an operational failure are different reasons for data still being present. Combining them under “exception” conceals who must act next.

Follow copies beyond the application boundary

Trace the source record into integration staging, warehouse tables, exports, search indexes, logs and recovery copies. Ask each owner what identifier connects their copy to the source, how deletion is requested, and how completion can be observed. If a CSV export has lost the identifying key, a later deletion request may require rebuilding the whole export rather than removing one row.

A useful copy register has one row per destination, with the data class, purpose, owner, applicable rule, hold status, deletion mechanism and verification method. Add a named exception owner and resolution date where the mechanism cannot meet the agreed treatment. Keep evidence references rather than duplicating the personal data in the register.

Microsoft Purview illustrates why the visible application is only part of this map. Its retention documentation describes copies of edited or deleted SharePoint and OneDrive content being kept in a Preservation Hold library. By default, retention takes precedence over permanent deletion, although Microsoft documents exceptional priority-cleanup behaviour. Retention labels also do not persist when content moves outside Microsoft 365. An export therefore needs its own lifecycle control; the source label is not evidence that the exported file will expire.

Before changing a policy to make a deletion succeed, establish why the retained copy exists. A technical ability to override retention is not the business authority to release a hold.

Test a deletion through the whole journey

Consider a hypothetical customer-support record whose approved retention period has ended. It exists in the support application, a warehouse and a monthly analyst export. The application deletion succeeds, the warehouse job has not run, and the analyst still has the file.

The workflow should remain open with separate destination states. The warehouse owner confirms the next deletion run and checks the record afterwards. The export owner withdraws the old file and regenerates the permitted dataset. The integration owner verifies that a delayed event or full reload will not recreate the removed record.

Make the test include a failed destination and a retry. A retry should finish the outstanding work without changing a legitimately retained record or creating duplicate tasks. Monitor failures against an agreed operational deadline, and route unresolved copies to their owners. “Request accepted” by an API and “record absent from the destination” are distinct observations.

A backup needs a restore rule as well as an expiry date

The ICO’s erasure guidance says that, where a valid request applies and no exemption exists, organisations must take steps covering backups as well as live systems. Where immediate overwriting is not possible, it discusses keeping the backup data beyond use until replacement under an established schedule, with clear explanations to the individual. This is context dependent, not a blanket exemption for backups. The ICO flags this guidance as under review following the Data (Use and Access) Act.

Operationally, require the recovery owner to show what happens when an older backup is restored. One approach is to restore into a restricted environment and reapply authorised deletions before reopening access. Test whether the deletion history itself is available after a disaster and whether it covers the restored period. Avoid retaining unnecessary personal detail merely to support that history.

Close the case with an accurate account of live-system removal, authorised retained copies, backup treatment and unresolved failures. Then make new integrations declare their deletion behaviour before they receive data. For copies created by retrieval and AI pipelines, extend the same exercise to AI data readiness and revocation.