Notifying Data Subjects About a Data Protection Breach (Article 34 GDPR) (Chapter 5, Section 2) — Guide to the GDPR

Pursuant to Article 34(1 and 2) GDPR:

The obligation to notify data subjects about incidents such as a data leak is a very uncomfortable duty for a controller. Similar to the obligation to notify the supervisory authority of a data protection breach under Article 33 GDPR, this is something new that organisations must face. It is not just that notifying ‘victims’ of a leak or other data security-related incident is yet another organisational and procedural hurdle for companies; fulfilling that obligation can also entail consequences, from the need to deal with difficult customers having a lot of time on their hands to the loss of reputation.

A controller is obliged to notify data subjects if a personal data breach is ‘likely to result in a high risk to rights and freedoms of natural persons’.

Similarly as in Article 33(1) GDPR, we need to understand what ‘likely to result in a high risk’ means. Let us note once again that ‘risk’ in the meaning of GDPR already includes ‘likelihood’; therefore, ‘likely to result in a high risk’ should translate to ‘likely to result in likelihood and severity of potential consequences constituting high risk’. Does not get clearer though. It is even less clear when we note that Article 34(1) GDPR refers to ‘high risk to rights and freedoms of natural persons’ and not to ‘a natural person’ instead. Does it mean that we need to inform a data subject if there is high risk to that particular data subject or if we get to a conclusion that overall a breach in question generates a secondary high risk (e.g., where consequences for one person affected would usually be not that bad but there is a lot of affected persons, making the overall risk score amounting to ‘high’)? Who writes these laws? I happened to propose a certain wording of data processing and cloud computing rules, but I am not at all responsible for the wording of commented provisions.

Using common sense as a rule of thumb, you should inform a person about a breach in case you establish considerable likelihood (if something is likely it means that its likelihood is considerable) of severe consequences to that person. You should also inform persons about a breach (or make a public announcement) if a scale of persons affected is such that an overall assessment of a risk resulting from a breach is ‘high’ according to your methodology. I usually use an example of wrong addressing of an electrical bill (already mentioned in this book in another context). If an electricity company addresses wrongly one bill, the risk most likely will be negligible. However, if 10,000 bills go out to wrong addressees, one may concern a power delivery point unknown to one’s wife, leading her to a conclusion that her husband is renting another apartment and not telling her about it and draw further conclusions. And in result, an electricity company becomes co-responsible for a divorce. Which seems to be a pretty severe consequence for persons affected. There is, however, an interesting and more common variation of the same example. The same electric bill may be wrongly dispatched to an address of residence of a buyer instead of an address for delivery indicated in the power supply agreement, leading to a higher likelihood of similar consequences.

When a controller becomes aware that a breach has taken place, it must evaluate the likelihood of high risk. It should consider criteria similar to those used when notifying a breach to the supervisory authority under Article 33 GDPR. But it is easier to avoid notifying natural persons than the authority.

The rights and freedoms of data subjects that can be breached as a result of an incident are the fundamental rights and freedoms granted on the basis of European law (e.g., the Charter of Fundamental Rights of the EU and the European Convention on Human Rights), e.g.:

the prohibition on discrimination on the basis of sex, race, colour, language, religion or political or other opinion (Article 14 ECHR);
human dignity (Article 1 CFR);
personal data protection (Article 8 CFR);
the right to legal protection of one’s private and family life, honour and good reputation;
privacy of correspondence;
ownership.

Recital 75 GDPR describes situations where a breach of the rights or freedoms of data subjects may arise.

Pursuant to Article 34(3) GDPR, no notification is required in situations where:

In practice, those provisions make it possible to avoid notifying data subjects about an incident, even if the theoretical risk of a breach of their rights or freedoms is high. A controller, then, may take preventive measures (i) before an incident happens, or corrective measures (ii) to deal with consequences of an incident post factum.

Preventive measures referred to in Article 34 GDPR are those which can secure data even after a breach. Mostly that would be encryption of data or data carriers (USB sticks, mobile phones, computer drives), location tracking solutions (e.g., find my Iphone IOs function) and enabling remote erasure solutions amount to preventive measures as well, though they, of course, require further corrective measures, i.e. tracking and finding lost data ASAP or enforcing a remote erasure. And let us not forget here about creating backups following a reasonable backup policy which constitutes preventive measure against loss of data availability of course.

Corrective measures that eliminate the need to notify data subjects include, e.g., remotely destroying data from lost media (remote erasure), concluding a confidentiality agreement with persons who became acquainted with personal data without authorisation, restoring destroyed data from backup copies.

An entity that has to inform a person about a breach should do so in a way that is clear, simple and easy for the recipient to understand. The scope of communication to a data subject about a breach of personal data protection is similar to that of a notification to the supervisory authority but need not contain information on the scale of the leak or on other ‘injured parties’.

Such a communication should include:

the nature of the breach,
the contact details of the DPO or another contact point,
the possible consequences of the breach,
the measures employed or proposed by the controller in order to manage the breach and minimise any adverse effects it may have.

The GDPR does not directly impose any form for informing data subjects about a breach of their personal data. Expressly, it states only that the communication must be expressed in clear, plain language and must describe certain elements in connection with the breach.

To the extent possible a communication must be documented (in writing, email, text message, instant message) so that the data subject has the opportunity to read the content multiple times. In its guidelines concerning notification of personal data breaches, the Article 29 Working Party permits other documented forms of communication, including text messages, electronic communicator messages and banners published on a website (for more on an announcement instead of a communication, see section 2.4.3).

The time in which an entity is obliged to give communication of a breach means that the most convenient way of doing so, for both the data controller and the recipient, is in electronic form. This guarantees quick communication and allows the data subject concerned to become thoroughly familiar with the content of the communication.

Article 34(3)(c) GDPR introduces an additional, supposed exemption from the obligation to inform data subjects directly about a breach. If the communication:

would involve disproportionate effort … there shall instead be a public communication or similar measure whereby the data subjects are informed in an equally effective manner.

A decision on whether to replace direct communication with an announcement should be documented and justified both in principle and by the type of announcement you choose to make. The guidelines on notifying breaches permit announcements on prominent websites or in newspapers.

A mere note in the press or information in the company’s website news or corporate blog would not be sufficient in most circumstances. However, if, for example, a breach affects only employees, a data controller may choose to place an announcement at the entrance to the place of work (assuming a controller does not maintain email accounts for all employees).

A communication should be sent ‘without undue delay’, that is as fast as is reasonably possible. Communication must be made when the risk of a breach of rights and freedoms is high. If the possible consequences of that risk to natural persons are not severe, it is possible to work during normal business hours and in that way perform all the actions needed to issue the communication. If, however, the consequences could be very serious, you must act at once, regardless of whether it is after hours or a weekend. Remember, Article 33 GDPR places a ‘mental anchor’ for counting a deadline around ‘72 hours after having become aware of’ a breach.

Should you first notify a breach to a supervisory authority or inform data subjects? Taking into consideration that Article 33(3)(d) GDPR requires a data controller to describe measures to mitigate adverse effects of a breach, you should probably start by informing affected persons or at least explain in the notification to the supervisory authority whether you are going to do it and why it requires more time.

The guidelines on notifying breaches indicate that, in line with Recital 86 GDPR, communication to data subjects should be made in cooperation with the supervisory authority. This is how it is in practice since persons affected by a breach are usually notified after the controller has notified the supervisory authority. It would be imprudent not to take advantage up the opportunity to agree on the communication with the authority, or at least to try to do so (e.g., you can immediately include your proposals in the notification sent to the authority).

In certain cases, where the harm to natural persons could be serious and occur at once, those persons should be notified even before notification is sent to the authority. In any case, you should not delay informing data subjects hoping to get instructions from a supervisory authority. First, you will not be able to rely on the lack of reaction of a supervisory authority to justify your delay. Second, it will be hard for you to contest a supervisory authority’s instructions even if they are hysterical if you let them come in before you act.

Simplifying, if consequential risk resulting from a data breach is low, you do not need to notify a supervisory authority and if the risk is high, you need to not only notify a supervisory authority but also inform data subjects affected.

So, how to calculate the consequential risk to the rights and freedoms of data subjects resulting from a data breach?

EU Agency for Network and Information Security issued in 2013 Recommendations for a methodology of the assessment of the severity of personal data breaches. The Recommendation is often referred to when discussing notification and information duties under the GDPR. We are not big fans of the Recommendation, though we acknowledge it is somehow helpful especially because it grades specific types of data from the perspective of consequences of the severity of a breach. However, the Recommendation does not at all tackle the other dimension of the risk to rights and freedoms the GDPR requires us to calculate, which is likelihood. So, how to calculate likelihood and how to combine severity with likelihood?

Targeted attacks. If we have reasons to believe that a breach resulted from a targeted attack we notify a supervisory authority. Targeted attacks are done for purpose. Plus we are very cautious in establishing if that breach created high risk to rights and freedoms of affected or potentially affected persons.

Accidental breaches. In case of (assumed) accidental breaches we rely more on calculating probabilities.

How to calculate likelihood. We would calculate likelihood of specific consequences of a breach using Bernoulli Trials. We would calculate separate likelihood for consequences of a specific severity. However, we would not be calculating separately every likelihood of every possible adverse consequences of a breach for a data subject affected. We would focus on answering two questions: First, if high risk to rights and freedoms of affected persons exist, we need to inform them about a breach. Second, if any negative consequence to persons affected is more than unlikely, we need to notify a supervisory authority.

How to combine severity with likelihood. We would start combining both dimensions of risk to rights and freedoms by imagining and listing potential negative consequences of a specific breach. Second, we would group them into minimal, low, high, maximum severity consequences groups.

Then we would check which consequences have ‘high-risk potential’ and calculate their likelihood – to exclude of verify information duty (Article 34 GDPR). Again, we could rely on Bernoulli Trials to quantify the likelihood, if possible.

Then we would see if we are able to logically prove that any negative consequences of the breach for persons affected are unlikely, and if we fail to do so, we would notify a supervisory authority.

What you see above is bits and pieces from our practical experiences and works on risk assessment methodologies. Such approach would work for large organisations as long as they hire specialists capable of calculating probability. The same approach will not work at all for small and medium enterprises unless they outsource a ready to use solution (which will be a black box for them anyway). So, a much simpler way of calculating the consequential risk to rights and freedoms of data subjects needs to be developed for small and medium enterprises. We have developed such simplified, quantifiable and parameterised methodology built partially on ENISA’s approach. We are planning to release it soon for public discussion.

#2.1 Preliminary Remarks

#2.2 High Risk of a Breach of Rights and Freedoms

#2.2.1 Rights and Freedoms

#2.3 Exceptions from the Obligation to Notify

#2.3.1 Preventive Measures

#2.3.2 Corrective Measures

#2.4 Communicating a Breach to a Data Subject

#2.4.1 Content of a Communication

#2.4.2 Form of Communication

#2.4.3 An Announcement Instead of a Direct Communication

#2.4.4 Time for Informing about a Breach

#2.5 Cooperation with the Supervisory Authority

#2.6 Closing Remarks: How to Calculate Consequential Data Breach Risk Assessment