Where do organisations most often break erasure obligations in practice?

Where erasure breaks most often in practice

Organisations usually fail erasure at the edges of the system, not in the primary application itself. The main database may be updated correctly, while backups, logs, exports, replicas and downstream analytics stores continue to hold personal data. That creates a false sense of compliance because the most visible datastore looks clean even though other copies remain.

The practical problem is data sprawl. Personal data is copied for resilience, troubleshooting, reporting and integration, and each copy has its own retention logic, access path and deletion method. If the erasure workflow only targets the primary record store, those secondary locations become the place where obligations break down.

Secondary stores are also harder to enumerate than the core application. Some are managed by another team, some are held by vendors, and some are embedded in tooling such as search indexes, message queues, archived extracts or data science platforms. A valid erasure process has to follow the data, not just the application that first collected it.

Why backups, logs and analytics stores are the usual failure points

Backups are a common exception because they are built for recovery, not selective deletion. Logs and audit trails are retained for operational and security reasons, which means personal data may persist there longer than in the source system. Exports and replicas are often overlooked because they look like temporary or derived data, yet they can contain complete or near-complete personal records.

Downstream analytics stores create a separate challenge. Data is often transformed, enriched or joined before it lands there, so the organisation may lose sight of where the original subject data ended up. If those stores are not included in the deletion scope, the erasure request is technically handled in one place and practically ignored in another.

External disclosure adds another layer of risk. When personal data has been sent to partners, processors or reporting platforms, the deletion obligation does not end at the first internal system boundary. Organisations need inventory, ownership and exception handling for each downstream destination that can retain the data.

What a credible erasure process must cover

A credible process starts with data mapping. Teams need to know where the data originated, where it was replicated, which systems transform it, and which retention rules apply at each stage. Without that map, deletion becomes a best-effort activity instead of a controlled process.

Erasure also needs explicit exception handling. Some data cannot be removed immediately from immutable backups or security logs, but that exception should be documented, time-bounded and justified. If the organisation can only exclude a system by assumption, it does not really know whether the obligation has been met.

The most reliable approach is to make erasure a tracked workflow across every storage layer, with ownership assigned for source systems, backup sets, archives, exports and downstream stores. That way, a completed request means more than a ticket being closed in the primary application.

Risk and Threat Considerations

Unremoved copies create both compliance exposure and security exposure. Personal data left in backups, logs or analytics platforms can survive long after the original record has been deleted, which means a breach, access review or legal review may uncover data the business believed was already erased.

Failure mechanism: The organisation deletes or masks the primary record but misses secondary copies, or it lacks the ability to selectively remove personal data from retained archives, exports or derived datasets.

Impact: The subject’s data continues to exist outside the intended retention boundary, creating regulatory breach risk, inaccurate records of compliance, and avoidable exposure if those stores are later accessed or compromised.

Practitioner Guidance

What to prioritise: Start with systems that routinely duplicate data, especially backup platforms, logging pipelines, export jobs and analytics sinks. Those are the places where erasure requests most often look complete on paper but remain incomplete in reality.

What to verify: Do not trust a deletion record until you can show the downstream data path, the owner for each storage layer, and the exception status for each retention-controlled store. If a team cannot point to those details, the erasure control is not yet operational.

Practitioner takeaway: The hard part of erasure is not deleting the obvious record, it is proving that every meaningful copy has been found, governed and either removed or formally exempted.

Related resources from NHI Mgmt Group

• Why do role-based access control models often break down as organisations move to digital-first operations?
• Where do IAM programmes most often break down in practice?
• Why do access reviews often fail in large organisations?
• How should organisations stop identity governance from stalling in practice?