I’ve been engaged with data breach notification for many years and from many perspectives. I wrote what was probably the first-ever breach notification letter in 2002, before California’s landmark law had taken effect.

The breach that inspired the law took place on a state server and exposed the personal information, including Social Security numbers, of more than a quarter-million state government employees. It was discovered in the spring of 2002, while the legislation requiring notification would not be in effect until July 2003. As head of the California Office of Privacy Protection, a state office that advocated for consumer privacy rights, I urged that we anticipate the law’s requirements and offered to draft and send out breach notices to the affected parties.

That is what we did.

In the 15 years since then, I’ve participated in many anxious meetings with state agencies attempting to decide what to do in response to the trickling in of information about a security incident that may be a data breach; testified before the California Legislature and Congress about the harm data breaches can wreak on individuals and the rationale behind the notification law; and spoken about data breach notification at numerous privacy conferences around the country. I’ve also reviewed information on more than 1,000 breaches reported to the California Attorney General and drafted recommendations in response, including proposals for updating the breach notification law, most of which were enacted.

So I was pleased to be asked to take a new look at the issue, this time from a European perspective.

Last October, when the Article 29 Working Party issued its Guidelines on Personal data breach notification under Regulation 2016/670, the Centre for Information Policy Leadership engaged me to review the draft Guidelines and prepare a written response on behalf of CIPL, incorporating the views of staff and member companies. I submitted comments to CIPL and was pleased to see that many of our recommendations (and presumably many similar suggestions of other commenters) were reflected in the final Guidelines.

Many privacy pros in the U.S., with long experience complying with breach notification laws, were staggered by the GDPR’s 72-hour notification time frame. They hoped that the guidance from the WP29 would shed some light on questions such as when the notification clock starts ticking, what constitutes “awareness” of a breach, and how to determine the level of risk that triggers notification. The draft Guidelines did address these issues, with helpful points suggesting that the WP29 had drawn lessons from the experience of other jurisdictions.

But the light shed was sometimes dimmed by contradictions and inconsistencies, particularly in the area of risk assessment.  

The EU General Data Protection Regulation takes a risk-based approach to data protection, requiring organizations to assess the risks that their data processing activities may pose to individual rights and freedoms and to manage and mitigate such risks with technological and organizational measures. The data breach notification provisions in Articles 33 and 34 rely heavily on risk assessment and in particular on the determination of the level of risk that triggers notification in specific breach situations. The draft Guidelines offered many examples and elucidations that could be helpful to controllers and processors in making such determinations, but some of the discussion was unclear or seemed inconsistent with the GDPR.

There were inconsistencies in the discussion of the risk assessment process and in the examples provided. While the discussion generally adopted the standard definition of the level of risk as determined by both the severity of possible consequences and the likelihood of their occurrence, at several points the WP29 failed to mention likelihood and focused only on the severity of consequences. The final Guidelines correct this, amending the language in some of the example breaches to substitute “likely consequences” for “potential consequences.”

The WP29 initially asserted that certain factors make a breach automatically “high risk,” regardless of likelihood. One such factor was the number of individuals affected, where the draft asserted that a large number affected should per se be assumed to pose a likely risk or a high risk to those individuals’ rights and freedoms. In the final Guidelines, the WP29 adds qualifying language to the discussion of number affected as a factor, emphasizing that “the key is to consider the likelihood and severity of the impact on those affected.” We also recommended that the WP29 could add clarity to the discussion by using the term “notifiable breach” to refer to a breach that meets the standard for notifying at least the supervisory authority, and the final Guidelines do this.

There were also concerns about controller-processor and joint-controller responsibilities.

In the draft, the WP29 recommended some specific notification practices between processor and controller, rather than recognizing that such practices are subject to contract and that as the party bearing the ultimate legal responsibility for breach notification, the controller should have the discretion to determine the procedures its processors are to follow. The final Guidelines acknowledged the controller’s contractual discretion regarding such arrangements, noting that the controller may want to conduct the investigation itself and that a processor need not, and in some cases could not, assess the likelihood of risk before notifying the controller.

On the matter of a time limit for a processor to notify a controller of a data breach, the draft Guidelines went beyond the GDPR’s requirement of notification “without undue delay” to recommend that a processor provide “immediate notification” to the controller, an unclear and unrealistic expectation. The final Guidelines change this to a recommendation that the processor notify the controller “promptly.”

The draft did not speak to notification procedures among joint controllers. The final Guidelines, however, added a section on joint controllers in which the WP29 recommends that their contractual arrangements include provisions for determining which entity will be responsible for or take the lead on meeting breach notification obligations.

The final Guidelines leave some problematic issues unchanged, including the vexing question of “availability breaches,” which do not seem to square with the GDPR’s Article 4(12) definition of “personal data breach,” nor to belong in a notification scheme with the avowed purpose of informing data subjects of “the steps they can take to protect themselves from its potential consequences.”

But on the whole, the WP29 is to be applauded for taking the comments of reviewers into account when preparing their final document.

photo credit: theilr parallel lines via photopin (license)