What breaks when organisations try to fulfil a right to erasure request manually?

Why manual erasure work collapses at scale

Manual deletion is not just slow, it is structurally brittle. A right to erasure request can span email, cloud drives, HR systems, analytics stores, backups, ticketing tools, exports, and shadow copies, so the search problem quickly becomes larger than any one team can reliably complete by hand. That makes the control fail on coverage, not just effort.

The practical issue is that completeness is hard to prove when records are distributed across systems with different owners, retention rules, and deletion semantics. If the process depends on people remembering every location and every replication path, the organisation is left with residual personal data even after a ticket is marked closed. For the privacy obligations behind erasure, that is a material control weakness; for a deeper treatment of processing obligations and deletion duties, see EU General Data Protection Regulation (GDPR).

Where the manual process fails in practice

Manual handling usually breaks in three places: discovery, consistency, and evidence. Discovery fails when data exists in forgotten repositories, attachments, logs, archives, or vendor platforms. Consistency fails when one team deletes a record while another retains a synced copy, export, or derived dataset. Evidence fails when the organisation cannot show what was searched, what was removed, and what remains under lawful retention.

That is why manual workflows often create uneven outcomes. Some systems get cleaned up quickly, others are missed, and some are only partially redacted or pseudonymised when full erasure was required. Where the subject is privacy operations rather than simply security hardening, the process needs a governance backbone, and the privacy-oriented controls in the NIST Privacy Framework are a useful reference point for classifying and governing personal data flows.

Manual handling also struggles with timing. Erasure requests often have statutory or policy deadlines, but locating every copy can take longer than the response window allows. Once a request becomes backlog work, the organisation risks delayed fulfilment, repeated chasing by the requester, and inconsistent treatment across cases. That is why the operational problem is not deletion alone, but coordinated deletion across the full data lifecycle.

What organisations need instead of ad hoc cleanup

The right response is to make erasure executable as a process, not an investigation. That means knowing where personal data lives, which systems are authoritative, which copies are derivative, and which retention exceptions are legally justified. It also means having a repeatable way to locate related records, propagate deletion where appropriate, and preserve the audit trail needed to prove what happened.

Practitioners should treat erasure requests as a data-mapping and workflow problem as much as a legal one. The more fragmented the environment, the more important it is to automate discovery, define ownership, and standardise evidence capture. A good practical benchmark is whether a team can answer, without manual trawling, which systems were searched, which records were deleted, which were retained, and why.

For organisations that want the security side of this governance discipline expressed in a broader control model, the NIST SP 800-53 Rev 5 Security and Privacy Controls catalog is a useful companion because it ties access, auditability, and controlled handling to operational accountability.

Risk and Threat Considerations

Manual erasure creates a residual-data risk because the organisation can believe it has complied while copies still survive in hidden repositories, replicas, exports, or downstream systems. The same weakness can also create a trust problem: once a requester or regulator sees inconsistent deletion, confidence in the organisation’s privacy handling drops quickly.

Failure mechanism: the process depends on human memory, fragmented system knowledge, and inconsistent ownership, so overlooked copies and incomplete deletion become likely under deadline pressure.

Impact: non-compliance exposure, delayed fulfilment, repeat remediation work, and loss of customer confidence when the organisation cannot prove complete erasure.

Practitioner Guidance

What to verify: Before trusting an erasure workflow, verify that it covers primary systems, downstream replicas, searchable archives, exports, and third-party processors. If the process cannot evidence each search and deletion step, it is not yet operationally reliable.

What good looks like: The organisation can produce a case file showing request intake time, systems searched, deletion actions taken, exceptions retained under lawful basis, and the final completion date. That record should be repeatable enough to survive audit, complaint handling, or regulator review.

Practitioner takeaway: Manual erasure is usually a governance failure disguised as a cleanup task, and it stops working the moment the organisation can no longer prove completeness at the pace the law demands.

Related resources from NHI Mgmt Group

• What breaks when organisations try to clean up machine accounts manually?
• What breaks when organisations try to review access manually across nested groups and foreign security principals?
• What breaks when organisations try to manage elevated access manually at scale?
• What breaks when organisations try to manage DPDP compliance manually?