Notification of a Personal Data Breach to the Supervisory Authority (Article 33 GDPR) (Chapter 5, Section 1) — Guide to the GDPR

Pursuant to Article 33(1) GDPR:

In the case of [1] a personal data breach, the controller shall [2] without undue delay and, where feasible, not later than [3] 72 hours after [4] having become aware of it, [5] notify the personal data breach to the supervisory authority competent in accordance with Article 55, unless the personal data breach [6] is unlikely to result in a risk to the rights and freedoms of natural persons. [7] Where the notification to the supervisory authority is not made within 72 hours, it shall be accompanied by reasons for the delay.

Pursuant to Article 33(2) GDPR, a similar obligation weighs on the processor, which:

shall notify the controller without undue delay after becoming aware of a personal data breach.

Pursuant to Article 4(12) GDPR:

personal data breach’ means [1] a breach of security leading to the accidental or unlawful [2] destruction, [3] loss, [4] alteration, unauthorised [5] disclosure of, or [6] access to, personal data transmitted, stored or otherwise processed.

In line with that definition, a personal data protection breach is a ‘consequential’ breach of the security of information concerning personal data, i.e. a breach of security resulting in adverse irreversible effects.

This definition focuses on a breach of the integrity and confidentiality of data, but mistakenly omits the idea of a breach of data availability. In its guidelines concerning the notification of data breaches, the Article 29 Working Party European Data Protection Board (EDPB) states directly that a breach of access to data is also a data protection breach if it results in the risk of a breach of rights and freedoms. Whether the letter of the law or the views of the European Union (EU) Regulator are most important is open to discussion. Let us take a closer look at this issue.

If we break down the definition of a data protection breach into parts, we can identify the following elements:

– destruction of personal data – a situation where data cease to exist in a form usable by the controller.

– alteration of personal data – damage (accidental or unlawful) to data as a result of which the data are altered or spoiled, becoming incomplete, partially illegible or defective.

– loss of personal data – a situation where data continue to exist, but the controller loses control over them or access to them or is no longer in possession of them.

Unauthorised or unlawful processing includes cases where personal data are disclosed or made available to recipients not authorised to obtain them or obtain access to them, as well as all other forms of processing in breach of the provisions of the General Data Protection Regulation (GDPR).

Note that the definition of a personal data protection breach does not include a temporary loss of data availability, from which even the principle of data protection is given the name ‘integrity and confidentiality’ rather than just ‘data security’. But let us not be deceived by this omission of inaccessibility in the definition of a personal data protection breach. As we show below, the Article 29 Working Party Guidelines also refer to such a situation (e.g., a momentary loss in the availability of medical data when there is a need to conduct surgery).

In the opinion of the Article 29 Working Party (to which we subscribe), there are three types of personal data protection breaches, one for each of the three fundamental aspects of information security. These are breaches of: confidentiality, integrity and availability.

A breach of confidentiality involves the disclosure of personal data to an unauthorised person, often including loss of unsecured data (e.g., loss of an unencrypted pen drive).

If the controller is in a relationship with the recipient, knows the recipient’s procedures and other important details that indicate it is trustworthy, the controller can ask it to return or safely destroy the data it has obtained. In other words, this means a situation where the controller has justifiable certainty as to the recipient and can expect that the recipient will not read or use the improperly sent data but will follow instructions concerning the return thereof.

Article 4(12), Article 5(1)(f), Article 32(2) GDPR refer to a breach of availability, and as usual for GDPR wording of these provisions may be misleading. Article 4(12) and Article 5(1)(f) GDPR refer to ‘accidental loss, destruction’. Article 32(2) GDPR refers to ‘accidental or unlawful destruction, loss’. Neither of those provisions refers to ‘temporary inaccessibility’.

Despite those ambiguities, breach of availability of personal data in the meaning of GDPR must be understood in line with general principles of information security knowledge, and it is understood that way. The fact that Article 5(1)(f) misses ‘unlawful destruction or loss’ referred to in Article 32(2) GDPR is easily cured when we note that ‘unlawful destruction or loss’ amounts to ‘unlawful or unauthorised processing’ mentioned in Article 5(1)(f) GDPR. As for temporary loss of availability, Article 29 Working Party (EDPB) Guidelines on Personal data breach notification under Regulation 2016/679 (17/EN WP 250) rightly explain that ‘If the lack of availability of personal data is likely to result in a risk to the rights and freedoms of natural persons, then the controller will need to notify’ and support this view with the following example:

The third type of data protection breach is a breach of integrity, that is the unauthorised alteration of the content of personal data.

Losing a paper page containing personal data is a breach of personal data protection, and so is inadvertently allowing someone to look at someone’s files on your laptop screen while reading in a train.

However, notification to a data supervisory authority is not necessary if the breach is ‘unlikely to result in a risk to the rights and freedoms of natural persons’.

Taking into consideration that the definition of risk to the rights and freedoms of natural persons includes ‘varying likelihood’, it is not easy to decrypt what the EU legislator meant by the ‘unlikely risk’. Does it refer to a low likelihood of any risk (which would practically cover any case except for resurrection) or to a low likelihood of any risk higher than low risk? We believe the second option is correct and that situations when a likelihood of a risk higher than low is low, there is no need to notify a breach to a data protection authority.

In our opinion, the GDPR’s provision on data breach notification is one of the worst pieces of EU legislation known, requiring not only calculating likelihood of adverse effects of a breach but also multiplying it by the same likelihood and by severity of a breach.

In practical terms, however, let us try to assume that a notification to a supervisory authority is needed when unless it is unlikely that something wrong happens to a data subject’s rights or freedoms.

Proving that despite a breach the risk to rights and freedoms of natural persons is low.

The GDPR provides specific, measurable time periods for notifying a breach of personal data.

The time period for a controller is ‘without undue delay’, but:

Whether notification has been made without undue delay is determined theoretically taking account of: (i) the nature and severity of the personal data protection breach, (ii) the consequences thereof and (iii) its potential adverse effects on the data subjects. In practice, if a data controller fits into seventy-two hours that will certainly be without undue delay, as seventy-two-hour deadline is tight enough.

A processor must notify the personal data controller of a breach ‘without undue delay’. As we explain when discussing the entrustment of processing, the Article 29 Working Party Guidelines concerning notification of personal data breaches state that a processor should notify the controller of a breach soon enough to allow the controller to notify the supervisory authority within seventy-two hours of being made aware of the breach by the processor. This approach is hard to accept due to operational problems with communication and control. The operational problem can be overcome somewhat if the processor immediately notifies the controller that it ‘suspects’ there has been a breach and allows the controller to take part in its efforts to clarify the situation. Not that we believe all data processors will be eager to notify their clients about a suspicion of data breach until they are sure the milk is spilled. At any rate, until the guidelines are updated we recommend you take them into consideration and act as suggested above.

Allegedly, an organisation learns of an information security breach only after some time – three months on average, and from the press. The public disclosure of the most talked-about recent breaches was made after about a year, although the organisations involved knew about them much earlier, if not at once.

A controller is obliged to implement internal procedures that make it possible to detect and manage breaches. To this end, it may use available threat detection and prediction tools. It is also worth implementing tolerance for error in your organisational culture.

Here we need to specify exactly when we confirm a breach. According to the Article 29 Working Party, a controller determines there has been a breach at the moment when it has sufficient certainty that a security incident occurred that has resulted in a breach of personal data security. When no breach has yet been determined, but the event has already occurred, the controller’s most important task is to investigate the event and evaluate its effects in order to determine whether there has actually been a personal data security breach.

The Article 29 Working Party uses fuzzy terms such as ‘a reasonable degree of certainty’, ‘not always immediately clear’, ‘on another occasion some time will be needed to determine that a personal data breach did occur’ or ‘a short investigation time’. It is hard to avoid getting the impression that the idea was not to give a precise answer.

In any case, the controller must act at once, making a quick evaluation and thinking it over later (after taking an initial decision on whether there was or was not a breach). Until better guidelines are available, it is better to assume that, from the time you receive information on a suspected breach (e.g., notification of a suspected breach), you have seventy-two hours to determine whether or not there really was a breach, and seventy-two hours to prepare a notification and submit it to the supervisory authority. Why not less or more time? The time cannot be shorter because, from the operational perspective, seventy-two hours is already very demanding, especially if the breach took place at the processor or subprocessor. Nor can it be longer because, since the EU legislator established seventy-two hours as the period for urgent notification, this is the measure we have to comply with.

An essential part of an action plan is to make an evaluation of the potential risk for natural persons that allows you to determine whether you are obliged to notify the breach. You should then make an additional evaluation, taking account of all the circumstances (a context of the breach). The importance of recognising a breach, of evaluating the risk for natural persons, and of notifying a breach where necessary are emphasised in Recital 87 GDPR. The faster you ascertain a breach, the faster you can react. It is possible for a controller to make an initial assessment of the risk that may be posed by a breach as part of a data protection impact assessment or within a risk analysis.

The GDPR does not introduce any requirement as to the form in which the supervisory authority is to be notified of a data protection breach or the results of not adhering to such form. Due to practical reasons, and especially the short seventy-two-hour deadline, a notification will be done electronically.

In a notification, a controller must include all the information specified in Article 33(1) sentence 2 and Article 33(3) GDPR. A notification must include, at least:

Under the GDPR, a submission need not immediately contain all of the elements specified in Article 33(3). These can be supplemented successively if all of the required information cannot be immediately included in the notification.

Pursuant to Article 33(1) GDPR, if a controller notified the supervisory authority later than with seventy-two hours, it must explain the delay. Let us note that GDPR acknowledges that there will be situations where ‘without undue delay’ means longer than seventy-two hours. This is indicated by the use in Article 33(1) of the formulation ‘where feasible, not later than 72 hours’. This means that if, in a given situation, meeting the seventy-two-hour deadline is not possible, then providing notification later on will still fall within the basic expression of ‘without undue delay’. Nevertheless, in each case, you exceed seventy-two hours for notifying a breach you should explain yourself.

Article 28(3) GDPR states:

contract or other legal act shall stipulate, in particular, that the processor assists the controller in ensuring compliance with the obligations pursuant to Articles 32 to 36 taking into account the nature of processing and the information available to the processor.

In addition, Article 33(2) GDPR specifies that if a controller uses the services of a processor, the processor is obliged to notify the controller of any personal data protection breach ‘without undue delay’.

The GDPR does not specify any deadline, but, in line with the Article 29 Working Party Guidelines, a processor should notify the controller immediately, and then successively send information on progress made. Here as well, the seventy-two-hour period for a controller to give notification is the point of reference. Above, we commented (unkindly) on the Article 29 Working Party’s request that the controller’s seventy-two hours starts running from the moment the processor learned about a breach.

A data controller need not notify a data protection breach to the supervisory authority when:

the personal data breach is unlikely to result in a risk to the rights and freedoms of natural person.

It is not totally unlikely that those who worded the GDPR knew what they exactly meant by ‘unlikely risk to the rights and freedoms’; still it is hard to believe looking at the words used. It is likely they knew that the likelihood of the ‘risk’ in question refers to a risk of subsequent violation of rights or freedoms. Still, wording of respective provisions of the GDPR (Article 33(1) and 34(1) is a mastery of ambiguity.

Let us start with an observation that a breach of confidentiality often equals to a breach of privacy – this when data fall into hands of an unauthorised person. So, as to a breach of privacy there is no assessment of likelihood. Therefore we believe in such situations Article 33(1) GDPR requires a data controller to assess what subsequent negative consequences for rights and freedoms of a data subject could take place.

Then we need to ask ourselves that question what the GDPR means by ‘unlikely risk’. Taking into consideration that ‘risk’ in the meaning of the GDPR is a result of a relationship between likelihood and severity of a breach, we would end up calculating a result of multiplying [likelihood of likelihood of further negative consequences multiplied by severity of those potential negative consequences] by [likelihood of further negative consequences multiplied by severity of those potential negative consequences]. That sounds nonsensical. So, probably the EU legislator meant by ‘likelihood of risk’ simply likelihood of negative consequences.

At the end of the day, we believe that a data controller may resign from notifying a supervisory authority if further/subsequent (other than those which directly constitute a data breach) negative consequences (breach of rights or freedoms) for data subjects affected are ‘unlikely’, which should be true even for minor subsequent breaches of rights and freedoms. In plain words: if it is unlikely that something wrong happens, you do not need to notify your supervisory authority.

It is the controller itself that must evaluate whether there is a risk of a breach of human rights and freedoms. It should do so based on objective criteria (such as existing experience in connection with similar cases, knowledge about information security) and taking account of the circumstances (context) of the breach of personal data security.

Furthermore, please note that, although a loss of access to a controller’s systems may be only temporary and may not entail any direct consequences for natural persons, the very fact that a network has been broken into should be seen as a potential breach of confidentiality that must be notified. A controller must always consider all possible consequences of a breach.

An example of a situation in which there is a small probability of a personal data protection breach, and in which notification to the authority is not required, is where personal data are deleted as a result of a telecommunications system error but are recovered immediately from a backup copy.

If there is a leak of data that are publicly available, e.g. on the company’s website, this also causes no risk to natural persons and is not treated as a breach.

In Guidelines on Personal data breach notification under Regulation 2016/679 (17/EN WP 250), the Article 29 Working Party (EDPB), as usual in a complicated seemingly self-contradictory way, tackles the issue of losing control over encrypted data. Article 29 Working Party starts with stating ‘a confidentiality breach of personal data that were encrypted with a state of the art algorithm is still a personal data breach, and has to be notified (our example: loss of an encrypted pen drive) but at least it does not need to be communicated to data subjects affected (because they are not really affected) unless there are no backups of data lost.’ Straight from there the same Guidelines go to a more reasonable conclusion, contradicting the first quoted that ‘if personal data have been made essentially unintelligible to unauthorised parties and where the data are a copy or a backup exists, a confidentiality breach involving properly encrypted personal data may not need to be notified to the supervisory authority.’

We do not agree with the first quote but we do agree with the second. Assuming an algorithm and a password are strong, a likelihood of decrypting is very small (unless we are discussing a targeted attack from a highly skilled private hacker or a national or foreign cyber-intelligence agency, likelihood of which needs to be assessed as well). Therefore in case we lose well protected encrypted data, we believe it is unlikely data are going to be compromised, so there would be no need to notify such breach to a supervisory authority and no need to inform data subjects.

At the same time, in line with our understanding, under the guidelines on notifying a personal data protection breach, if personal data become in principle impossible to be read by unauthorised persons, and if those data constitute a copy or another backup copy of them exists, then there is no obligation to notify the supervisory authority of a breach of availability of such data or confidentiality of appropriately encrypted personal data. Here there is only a small probability that such a breach could pose a risk to the rights and freedoms of natural persons. Of course, this also means that those natural persons need not be notified. The same guidelines insist on re-evaluation of the risk if new circumstances occur – e.g., a vulnerability of an encryption program/algorithm is disclosed. However, we believe only in case of a suspicion of a targeted attack that would really matter.

The ‘triggers’ for notifying the authority and persons under Articles 33 and 34 GDPR are described using the words ‘unless the personal data breach is unlikely to result in a risk’ of a breach and ‘a high risk of a breach’. The risk assessment methodology recommended by CNIL involves a four-level scale (negligible, low, high, maximal). A leak need not be notified to the supervisory authority only when the risk is negligible, while data subjects concerned need not be notified unless the risk is high.

Regardless of whether or not a breach requires notification, a controller should record every breach, in view of the GDPR principle of accountability.

While it is the controller that determines the manner and form of documenting breaches, there are certain rules for recording information that must be followed in every case. Pursuant to Article 33(5) GDPR, a controller must record information on a breach, encompassing the cause, the course of events and what personal data were compromised. A record should also include the effects and consequences of the breach, and what remedial action was taken by the controller.

The Article 29 Working Party also recommends documenting a justification of the decision taken in response to the breach. Specifically, this means documenting the reasons for a decision not to give notification of a breach. The controller must state the reasons why it deems that the risk of a breach of the rights and freedoms of natural persons is unlikely (Recital 85 GDPR). If the controller judges that one of the conditions described in Article 34(3) GDPR has been met, it should be able to provide relevant evidence that this is so.

Documentation must be kept in a way that, on the basis thereof, the supervisory authority can verify whether the obligations resulting from Article 33 GDPR have been duly met.

Despite the GDPR refers only to the term ‘data protection breach’ in reality controllers and processors need to record and control all ‘incidents’ (a term not defined by the GDPR for mysterious reasons) to demonstrate compliance with duties relating to data protection breaches.

Incidents, in plain words, are situations when data protection (information) security rules are broken, or data (information) security is compromised or exposed or (as for suspicions) we suspect that is the case. A simple example: someone left the office open for a night. Most likely it has not led to any data protection breach, but data protection security rules, of course, have been broken. Another example: someone at a telecom left their desk without blocking their computer and a journalist managed to copy billing information of a certain politician. It resulted in a country-wide data breach – that journalist published those billings, and they had been used in criminal investigations and commented widely in the press. In this case, an incident (leaving your working station without securing it) led to a personal data breach.

We recommend registering also ‘suspected incidents’. In reality, we recommend to treat every internal notification of a breach as a notification of a suspicion of a breach. A competent person or competent body with a particular organisation should then confirm a breach and evaluate its potential consequences. It is not only about ‘gaining time’, a competent situation assessment requires expertise or at least proper training.

The GDPR provides for administrative liability for a breach of any of the provisions of Article 33 GDPR. For example, a failure to meet the obligations concerning documentation allows for imposing an administrative fine as referred to in Article 83(4)(a) GDPR, namely, in the amount of up to EUR 10 million, and in case of a business of over EUR 500 million global total annual turnover for the previous financial year in the amount of up to 2% of that turnover.

To manage the whole process concerning the obligation to notify the supervisory authority of a personal data breach, you should have the following in place:

#1.1 The Provision

#1.2 What Is a Breach of Personal Data Protection?

#1.2.1 Data Protection Breach According to the Article 29 Working Party

#1.2.1.1 Breach of Confidentiality

#1.2.1.2 Breach of Availability

#1.2.1.3 Breach of Integrity

#1.3 Must Every Breach Be Notified?

#1.3.1 Notification Procedure

#1.3.1.1 Time for Notification

#1.3.1.2 Time Period for a Processor

#1.3.2 Determination of a Breach

#1.3.3 Notification: Content and Form

#1.3.4 Delayed Notification

#1.3.5 Obligations of a Processor

#1.4 When, in the Case of a Data Protection Breach, Is It Not Necessary to Notify the Supervisory Authority?

#1.4.1 Practical Issues

#1.4.2 Documentation of Breaches

#1.4.3 Administrative Sanctions

#1.5 Elements of the Breach Notification System