This post has been updated to reflect that the WP29 has since released updated guidance.
In our recent blog post on the Article 29 Working Party’s draft guidance on the GDPR’s breach notification requirements, we explored some of the questions answered – as well as left unanswered – by the WP29. In this post, we take a look at perhaps the most daunting element of the GDPR’s breach notification regime: how breach notification to supervisory authorities within 72 hours might work in practice. For companies used to breach notification requirements in the U.S., 72 hours probably seems very short (although it is not unprecedented here). As a result, it is likely that many U.S. companies will need to modify their incident response plans and internal security cultures to ensure that this short timeline for reporting can be met regularly in the EU.
Overview
Article 33(1) generally requires controllers to “without undue delay and, where feasible, not later than 72 hours after having become aware of it, notify [a] personal data breach to the supervisory authority competent . . . unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons.” Article 33(2) requires processors to “notify the controller without undue delay after becoming aware of a personal data breach.”
In light of Article 33 and the WP29’s draft guidance, controllers may need to take steps to:
- Implement processes to:
- Identify and quickly assess incidents to determine if the awareness threshold has been met
- Ensure that legal or other compliance personnel are notified immediately about incidents
- Collect evidence responsive to the content requirements of the requisite breach notifications
- Take steps to ensure that processors provide notice of possible breaches as quickly as possible to provide the controller with sufficient time to investigate and respond;
- Roll out specific training and awareness campaigns to educate personnel about GDPR-related process changes and address logistical challenges; and
- Conduct GDPR-specific table top exercises.
Awareness of the Personal Data Breach
The first step in preparing to meet the 72-hour reporting requirement is to understand the timeline of a breach in this framework. The text of Article 33 makes clear that notification to regulators within 72 hours is triggered by the controller’s awareness of a personal data breach (“PDB”) – not by the occurrence of the breach itself. The draft WP29 guidance interprets the term “aware” as “a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised.” The WP29 says that controllers may “undertake a short period of investigation” to determine whether a PDB has occurred and perform a risk assessment, but the 72-hour notification requirement is triggered as soon as the controller establishes “with a reasonable degree of certainty” that a PDB has occurred and that the conditions of Article 33(1) have been met. In some cases, this means that the controller may not be able to complete forensic analysis prior to triggering the 72-hour window. The WP29 suggests that this type of “more detailed” investigation can follow later, although it should not interfere with the 72-hour notification window.
The WP29 takes the position that a controller is deemed to be aware of a PDB whenever its processor informs it of the PDB.* Nonetheless, it will be important to require processors by contract to notify the controller of any actual or suspected PDBs as soon as possible, as discussed below.
Internal Reporting
In reality, whether an incident is clearly a PDB or requires further investigation, it will be important for controllers to implement reporting procedures for personnel who identify or receive notice of possible PDBs. The procedures should require incidents to be reported immediately, and should designate a single group or person to be responsible for receiving initial reports and funneling these reports to counsel or other compliance personnel. Likewise, controllers may need to put in place a reporting structure that ensures counsel or other relevant compliance personnel are kept up to date about factual developments when investigating possible PDBs. Both of these goals could be accomplished by establishing a generic email address that is distributed to a group of relevant stakeholders that includes counsel and/or compliance personnel. Establishing a generic email address could also help comply with the WP29’s recommendation to direct all information concerning security-related events to “a responsible person or persons with the task of addressing incidents, establishing the existence of a breach and assessing risk.”
The trigger for the 72-hour deadline for regulator notification is fundamentally legal in nature, so lawyers and other compliance personnel should be responsible for making the ultimate call as to whether an incident constitutes a PDB requiring regulator notification.
Implementing these types of process modifications will probably require at least some changes to most controllers’ incident response plans (“IRPs”). Accordingly, this action item should be kept in mind as organizations assess their readiness under Articles 32, 33, and 34 of the GDPR.
Addressing Logistical Challenges
It will also be important to assess and address some of the practical obstacles to implementing these process changes. IT and information security personnel may be reluctant to share information about possible breaches with legal and compliance departments, or proper reporting and escalation procedures may simply be overlooked during the frenzy of the response process. Poorly trained or understaffed technical support teams can also pose challenges to investigation efforts. Of course, if the incident occurs on the systems of a processor, any of these issues will be compounded by the additional issue of investigating an incident on the premises of a third party.
Every organization faces some of these challenges, and it will be important to minimize them to the extent possible in light of the steep fines controllers may face under the GDPR. According to the WP29, violations of the 72-hour reporting requirement can lead to an administrative fine of up to the greater of €10,000,000 or 2% of total worldwide annual turnover. Also, the WP29 notes that a failure to properly report to the supervisory authority “could reveal either an absence of existing security measures or an inadequacy of the existing security measures” that could lead a regulator “to issue sanctions for failure to notify or communicate the breach (Articles 33 and 34) on the one hand, and absence of (adequate) security measures (Article 32) on the other hand, as they are two separate infringements.”
Some of the most effective tools for combatting these logistical challenges are (i) the implementation of robust training and awareness campaigns and (ii) conducting one or more tabletop exercises to test the organization’s incident response processes in the context of realistic PDB scenarios. For the latter, it will likely be of highest value to the organization to conduct these exercises after revisions to the IRP are complete and training and awareness materials have been rolled out.
Execute the Right Kind of Investigation
It will also be important to identify in advance what information should be collected (if possible) as soon as a suspected PDB is reported and what actions may need to be taken to address the incident, such as potential sources of evidence and incident containment measures.
During the investigation, controllers should attempt to gather information that would be useful in assessing the likelihood that a security incident will “result in a risk to the rights and freedoms of natural persons.” The relevant factors for that analysis are discussed in our previous post on the WP29 guidance. In addition, the controller should try to collect data that is responsive to the content requirements of the supervisory authority notification, namely:
- The nature of the personal data breach including, where possible, the categories and approximate number of data subjects concerned and the categories and approximate number of personal data records concerned;
- The likely consequences of the PDB; and
- The measures taken or proposed to be taken to address the PDB, including, where appropriate, measures to mitigate its possible adverse effects.
The WP29 asserts, however, that prior to notification to the supervisory authority, the “focus should be directed towards addressing the adverse effects of the breach rather than providing precise figures.” Phased reporting can be used to report information as it becomes known over time, as discussed in our initial blog post.
Considerations for Contracting with Processors
Article 28(3) of the GDPR requires that processing “be governed by a contract or other legal act,” which must address, among other things, a requirement that the processor “assists the controller in ensuring compliance with the obligations pursuant to Articles 32 to 36.” In light of this requirement (and, indeed, best practices concerning vendor risk management), controllers should consider requiring their processors to provide immediate notification of any actual or suspected PDB (ideally with some sort of cap, like 24 hours) so that the controller has enough time to investigate and comply with reporting requirements. This type of provision may also help a controller defend against liability in the event that a processor’s late reporting causes delayed reporting to regulators.
Controllers may, depending on the context and risk of particular processing, also want to tie notification of incidents to a Service Level Agreement. The contract can also address additional breach-related topics such as for-cause security audit rights, good faith cooperation in the investigation, cost responsibility, and even data subject notification responsibility, among others.
*This article originally stated that a controller is deemed by the WP29 to be aware of a breach once its processor is aware of it. However, 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.
