The data breach I (Notifying the supervisory authority of the data breach)
The GDPR defines the notion of data breach and contains rules on when it is mandatory for controllers to report a data breach to the competent supervisory authority and when they are obliged to communicate such breaches to the data subjects. Controllers are also required to document personal data breaches. In addition, processors are required to notify the controller without undue delay after becoming aware of a personal data breach.
The Article 29 Data Protection Working Party (WP29) issued guidelines on the personal data breach notification on 3 October 2017, which are being finalized, that interpret the respective provisions of the GDPR (Articles 33-34 and Recitals 75-76 and 85-88) and give some examples of possible data breaches.
Below, a Q&A will follow on the issue of notifying the supervisory authorities of data breaches and how risks to the rights and freedoms of individuals can be assessed. I will analyse in separate posts the issues in relation to communicating data breaches to the data subjects and, respectively, the obligation to document the data breaches.
1. What is a data breach?
A personal data breach (data breach) means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed. Under the definition, it can be established that a security breach not involving personal data is not considered a data breach, however, all personal data breaches are security breaches.
Data breaches can typically be classified in the below three categories:
- “confidentiality breach”: any unauthorized or accidental disclosure of, or access to, personal data (for example, a hacker retrieves protected content and passwords from a website);
- “integrity breach”: where there is an unauthorised or accidental alteration of personal data (e.g. a hacking is committed in a way that the hacker deletes from or alters certain data in a data base);
- “availability breach”: accidental or unauthorised loss of access to, or destruction of, personal data (e.g. a laptop is stolen and no back-up of the data is available).
It is worth noting that if e.g. an employee accidentally deletes a file from the employer’s system and the file is recovered from the back up immediately or within a very short period of time, then the breach does not qualify as a data breach but rather only as a security breach.
If a security breach occurs, one of the first things a controller has to decide is if the security breach involves any personal data, in other words, if the breach qualifies as a data breach. This is because the administrative obligations in Articles 33-34 of the GDPR are all connected to data breaches and not to security breaches. However, this does not at all mean that controllers and processors do not have any obligation under the GDPR as far as security breaches are concerned. This is because controllers and processors are required to implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk. As the WP29 puts it, “a key element of any data security policy is being able, where possible, to prevent a breach and, where it nevertheless occurs, to react to it in a timely manner.”
2. When do controllers have to notify the supervisory authority?
In the case of a personal data breach, the controller must without undue delay and, where feasible, not later than 72 hours after having become aware of it, notify the competent supervisory authority of the personal data breach, unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons.
Since risk serves as a trigger for notifying the authority, it is indispensable to be able to properly analyse the data breach and identify the potential negative consequences of the same. When it comes to assessing the risks, certain factors must be taken into account, such as, for example,
- the type of breach (confidentiality, integrity or availability);
- the nature, sensitivity and volume of personal data;
- the issue of how easy it is to identify the individuals affected by the data breach;
- the likelihood and severity of consequences for individuals;
- if vulnerable individuals are affected (e.g. children, the elderly, people with disease);
- the number of affected individuals;
- the characteristics of the data controller, its activities.
For further details, please see the response to question 4 below.
3. When does a controller become "aware" of a data breach?
The WP29 says in its guidelines that once the controller has a reasonable degree of certainty that a data breach has occurred, the controller should be regarded as having become aware of the data breach.
In practice, it is not always obvious when there is a reasonable degree of certainty and this is an issue that has to be examined and decided on a case by case basis. The guidelines add, though, that “after first being informed of a potential breach by an individual, a media organisation, or another source, or when it has itself detected a security incident, the controller may undertake a short period of investigation in order to establish whether or not a breach has in fact occurred. During this period of investigation the controller may not be regarded as being “aware”.”
It is essential that the controller starts the investigation as soon as possible and establishes if a security breach or a data breach has taken place. To be able to do so, it is of utmost importance to have appropriate internal processes in place so that the controller is able and well prepared to detect and address the breach.
4. When is a data breach likely to result in a risk to the rights and freedoms of natural persons?
Recitals (75)-(76) of the GDPR may serve as guidance as to what may be regarded as a risk to the rights and freedoms of individuals (for example, identity theft, identity fraud, discrimination, financial damages, damage to reputation, loss of confidentiality of personal data protected by professional secrecy, economic or social disadvantage). The WP29 says in its guidelines that if the controller is not certain if there may be / is a risk to the rights and freedoms of individuals, the controller should err on the side of caution and assume that there is a risk and notify the supervisory authority.
The WP29 also provides examples for data breaches which trigger a notification obligation. For example, if
- personal data of individuals are stolen from a secure website;
- a controller experiences a ransomware attack resulting in personal data being encrypted;
- an individual calls the bank and reports that she has received a monthly statement for someone else;
- medical records in a hospital are unavailable for hours due to a cyber attack;
- a webshop suffers a cyber-attack and usernames, passwords and purchase history are published online by the attacker;
- a direct marketing email is sent to recipients in the “to:” or “cc:” field so that the recipients can see the email address of other recipients.
However, if, for example, a laptop which contains encrypted data is stolen and the controller has a back up of the data, no notification is necessary (as long as the encryption key is not compromised), and if there is a power outage lasting for minutes at the controller’s call center then, likewise, the availability breach is not reportable to the authority.
It is worth noting that, in December 2013, the European Union Agency for Network and Information Security (ENISA) in cooperation with the Data Protection Authorities of Greece and Germany issued recommendations for a methodology of the assessment of the severity of personal data breaches. The document was produced with the objective of providing both data controllers and national authorities with a quantitative tool / methodology for assessing the severity of data breaches. Due to the general nature of the methodology, both data controllers and national authorities need to apply special care when using the methodology as it cannot take into account all kinds of breaches. Thus, the specificities of the given breach need to be addressed accordingly. Still, the document provides very useful information on how to assess a breach.
In the document, a formula was set up based on which severity may be assessed. The formula reads as follows:
SE = DPC x EI + CB
(SE means severity of the breach, DPC stands for data processing context, EI means ease of identification of the relevant individuals and CB stands for circumstances of the breach.)
The document explains how the factors in the formula need to be evaluated and categorizes the breaches into four classes as per the below:
- Low risk. If the SE value is less than 2, the risk is considered to be low. Low risk means that “individuals either will not be affected or may encounter a few inconveniences, which they will overcome without any problem (time spent re-entering information, annoyances, irritations, etc.).”;
- Medium risk. If the SE value is equal to or more than 2 and less than 3, there is a medium level of risk. Medium risk means that “individuals may encounter significant inconveniences, which they will be able to overcome despite a few difficulties (extra costs, denial of access to business services, fear, lack of understanding, stress, minor physical ailments, etc.).”;
- High risk. If the SE value is equal to or more than 3 and less than 4, the risk is considered to be high. High risk means that “individuals may encounter significant consequences, which they should be able to overcome albeit with serious difficulties (misappropriation of funds, blacklisting by banks, property damage, loss of employment, subpoena, worsening of health, etc.).” and
- Very high risk. If the SE value is equal to or more than 4, the risk is considered to be very high. Very high risk means that “individuals may encounter significant, or even irreversible, consequences, which they may not overcome (financial distress such as substantial debt or inability to work, long-term psychological or physical ailments, death, etc.).”
Within the DPC factor, the document differentiates four categories of data: simple, behavioural, financial and sensitive. In addition to the types of data breached, the data volume, special characteristics of the controller and the individuals and the nature of data must also be taken into account and evaluated. The fact if the data are inaccurate or are published also has to be assessed. The document contains a scoring method for the calculation of the DPC factor, the result of which can be 1, 2, 3 or 4 points.
As regards the EI factor, the document defines four levels of EI: negligible, limited, significant and maximum. The lowest score (negligible) means that it is extremely difficult to identify the individual based on the data breached, whereas the highest score (maximum) means that identification is ascertainable directly from the data breached. The document contains guidance according to which the EI value can be either 0.25, 0.50, 0.75 or 1, depending on the data breached, i.e. direct (e.g. name) or indirect (e.g. phone number, email address) identifiers.
Concerning the CB factor, it has to be assessed if the breach is a confidentiality, integrity or availability breach and if there was a malicious intent. The CB value can be 0, 0.25 or 0.5, depending on the circumstances.
Once the assessment is done, two additional factors need to be taken into account. Although, they do not affect a prior the scoring, they are important for the final assessment. Namely, (i) if the number of individuals exceeds 100 and (ii) if the data breached is unintelligible. For example, if a strong encryption was used to protect the data and the encryption key is intact, this can substantially decrease the negative consequences of the breach.
The document adds that the severity level could be integrated into the notification the controller sends to the supervisory authority and could be used by the controller and the competent authority to assess if there is a need to notify the data subjects.
5. What information must be provided to the supervisory authority?
The notification must at least
a) describe 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;
b) communicate the name and contact details of the data protection officer or other contact point where more information can be obtained;
c) describe the likely consequences of the personal data breach;
d) describe the measures taken or proposed to be taken by the controller to address the personal data breach, including, where appropriate, measures to mitigate its possible adverse effects.
6. Is it allowed to notify the supervisory authority in phases?
Yes. In so far as it is not possible to provide all the information at the same time, the information may be provided in phases without undue further delay.
Depending on the circumstances of the case, it can happen that the controller simply cannot make a complete notification within 72 hours of becoming aware of the data breach. In this case, the controller is urged to make a notification within 72 hours giving as many details as possible and indicating that the data breach is still being investigated and that further details will follow later.
If the controller is not certain if a given data breach must be notified to the supervisory authority, it is advisable to notify. This is because there is no sanction for reporting a breach which later turns out not to be a data breach or a reportable data breach. As opposed to this, if no notification is made but the controller should have made one, the authority may impose a fine for breach of an administrative obligation. In addition, the authority may also inspect if, for example, the controller has appropriate technical and organizational measures in place.
7. Which supervisory authority must be notified if the data breach affects individuals in more than one Member State?
Whenever a data breach affects the personal data of individuals in more than one Member State and notification is required, the controller will need to notify the lead supervisory authority, i.e. the supervisory authority of the Member State in which the controller’s main establishment or only establishment is situated.
As regards a controller with establishments in more than one Member State, the main establishment is the place of its central administration in the Union, unless the decisions on the purposes and means of the processing of personal data are taken in another establishment of the controller in the Union and the latter establishment has the power to have such decisions implemented, in which case the establishment which took such decisions is to be considered as being the main establishment.
Multinational companies carrying out cross-border processing are advised to prepare a breach response plan in a way that it is also assessed to which supervisory authority the data breach must be reported. The WP29 stresses that the controller may also proactively report the data breach to a supervisory authority which is not the lead supervisory authority. Furthermore, if the controller notifies the lead supervisory authority of the data breach, the controller should indicate in the report if the data breach has likely affected individuals in other Member States.
8. What happens if the controller makes a delayed notification?
The WP29 guidelines admit that there may be scenarios where it may be justified to notify the supervisory authority of the data breach (or rather a series of similar breaches) after more than 72 hours of becoming aware of the breach(es). The guidelines say that “depending on the circumstances, it may take the controller some time to establish the extent of the breaches and, rather than notify each breach individually, the controller instead organises a meaningful notification that represents several very similar breaches, with possible different causes.”
According to the GDPR, in the event that the notification is made after 72 hours it must be accompanied by reasons for the delay. The guidelines emphasize that the fact that the GDPR allows for delayed notification under certain circumstances “should not be seen as something that regularly takes place.”
Overall, it is advisable to avoid making a notification after 72 hours and rather make the notification within 72 hours and then supplement the notification later as necessary.
9. Are processors required to notify anyone about a data breach?
Yes. The processor is required to notify the controller without undue delay after becoming aware of a personal data breach.
It is important that the controller makes the processor aware of this obligation because the guidelines stress that the controller uses the processor to achieve its purposes; therefore, in principle, the controller should be considered as being “aware” of the data breach once the processor has become aware. Taking this into account, it is good practice to have such measures in place that ensure that the processor notifies the controller of any breach without undue delay after becoming aware of the data breach, so that the controller can fulfill its obligations in due course.
10. When is a notification not required?
If the security breach does not affect personal data it is not considered to be a data breach, thus no notification is required. Furthermore, if the data breach is “unlikely to result in a risk to the rights and freedoms of natural persons”, no notification is required.
As per the guidelines, for example, the loss of a securely encrypted mobile device utilized by the controller and its staff would not require notification (if the controller has a back up of the data) because such a breach is unlikely to pose a risk to the rights and freedoms of individuals. If the encryption key which was properly generated remains within the secure possession of the controller, then the personal data would be unintelligible to a hacker. However, if it later turns out that the key was compromised or the encryption is vulnerable, the level of risk may change and notification may be required.
Taking the above into account, controllers are urged to monitor a data breach even after the initial assessment and after going through the steps of the breach response plan and addressing the breach as per Articles 33 and 34 of the GDPR. This is because, over time, the risk level may increase to an extent that notification and the taking of certain (additional) measures may become necessary.
11. Are there additional notification obligations under other laws?
Yes. For example, providers of electronic communication services are required to notify the competent national authority of personal data breaches no later than 24 hours after the detection of the personal data breach, where feasible. There are and there may be some other laws as well which set forth notification obligations for controllers active in certain sectors, thus controllers should always be vigilant and should not think that if they have complied with the notification obligation under the GDPR there can be no additional notification obligation.
In my next post, I will address issues concerning the notification of data breaches to the data subjects. For details, please click here.
Zoltán Balázs Kovács, J.D. (LL.M.), Partner, Szecskay Attorneys at Law, Budapest, Hungary (zoltan.kovacs@szecskay.com)
The contents of this post are intended to provide only a general overview of the subject matter and do not qualify as legal advice.
