How should organisations handle right-to-erasure requests when personal data is spread across multiple systems and third parties?

Organisations should start by locating where the requester’s personal data lives, then remove the relevant data types from internal systems and notify third parties that received the same data. The process is not a full deletion of every record, because legal, public-interest, or freedom-of-expression exceptions may apply. Strong data mapping is the practical foundation for compliant erasure handling.

Why erasure is really a data discovery and propagation problem

Right-to-erasure handling is rarely blocked by the act of deleting a row in one database. The harder part is finding every place the personal data was copied, transformed, cached, exported, or shared, then deciding which records must be removed, which can be retained under an exception, and which third parties need a matching notice. That makes inventory, lineage, and ownership the practical control points.

Where organisations treat erasure as a ticket for a single system owner, they usually miss downstream replicas, analytics stores, support tools, backups, and vendor-held copies. A workable process needs a repeatable way to trace data categories, not just individual names, because the requester may be represented in multiple systems under different identifiers or schemas. Identity Data Privacy and Consent Guide is useful here because it ties data subject rights to minimisation, retention, and delegated handling rather than one-off deletion tasks.

When the source data is mapped well, teams can separate routine operational deletion from legal hold, fraud prevention, public-interest, or freedom-of-expression exceptions. That distinction matters because compliant erasure is selective, not absolute: the organisation must remove the data that is no longer justified, but it may still need to retain specific records where another lawful basis applies.

How to handle internal systems and third parties without losing control

Internally, the safest pattern is to translate the request into all affected data types and systems, then execute deletion or suppression by system class. Personal data in transactional systems may be deleted, while logs, analytics, archives, and backup sets may require different treatment, such as delayed purge, restricted access, or documented exemption handling. The key is consistency, because partial deletion can create mismatched records that are harder to explain later.

For third parties, the organisation remains responsible for passing the erasure instruction to processors or recipients that received the same personal data. That means contracts and operating procedures need a clear path for notification, confirmation, and exception handling, especially when the same data has moved through SaaS platforms or integration chains. Third-Party, B2B and Contractor Access Guide is relevant because it shows how external access, sponsorship, and reviews support downstream control over data exposure.

A good implementation also distinguishes deletion from propagation. A deletion request is not finished when the internal source record is removed if replicas, exports, or vendor copies still persist. Organisations should keep an auditable record of which parties were notified, what was requested, what was confirmed, and what was retained under an exception so they can evidence compliance later.

What makes erasure fail in practice

Most failures come from incomplete discovery, not deliberate refusal. If data mapping is weak, organisations often miss shadow systems, duplicated exports, and fields embedded in tickets, collaboration tools, or customer support workflows. If third-party tracking is weak, they know where data was sent in theory but cannot prove whether the recipient deleted it or whether a subprocessor held an independent copy.

Another common failure is over-deleting. Teams sometimes remove records that should have been retained for legal or regulatory reasons, then discover they have impaired auditability or incident response. The better approach is to classify the request against the retention schedule and the lawful basis before actioning deletion, so the organisation does not trade privacy compliance for recordkeeping risk. EU General Data Protection Regulation (GDPR) is the clearest reference for the underlying duties, including processing principles, data protection by design, and the legal structure around erasure.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 sets the technical controls, while GDPR defines the regulatory obligations.

Framework	Control / Reference	Relevance
GDPR	Art.5 — Principles relating to processing of personal data	Defines minimisation, storage limitation and accountability for erasure handling.
	Art.17 — Right to erasure ('right to be forgotten')	Directly governs when and how erasure requests must be handled.
	Art.28 — Processor	Requires processor obligations and notification pathways for third-party copies of personal data.
Recommendation — Apply data minimisation and storage-limitation rules to remove personal data only where retention is no longer justified. Assess each request against Article 17 conditions and execute deletion or restriction where required. Ensure processors receive and act on erasure instructions through contractually defined procedures.
NIST SP 800-53 Rev 5	MP-6 — Media Sanitization	Supports secure removal of data from storage media and retained datasets.
Recommendation — Sanitize media and storage according to retention and disposal requirements.

Practitioner Guidance

What to prioritise: Start with a data map that identifies where personal data is stored, who receives it, and which systems can suppress rather than fully delete. If you cannot trace data flows, you cannot answer an erasure request with confidence.

What to verify: Confirm that each deletion workflow has a matching exception path for records that must be retained, and that third-party notifications are actually closed out. The evidence should show both action taken and the reason any data remained.

Common mistake: Treating the request as a single-system purge. The operational risk is not just non-compliance, it is inconsistent state across internal platforms and vendors, which creates future disclosure and audit problems.

Practitioner takeaway: Effective erasure handling is a data lineage problem first and a deletion problem second, so the control objective is to make every removal decision traceable, exception-aware, and repeatable across the full data chain.