The General Data Protection Regulation ("GDPR") entered into force on May 25, 2018 ("GDPR Day"). Introducing a new regime for the protection of personal data in the European Union ("EU"), the GDPR imposes new obligations on organizations dealing with personal data. 

Under the GDPR, a personal data breach is defined as "a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data transmitted, stored or otherwise processed." Personal data breaches include not only the unauthorized access or disclosure of data but also the accidental destruction or alteration of data. While limited breach notification regimes were in place in the EU before the GDPR, how to deal with these types of incidents is among the biggest paradigm shifts to which organizations and supervisory authorities have had to adapt since GDPR Day.

The GDPR mandates controllers and processors to have technical and organizational measures in place to ensure an appropriate level of security for personal data. They should have the ability to detect, address and report data breaches in a timely manner. Many internal procedures were drafted in anticipation of the entry into force of the GDPR. Now, two months after GDPR Day, here are five lessons learned from data breach management, as, yes, numerous personal data breaches have occurred since then, of which authorities were notified, in pretty significant numbers and in a variety of sectors. 

Lesson No. 1: Speaking to a supervisory authority should be done with caution.

In breach notifications, there are no "off the record" conversations with supervisory authorities. Reporting a non-reportable breach with the supervisory authority to discuss the occurrence of a breach or whether the particular incident is, in fact, one to be reported may expose your organization to further investigations. It is the controller's responsibility to assess whether it is facing a reportable personal data breach.

This doesn't mean that any conversation with a supervisory authority should be avoided; in the course of the notification process, controllers may engage with authorities in a number of matters, such as whether the affected individuals need to be informed or what steps should be taken to mitigate risks. Furthermore, controllers will engage with supervisory authorities when dealing with a notification that has to occur in phases. The GDPR recognizes that controllers will not always have all of the necessary information concerning a breach within 72 hours of becoming aware of it (for instance, when an in-depth forensic investigation may be necessary to fully establish the nature of the breach). In these cases, the supervisory authority may engage and provide guidelines on how and when additional information should be provided. For this process to work, supervisory authorities should be responsive in replying to notifications and communicating with organizations (especially in the early stages, as this is where the process typically develops). Experience shows an uneven response rate among supervisory authorities. 

Lesson No. 2: Knowing when and how to communicate with affected individuals is not easy.

Dealing with breach management response makes it clear that, in order for the process to run as smoothly as possible, procedures should be in place to cover how to deal with the breach as well as how to assess the risks related to it. Given the tight timeline for communicating to the affected individuals, drawing a line between what is a "risk" and what is a "high-risk" breach is not an easy task. 

Controllers may rely on tools and existing methodologies (often developed prior to GDPR Day) to objectify the high-risk nature of the breach. In their assessment, they should keep in mind the rationale for the GDPR’s communication requirement to affected individuals (i.e., primarily to allow them to take steps to protect themselves from any negative consequence of the breach), as that is the benchmark they will be assessed against if there are subsequent complaints or investigations. Striking the right balance often proves to be challenging. 

In the same vein, experience shows that it is difficult for organizations faced with communication requirements in the EU to assess whether to communicate with all affected individuals wherever they are located (with some supervisory authorities’ breach notification forms even requiring controllers to provide information where affected individuals are located even when outside the European Union at the time a notification is made to them). 

Lesson No. 3: Dealing with processor-level data breaches requires more than having a DPA in place.

Many organizations carried out a remediation exercise with their vendors as part of their GDPR compliance preparation. Responding to breaches under the GDPR makes it clear that it is essential that data protection agreements ("DPAs") provide details on how the processor will notify the controller, what types of information must be provided, and what the expected timeline is expected. 

Under the GDPR, the controller retains overall responsibility for the notification of data breaches to the supervisory authority and communication to data subjects. Processors have an important role to play: they must enable the controller to comply with its obligations. Having merely a general clause in the DPA stating that the processor will assist the controller in dealing with data breaches is not enough to support the controller's ability to adequately manage the breach and effectively comply with the GDPR. 

Most supervisory authorities have developed notification forms (and, no, they are not harmonized) that are available online. Such forms require controllers to disclose specific information about the breach (e.g., description of the breach, the types of personal data involved, the data subjects concerned, measures that have been taken to mitigate the risks, etc.). In order to fill in the form appropriately (as well as assess the risks raised by the breach), controllers have to receive accurate and granular information about incidents from their processors. 

Lesson No. 4: Cross-border breaches are a lively test on how comfortable you are of the election of your lead supervisory authority ("LSA").

Confronted with a cross-border breach, controllers should revisit their policies and procedures to check if they have substantiated the election of their LSA in a solid way. In case of cross-border breaches with controllers who are eligible to appoint an LSA, the selected authority is the one to be notified, irrespective of where the data subjects are located or where the breach(es) happened. It is, however, up to controllers to determine if they have satisfied the conditions to appoint an LSA, if they appointed the "right" one and if they documented the choice adequately. Controllers tend to affirmatively stand behind the choice they made when electing their LSA, avoiding multiple notifications to authorities. Experience will tell whether or not LSAs will use their rights to challenge such assessment and, as the case may be, launch separate enquiries against controllers who haven’t engaged in multiple notifications. Keep in mind that the European Data Protection Board (formerly the Working Party No. 29), in its breach guidelines, has warned controllers that "if the controller has any doubt as to the identity of the lead supervisory authority then it should, at a minimum, notify the local supervisory authority where the breach has taken place."

Non-EU based controllers don't benefit from such a one-stop-shop mechanism, increasing the burden and efforts for compliance on their side when facing cross-border breaches.

Lesson No. 5: The GDPR is important, as are other legal frameworks. 

For many organizations with an international presence, having to deal with a personal data breach under the GDPR often requires parallel notification requirements to other regulatory authorities or bodies in multiple jurisdictions. Navigating multiple regulatory frameworks requires cross-border and cross-office cooperation by a team that has a clear understanding of the overall picture. Working in silos cannot be an option, and some preparatory work and training is necessary. 

Other notification obligations may include, for instance, notification under Regulation (EU) 910/2014 on electronic identification and trust services for electronic transactions in the internal market (requiring providers to notify their supervisory body of a breach) or under the NIS Directive, which imposes on both operators of essential services and digital service providers the obligation to notify security incidents to their competent authority. Controllers should also be aware of any additional notification duties under other applicable regimes (such as financial services and prudential authorities). 

Bonus Lesson: Breach work starts on Fridays.

We knew from experience around the world that breach work is a weekend thing. It is often the case that the controller’s clock starts to tick on Fridays. We hope you will not be confronted by and have to deal with such incidents, but should you have questions or experience any issues, pick up your phone and contact us; our team will assist you in dealing with such issues, around the clock.

To learn more on the nature of reported breaches and the actual number of cases reported to certain European supervisory authorities, see (among many other sources) the following IAPP (International Association of Privacy Professionals) publications: