Deletion requests must propagate to downstream recipients

What it is

Erasure notification to recipients extends an approved deletion beyond the source organization's primary store to parties that previously received the data. Under the GDPR, for example, a controller generally communicates an executed erasure to recipients unless doing so is impossible or involves disproportionate effort. For personal data made public, the rule also calls for reasonable steps, considering technology and implementation cost, to inform controllers processing links, copies, or replications.

Why it happens

Disclosure turns one record into a cross-organizational copy graph. Local deletion does not change a processor's warehouse, advertising platform, or partner institution. Without recipient inventory, stable request identifiers, and acknowledgments, the source cannot even establish whom to notify. Propagation makes deletion a supply-chain protocol: an upstream event needs executable semantics, and downstream parties must locate copies, apply their own basis assessment, and return completion or exception state.

Studying it

Marked synthetic records can be disclosed through vendor chains and then deleted, measuring recipient discovery, successful notification, acknowledgment latency, failure reason, and continued downstream use. Contract and data-flow audits should be reconciled with network, export, and vendor logs because static processor lists become stale. Processor, independent controller, and public re-publisher roles require separate analysis; a sent email is not evidence of downstream completion.

Where it stops holding

Propagation cannot guarantee that every copy on the open internet disappears. Applicable law may recognize impossibility or disproportionate effort, and independent recipients may have a separate retention basis. Anonymous aggregates differ from pseudonymous data still linkable to a person. Exact duties depend on jurisdiction, role, and disclosure relationship; GDPR recipient rules should not be stated as a universal global requirement.

Applying it

• Record recipient, data class, purpose, role, time, deletion interface, and contractual contact for every disclosure, updating the inventory as integrations change.
• Send machine-processable deletion events carrying request identity, object scope, and due state, with signed acknowledgment rather than free-form email.
• Escalate failed, unacknowledged, and exception-claimed recipients separately and disclose unconfirmed scope to the requester.
• Regularly send a marked record to test processors and request deletion, verifying their queries and jobs; close the propagation case only with evidence for internal and downstream states.

Related

• Same group: O1.07.1 Deletion must cover backups and derived data · O1.07.2 Deletion scope and timing must be stated · O1.07.3 Disappearance from the interface is not backend deletion · O1.07.4 Erasure is an assertable legal right, not an optional feature · O1.07.6 Public-interest and retention exceptions can justify refusal · O1.07.7 Completion needs verifiable evidence, not a verbal promise
• Adjacent: O2.13 Disclosure of third-party sharing · O1.03 Purpose limitation
• Search terms: recipient notification · deletion propagation · downstream erasure