The controller shall communicate any rectification or erasure of personal data or restriction of processing carried out in accordance with Article 16, Article 17(1) and Article 18 to each recipient to whom the personal data have been disclosed, unless this proves impossible or involves disproportionate effort. The controller shall inform the data subject about those recipients if the data subject requests it.
Article 19
Notification obligation regarding rectification or erasure of personal data or restriction of processing
Understanding This Article
Article 19 establishes a crucial notification obligation that ensures rectifications, erasures, and restrictions don't stop with the original controller but propagate to all entities that received the data.
This article creates a ripple effect for data subject rights. When a controller rectifies, erases, or restricts data, they must inform each recipient who received that data. This prevents situations where corrected data remains incorrect in downstream systems, or where deleted data continues to be processed by third parties.
The notification obligation has two components:
- Outward notification: Controller must inform recipients about rectification, erasure, or restriction
- Transparency to data subject: Upon request, controller must tell the data subject which recipients were notified
The obligation is not absolute - it doesn't apply if notification is impossible (e.g., recipient no longer exists, contact information lost) or involves disproportionate effort (e.g., notifying thousands of recipients when data was widely shared). However, controllers should document why notification wasn't possible.
This provision is essential for maintaining data integrity across complex processing ecosystems where data is shared with multiple processors, joint controllers, or third parties.
Key Points
- Controllers must notify all recipients when data is rectified, erased, or restricted
- Applies to actions under Articles 16, 17, and 18
- Exception: impossible or disproportionate effort
- Data subject can request list of notified recipients
- Ensures changes propagate through the data ecosystem
Practical Application
Example 1 - Customer Data Rectification:
An online retailer corrects a customer's address after a rectification request. Under Article 19, they must notify: their payment processor, shipping company, marketing automation platform, and customer service system. The customer can request a list confirming which entities were notified.
Example 2 - Employment Data Erasure:
After an employee's erasure request is granted, the employer must notify: payroll provider, pension administrator, background check company, and any recruitment agencies that received the data. Each recipient must then erase or restrict their copies.
Example 3 - Disproportionate Effort:
A news organization published an article mentioning someone's personal data, which was then republished by 10,000 third-party websites and blogs. After a rectification request, notifying all 10,000 sites would be disproportionately difficult. The organization documents this and notifies key recipients instead.
Example 4 - Impossible Notification:
A company shared data with a processor that subsequently went out of business. Notification is impossible because the recipient no longer exists. The controller documents this for accountability.
Implementation Best Practices:
- Maintain records of all data recipients (Article 30 processing records help here)
- Establish notification procedures and templates
- Document when notification is impossible or disproportionate
- Include notification obligations in processor contracts
- Track which recipients were notified and when
- Respond to data subject requests for recipient information
- Consider automated notification systems for high-volume scenarios
Common Mistake: Only rectifying data in your own systems without notifying processors and third parties who received the data, leaving incorrect information in the broader ecosystem.