Data Deletion Request

What a data deletion request actually requires

A data deletion request is not a simple record purge. The organisation has to locate personal data across operational systems, replicas, backups where applicable, and downstream processors, then coordinate removal or suppression so the individual is no longer being processed unlawfully. That makes the request as much an operational workflow as a legal-rights event.

The important distinction is scope. A single customer profile may be only one copy of the data, while logs, exports, analytics stores, support tools, archives and partner systems may also hold the same personal data. Good handling therefore depends on discovery, lineage, ownership and evidence, not just a delete button.

Why deletion requests are hard to fulfil cleanly

Deletion is difficult because modern systems copy data by design. Personal data can move into search indexes, message queues, data warehouses, ticketing systems and SaaS platforms, and each of those may have different retention rules or technical limits. If an organisation cannot map where the data lives, it cannot prove that deletion was complete or timely.

This is why deletion work often collides with retention law and business necessity. Some records must be kept for tax, fraud prevention, legal hold or security logging, while other copies should be removed or rendered non-identifiable. The challenge is to distinguish what must be retained from what must be erased and to keep that decision consistent across systems.

For engineering teams, the pattern is similar to the broader DSAR workflow described in NHIMG’s DSAR Guide: Handling Data Subject Requests, because deletion requests still depend on intake, search, exemptions and verification before closure.

How organisations execute deletion across systems

Most mature deletion programmes use a coordinated workflow rather than manual one-off deletions. The request is validated, the relevant person and identifiers are confirmed, systems are searched, deletion tasks are queued, and each completion step is logged for later evidence. Where deletion is technically impossible in place, teams may rely on suppressing further use, tombstoning records, or applying crypto-shredding to data encrypted with subject-specific keys.

That workflow has to extend beyond the core application into analytics, backups, logs and third-party processors. A privacy-by-design approach helps because it treats deletion as a lifecycle property of the system, not an afterthought. When engineering teams design for erasure early, they reduce the chance that copies survive in forgotten data stores.

NHIMG’s Right to Erasure Engineering Guide is a practical reference for orchestrating deletion across microservices, logs, backups and suppliers, while Privacy by Design Guide for Engineering Teams shows how deletion fits into privacy engineering and control design.

Evidence, retention, and exceptions

A deletion request usually cannot be closed on trust alone. Organisations need evidence that the request was received, processed and completed, along with a record of any exceptions. That evidence matters for accountability, complaint handling and regulatory defence, especially when an individual later asks what happened to their data.

Retention exceptions are just as important as deletion. If the business keeps data under a legal hold, or if certain records must remain for compliance or fraud-detection purposes, the decision should be documented and narrowly applied. The goal is to avoid both over-deletion and over-retention, because either one can create risk.

For policy and control design, NHIMG’s Data Retention and Secure Deletion Guide and Data Retention and Disposal Policy Template are useful because they connect deletion requests to retention schedules, backup handling, legal holds and secure disposal.

Deletion governance and external obligations

Deletion requests sit at the intersection of privacy rights, records management and vendor governance. If data has been shared with processors or other recipients, the request may require downstream notification or contractual coordination, not just internal deletion. That is why organisations need clear ownership for request handling, a defined path for escalations, and contracts that cover return, deletion and exit obligations.

Where data is hosted in cloud or supplier environments, the technical deletion step may depend on provider behaviour, evidence of disposal, and the timing of backup expiry or purge cycles. Organisations should therefore align deletion handling with the obligations in their privacy regime and with supplier contracts that support deletion at the end of processing.

For cloud PII processors, NHIMG’s ISO/IEC 27018 Cloud PII Protection Guide and Third-Party Security Contract Clauses Template help connect deletion requests to processor duties, exit planning and data return or deletion terms.

Related resources from NHI Mgmt Group

• Data Deletion
• Who is accountable when consumer data reappears after a deletion request is reported closed?
• What happens when a deletion request reaches data that has already been made public or indexed by search engines?
• Who should be accountable for data deletion request fulfillment?