GDPR & Data Breach: Takeaways from the WP29 Guidance

Published On November 13, 2017 | By Catherine Essig and Jason Wool | Data Security, International
TwitterLinkedInFacebookRedditCopy LinkEmailPrint

This post has been updated to reflect that the WP29 has since released updated guidance.

Most companies handling personal data of EU residents know that the General Data Protection Regulation (“GDPR”) will impose mandatory data breach notification requirements, but the Regulation leaves several fundamental questions unanswered. The Article 29 Working Party (WP29) has issued draft guidelines on data breach reporting under the GDPR that help answer some of these questions.

Should I notify?

Assessing Risk. Whether a company is required to notify supervisory authorities and affected individuals requires an assessment of the risk of harm created by the breach. Appropriate supervisory authorities generally must be notified of a breach, unless the breach is unlikely to result in a risk to the rights and freedoms of individuals. In contrast, notification to affected individuals is only required where there is likely a high risk of harm.

How should a company assess risks in light of these thresholds? Unsurprisingly, WP29 points first and foremost to Recital 85 of the GDPR, noting that notification is triggered by risk “when the breach may lead to physical, material or non-material damage for the individuals whose data have been breached.” This would include damage like discrimination, identity theft or fraud, financial loss, and damage to reputation, especially when “special categories” of personal data are impacted. To assess whether a breach poses a risk sufficient to require notification, WP29 recommends considering the following factors:

  • Type of Breach
  • Nature, Sensitivity, and Volume of Data
  • Ease of Identification
  • Severity of Consequences
  • Special Characteristics of Individuals
  • Number of Affected Individuals

According to WP29, an organization could conclude that notification is not necessary in some contexts. One example would be where personal data is accidentally sent to a “trusted” third party with which the data controller has “an ongoing relationship.” In this example, WP29 indicates that a controller “may have a level of assurance with the recipient and can reasonably expect that party not to read or access the data sent in error, and to comply with its instructions to return it.” 

Another example is if the data is encrypted. Notification may be unnecessary if you have rendered data “essentially unintelligible to unauthorized parties” through state-of-the-art encryption. The fact that the data is encrypted is not determinative, however.  For example, loss or alteration of encrypted data can have negative consequences if the controller has no adequate backups. Even where backups exist, WP29 suggests there may still be a reportable breach depending on the length of time that was required to restore the data, as well as the effect of the lack of availability. Additionally, encryption software or algorithms may become vulnerable, or a controller may learn that the encryption key was also compromised. Encryption technology also may become outdated, and WP29 suggests that risks must be re-evaluated over time. Exactly what will qualify as state-of-the-art encryption remains unclear.

When should I notify?

Supervisory Authorities. The GDPR requires notification of a breach to supervisory authorities “without undue delay” and, if feasible, within 72 hours after becoming aware of the breach. WP29 says you are “aware” when you have a “reasonable degree of certainty” that a security incident has occurred and personal data has been compromised. Unless a breach is immediately obvious, WP29 suggests that you may undertake a short investigation to determine whether a breach has occurred before being considered “aware.” (How long this investigation period may last in practice remains to be seen.) Once aware, the controller can undertake a more detailed investigation, but notification to the supervisory authority would nonetheless be required within 72 hours.

Controllers are responsible for reporting breaches to supervisory authorities even where the breach occurs at the processor level. Importantly, a controller is deemed aware of a breach once its processor is aware of it.* Accordingly, WP29 suggests that controllers and processors have contractual arrangements in place to ensure that processors immediately report breaches back to controllers. The WP29 does not specify what types of contractual arrangements might be useful, but a requirement that a processor inform the controller of a breach within 24 hours of detection would be one way to help ensure a controller has sufficient time to prepare for notification.

Individuals. The GDPR also requires you to communicate a breach to affected individuals “without undue delay.” WP29 notes that the risk threshold for individual notice is higher than for notice to supervisory authorities “and not all breaches will therefore be required to [be] communicated to individuals, thus protecting them from unnecessary notification fatigue.” It remains unclear exactly what the “without undue delay” standard requires in this context. WP29 suggests that “without undue delay” means as soon as possible, keeping in mind that you should provide specific information about steps individuals should take to protect themselves. Where there is an immediate threat of identity theft, or where particularly sensitive categories of personal data are compromised, WP29 states that you should notify individuals immediately. Annex B to the guidelines provides useful examples of personal data breach scenarios and whether and why notification is required.

Phased Reporting and Delays. A controller may not always be able to notify within 72 hours. The GDPR allows for phased reporting, meaning you can follow up with information that was not initially available. WP29 says this is particularly applicable for complex breaches that require in-depth forensic investigation to fully establish the nature of the breach and how personal data was compromised. WP29 recommends informing supervisory authorities if you intend to provide information at a later point. You must also provide supervisory authorities with justifications for any delays, including phased notifications. An example of a justified delay provided by the guidelines would be where a controller may experience multiple breaches over a short period of time, affecting large numbers of individuals in the same way, such that it would be best to send a delayed, meaningful notification representing several very similar breaches.

Overall, WP29’s guidance makes clear that it is important for controllers and processors to plan in advance.  In preparation for the GDPR, you should have processes in place to 1) quickly detect and contain a breach; 2) assess risk to individuals; 3) notify competent supervisory authorities and individuals when necessary; and 4) contain and recover the breach.

*The final version of the Guidelines on Personal Data Breach Notification changed this aspect of the WP29’s initial interpretation. The final version provides that a controller is deemed to be “aware” of a processor-level personal data breach once its processor informs it of the breach.


About The Authors

Jason Wool’s practice focuses on cybersecurity, including cyber risk management, incident response, and compliance with global data protection laws, regulations, and standards, including the PCI-DSS. He has advised organizations ranging from small businesses to Fortune 500 companies during complex, privileged computer crime investigations; provided ongoing advice on the development of cybersecurity programs and cybersecurity governance structures; conducted tabletop exercises and other data breach simulations; and assisted clients with large scale audits to determine compliance with complex cybersecurity standards.