Guidelines 9/2022 on personal data breach notification under GDPR

Guidelines 9/2022 on personal data breach notification

under GDPR

Version 2.0

Adopted 28 March 2023

Adopted 2

Version history

Version 1.0

10 October 2022

Adoption of the Guidelines (updated version of the previous

guidelines WP250 (rev.01) adopted by the Working Party 29

and endorsed by the EDPB on 25 May 2018) for a targeted

public consultation.

Version 2.0

28 March 2023

Adoption of the Guidelines following the targeted public

consultation on the subject of data breach notification for

controllers not established in the EEA.

Adopted 3

TABLE OF CONTENTS

0 PREFACE ............................................................................................................................... 5

INTRODUCTION ............................................................................................................................ 5

I. PERSONAL DATA BREACH NOTIFICATION UNDER THE GDPR ................................................... 7

A. Basic security considerations ..................................................................................................... 7

B. What is a personal data breach? ................................................................................................ 7

1. Definition ................................................................................................................................... 7

2. Types of personal data breaches................................................................................................ 8

3. The possible consequences of a personal data breach ............................................................... 9

II. ARTICLE 33 - NOTIFICATION TO THE SUPERVISORY AUTHORITY ............................................ 10

A. When to notify ............................................................................................................................. 10

1. Article 33 requirements............................................................................................................ 10

2. When does a controller become “aware”? .............................................................................. 11

3. Joint controllers........................................................................................................................ 13

4. Processor obligations ............................................................................................................... 13

B. Providing information to the supervisory authority..................................................................... 14

1. Information to be provided ...................................................................................................... 14

2. Notification in phases .............................................................................................................. 15

3. Delayed notifications ............................................................................................................... 16

C. Cross-border breaches and breaches at non-EU establishments ................................................. 17

1. Cross-border breaches ............................................................................................................. 17

2. Breaches at non-EU establishments ......................................................................................... 17

D. Conditions where notification is not required ............................................................................. 18

III. ARTICLE 34 – COMMUNICATION TO THE DATA SUBJECT .................................................... 20

A. Informing individuals ................................................................................................................... 20

B. Information to be provided ......................................................................................................... 20

C. Contacting individuals .................................................................................................................. 21

D. Conditions where communication is not required ...................................................................... 22

IV. ASSESSING RISK AND HIGH RISK ............................................................................................. 23

A. Risk as a trigger for notification ................................................................................................... 23

B. Factors to consider when assessing risk....................................................................................... 23

V. ACCOUNTABILITY AND RECORD KEEPING ................................................................................ 26

A. Documenting breaches ................................................................................................................ 26

B. Role of the Data Protection Officer .............................................................................................. 27

VI. NOTIFICATION OBLIGATIONS UNDER OTHER LEGAL INSTRUMENTS ................................... 28

Adopted 4

VII. ANNEX ................................................................................................................................. 30

A. Flowchart showing notification requirements ............................................................................. 30

B. Examples of personal data breaches and who to notify .............................................................. 31

Adopted 5

The European Data Protection Board

Having regard to Article 70(1)(e) and (l) of the Regulation 2016/679/EU of the European Parliament

and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing

of personal data and on the free movement of such data, and repealing Directive 95/46/EC,

(hereinafter “GDPR”),

Having regard to the EEA Agreement and in particular to Annex XI and Protocol 37 thereof, as amended

by the Decision of the EEA joint Committee No 154/2018 of 6 July 2018

Having regard to Article 12 and Article 22 of its Rules of Procedure,

Having regard to the Article 29 Working Party Guidelines on Personal data breach notification under

Regulation 2016/679, WP250 rev.01,

HAS ADOPTED THE FOLLOWING GUIDELINES

0 PREFACE

1. On 3 October 2017, the Working Party 29 (hereinafter “WP29”) adopted its Guidelines on Personal

data breach notification under Regulation 2016/679 (WP250 rev.01)

, which were endorsed by the

European Data Protection Board (hereinafter “EDPB”) at its first Plenary meeting

. This document is a

slightly updated version of those guidelines. Any reference to the WP29 Guidelines on Personal data

breach notification under Regulation 2016/679 (WP250 rev.01) should, from now on, be interpreted

as a reference to these EDPB Guidelines 9/2022.

2. The EDPB noticed that there was a need to clarify the notification requirements concerning the

personal data breaches at non-EU establishments. The paragraph concerning this matter has been

revised and updated, while the rest of the document was left unchanged, except for editorial changes.

The revision concerns, more specifically, paragraph 73 in Section II.C.2 of this document.

INTRODUCTION

3. The GDPR introduced the requirement for a personal data breach (henceforth “breach”) to be notified

to the competent national supervisory authority

(or in the case of a cross-border breach, to the lead

authority) and, in certain cases, to communicate the breach to the individuals whose personal data

have been affected by the breach.

4. Obligations to notify in cases of breaches existed for certain organisations, such as providers of

publicly-available electronic communications services (as specified in Directive 2009/136/EC and

Regulation (EU) No 611/2013)

. There were also some Member States that already had their own

References to “Member States” made throughout this document should be understood as references to “EEA

Member States”.

WP29 Guidelines on Personal data breach notification under Regulation 2016/679 (WP250 rev.01) (last revised

and updated on 6 February 2018), available at https://ec.europa.eu/newsroom/article29/items/612052.

See https://edpb.europa.eu/news/news/2018/endorsement-gdpr-wp29-guidelines-edpb_en.

See Article 4(21) GDPR.

See http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex:32009L0136 and http://eur-

lex.europa.eu/legalcontent/EN/TXT/?uri=CELEX%3A32013R0611

Adopted 6

national breach notification obligation. This might included the obligation to notify breaches involving

categories of controllers in addition to providers of publicly available electronic communication

services (for example in Germany and Italy), or an obligation to report all breaches involving personal

data (such as in the Netherlands). Other Member States might had relevant Codes of Practice (for

example, in Ireland

). Whilst a number of EU data protection authorities encouraged controllers to

report breaches, the Data Protection Directive 95/46/EC

, which the GDPR replaced, did not contain a

specific breach notification obligation and therefore such a requirement was new for many

organisations. The GDPR makes notification mandatory for all controllers unless a breach is unlikely to

result in a risk to the rights and freedoms of individuals

. Processors also have an important role to

play and they must notify any breach to their controller

5. The EDPB considers that the notification requirement has a number of benefits. When notifying the

supervisory authority, controllers can obtain advice on whether the affected individuals need to be

informed. Indeed, the supervisory authority may order the controller to inform those individuals about

the breach

. Communicating a breach to individuals allows the controller to provide information on

the risks presented as a result of the breach and the steps those individuals can take to protect

themselves from its potential consequences. The focus of any breach response plan should be on

protecting individuals and their personal data. Consequently, breach notification should be seen as a

tool enhancing compliance in relation to the protection of personal data. At the same time, it should

be noted that failure to report a breach to either an individual or a supervisory authority may mean

that under Article 83 GDPR a possible sanction is applicable to the controller.

6. Controllers and processors are therefore encouraged to plan in advance and put in place processes to

be able to detect and promptly contain a breach, to assess the risk to individuals

, and then to

determine whether it is necessary to notify the competent supervisory authority, and to communicate

the breach to the individuals concerned when necessary. Notification to the supervisory authority

should form a part of that incident response plan.

7. The GDPR contains provisions on when a breach needs to be notified, and to whom, as well as what

information should be provided as part of the notification. Information required for the notification

can be provided in phases, but in any event controllers should act on any breach in a timely manner.

8. In its Opinion 03/2014 on personal data breach notification

, WP29 provided guidance to controllers

in order to help them to decide whether to notify data subjects in case of a breach. The opinion

considered the obligation of providers of electronic communications regarding Directive 2002/58/EC

and provided examples from multiple sectors, in the context of the then draft GDPR, and presented

good practices for all controllers.

9. The current Guidelines explain the mandatory breach notification and communication requirements

of the GDPR and some of the steps controllers and processors can take to meet these obligations. They

See https://www.dataprotection.ie/docs/Data_Security_Breach_Code_of_Practice/1082.htm

See http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex:31995L0046

The rights enshrined in the Charter of Fundamental Rights of the EU, available at http://eurlex.europa.eu/legal-

content/EN/TXT/?uri=CELEX:12012P/TXT

See Article 33(2) GDPR. This is similar in concept to Article 5 of Regulation (EU) No 611/2013 which states that

a provider that is contracted to deliver part of an electronic communications service (without having a direct

contractual relationship with subscribers) is obliged to notify the contracting provider in the event of a personal

data breach.

See Articles 34(4) and 58(2)(e) GDPR.

This can be ensured under the monitoring and review requirement of a DPIA, which is required for processing

operations likely to result in a high risk to the rights and freedoms of natural persons (Article 35(1) and (11).

See WP29 Opinion 03/2014 on Personal Data Breach Notification http://ec.europa.eu/justice/data-

protection/article29/documentation/opinion-recommendation/files/2014/wp213_en.pdf

Adopted 7

also give examples of various types of breaches and who would need to be notified in different

scenarios.

I. PERSONAL DATA BREACH NOTIFICATION UNDER THE GDPR

A. Basic security considerations

10. One of the requirements of the GDPR is that, by using appropriate technical and organisational

measures, personal data shall be processed in a manner to ensure the appropriate security of the

personal data, including protection against unauthorised or unlawful processing and against accidental

loss, destruction or damage

11. Accordingly, the GDPR requires both controllers and processors to have in place appropriate technical

and organisational measures to ensure a level of security appropriate to the risk posed to the personal

data being processed. They should take into account the state of the art, the costs of implementation

and the nature, the scope, context and purposes of processing, as well as the risk of varying likelihood

and severity for the rights and freedoms of natural persons

. Also, the GDPR requires all appropriate

technological protection an organisational measures to be in place to establish immediately whether

a breach has taken place, which then determines whether the notification obligation is engaged

12. Consequently, 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.

B. What is a personal data breach?

1. Definition

13. As part of any attempt to address a breach the controller should first be able to recognise one. The

GDPR defines a “personal data breach” in Article 4(12) as:

“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.”

14. What is meant by “destruction” of personal data should be quite clear: this is where the data no longer

exists, or no longer exists in a form that is of any use to the controller. “Damage” should also be

relatively clear: this is where personal data has been altered, corrupted, or is no longer complete. In

terms of “loss” of personal data, this should be interpreted as the data may still exist, but the controller

has lost control or access to it, or no longer has it in its possession. Finally, unauthorised or unlawful

processing may include disclosure of personal data to (or access by) recipients who are not authorised

to receive (or access) the data, or any other form of processing which violates the GDPR.

Example

An example of loss of personal data can include where a device containing a copy of a controller’s

customer database has been lost or stolen. A further example of loss may be where the only copy of

a set of personal data has been encrypted by ransomware, or has been encrypted by the controller

using a key that is no longer in its possession.

15. What should be clear is that a breach is a type of security incident. However, as indicated by Article

4(12), the GDPR only applies where there is a breach of personal data. The consequence of such a

breach is that the controller will be unable to ensure compliance with the principles relating to the

See Articles 5(1)(f) and 32 GDPR.

Article 32; see also Recital 83 GDPR.

See Recital 87 GDPR.

Adopted 8

processing of personal data as outlined in Article 5 GDPR. This highlights the difference between a

security incident and a personal data breach – in essence, whilst all personal data breaches are security

incidents, not all security incidents are necessarily personal data breaches

16. The potential adverse effects of a breach on individuals are considered below.

2. Types of personal data breaches

17. In its Opinion 03/2014 on breach notification, WP29 explained that breaches can be categorised

according to the following three well-known information security principles

• “Confidentiality breach” - where there is an unauthorised or accidental disclosure of, or access

to, personal data.

• “Integrity breach” - where there is an unauthorised or accidental alteration of personal data.

• “Availability breach” - where there is an accidental or unauthorised loss of access

to, or

destruction of, personal data.

18. It should also be noted that, depending on the circumstances, a breach can concern confidentiality,

integrity and availability of personal data at the same time, as well as any combination of these.

19. Whereas determining if there has been a breach of confidentiality or integrity is relatively clear,

whether there has been an availability breach may be less obvious. A breach will always be regarded

as an availability breach when there has been a permanent loss of, or destruction of, personal data.

Example

Examples of a loss of availability include where data has been deleted either accidentally or by an

unauthorised person, or, in the example of securely encrypted data, the decryption key has been lost.

In the event that the controller cannot restore access to the data, for example, from a backup, then

this is regarded as a permanent loss of availability.

A loss of availability may also occur where there has been significant disruption to the normal service

of an organisation, for example, experiencing a power failure or denial of service attack, rendering

personal data unavailable.

20. The question may be asked whether a temporary loss of availability of personal data should be

considered as a breach and, if so, one which needs to be notified. Article 32 GDPR, “security of

processing”, explains that when implementing technical and organisational measures to ensure a level

of security appropriate to the risk, consideration should be given, amongst other things, to “the ability

to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and

It should be noted that a security incident is not limited to threat models where an attack is made on an

organisation from an external source, but includes incidents from internal processing that breach security

principles.

See WP29 Opinion 03/2014.

It is well established that “access” is fundamentally part of “availability”. See, for example, NIST

SP80053rev4, which defines “availability” as: "Ensuring timely and reliable access to and use of information,"

available at http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf. CNSSI-4009 also refers

to: “Timely, reliable access to data and information services for authorized users”. See

https://rmf.org/wpcontent/uploads/2017/10/CNSSI-4009.pdf. ISO/IEC 27000:2016 also defines “availability” as

“Property of being accessible and usable upon demand by an authorized entity”:

https://www.iso.org/obp/ui/#iso:std:isoiec:27000:ed-4:v1:en

Adopted 9

services,” and “the ability to restore the availability and access to personal data in a timely manner in

the event of a physical or technical incident”.

21. Therefore, a security incident resulting in personal data being made unavailable for a period of time is

also a type of breach, as the lack of access to the data can have a significant impact on the rights and

freedoms of natural persons. To be clear, where personal data is unavailable due to planned system

maintenance being carried out this is not a ‘breach of security’ as defined in Article 4(12) GDPR.

22. As with a permanent loss or destruction of personal data (or indeed any other type of breach), a breach

involving the temporary loss of availability should be documented in accordance with Article 33(5)

GDPR. This assists the controller in demonstrating accountability to the supervisory authority, which

may ask to see those records

. However, depending on the circumstances of the breach, it may or

may not require notification to the supervisory authority and communication to affected individuals.

The controller will need to assess the likelihood and severity of the impact on the rights and freedoms

of natural persons as a result of the lack of availability of personal data. In accordance with Article 33

GDPR, the controller will need to notify unless the breach is unlikely to result in a risk to individuals’

rights and freedoms. Of course, this will need to be assessed on a case-by-case basis.

Example

In the context of a hospital, if critical medical data about patients are unavailable, even temporarily,

this could present a risk to individuals’ rights and freedoms; for example, operations may be cancelled

and lives put at risk.

Conversely, in the case of a media company’s systems being unavailable for several hours (e.g. due to

a power outage), if that company is then prevented from sending newsletters to its subscribers, this is

unlikely to present a risk to individuals’ rights and freedoms.

23. It should be noted that although a loss of availability of a controller’s systems might be only temporary

and may not have an impact on individuals, it is important for the controller to consider all possible

consequences of a breach, as it may still require notification for other reasons.

Example

Infection by ransomware (malicious software which encrypts the controller’s data until a ransom is

paid) could lead to a temporary loss of availability if the data can be restored from backup. However,

a network intrusion still occurred, and notification could be required if the incident is qualified as

confidentiality breach (i.e. personal data is accessed by the attacker) and this presents a risk to the

rights and freedoms of individuals.

3. The possible consequences of a personal data breach

24. A breach can potentially have a range of significant adverse effects on individuals, which can result in

physical, material, or non-material damage. The GDPR explains that this can include loss of control

over their personal data, limitation of their rights, discrimination, identity theft or fraud, financial loss,

unauthorised reversal of pseudonymisation, damage to reputation, and loss of confidentiality of

personal data protected by professional secrecy. It can also include any other significant economic or

social disadvantage to those individuals

25. Accordingly, the GDPR requires the controller to notify a breach to the competent supervisory

authority, unless it is unlikely to result in a risk of such adverse effects taking place. Where there is a

See Article 33(5) GDPR.

See also Recital 86 GDPR.

Adopted 21

possible adverse consequences of the breach, such as resetting passwords in the case where their

access credentials have been compromised. Again, a controller can choose to provide information in

addition to what is required here.

C. Contacting individuals

88. In principle, the relevant breach should be communicated to the affected data subjects directly, unless

doing so would involve a disproportionate effort. In such a case, there shall instead be a public

communication or similar measure whereby the data subjects are informed in an equally effective

manner (Article 34(3)(c) GDPR).

89. Dedicated messages should be used when communicating a breach to data subjects and they should

not be sent with other information, such as regular updates, newsletters, or standard messages. This

helps to make the communication of the breach to be clear and transparent.

90. Examples of transparent communication methods include direct messaging (e.g. email, SMS, direct

message), prominent website banners or notification, postal communications and prominent

advertisements in print media. A notification solely confined within a press release or corporate blog

would not be an effective means of communicating a breach to an individual. The EDPB recommends

that controllers should choose a means that maximizes the chance of properly communicating

information to all affected individuals. Depending on the circumstances, this may mean the controller

employs several methods of communication, as opposed to using a single contact channel.

91. Controllers may also need to ensure that the communication is accessible in appropriate alternative

formats and relevant languages to ensure individuals are able to understand the information being

provided to them. For example, when communicating a breach to an individual, the language used

during the previous normal course of business with the recipient will generally be appropriate.

However, if the breach affects data subjects who the controller has not previously interacted with, or

particularly those who reside in a different Member State or other non-EU country from where the

controller is established, communication in the local national language could be acceptable, taking into

account the resource required. The key is to help data subjects understand the nature of the breach

and steps they can take to protect themselves.

92. Controllers are best placed to determine the most appropriate contact channel to communicate a

breach to individuals, particularly if they interact with their customers on a frequent basis. However,

clearly a controller should be wary of using a contact channel compromised by the breach as this

channel could also be used by attackers impersonating the controller.

93. At the same time, Recital 86 GDPR explains that:

“Such communications to data subjects should be made as soon as reasonably feasible and in close

cooperation with the supervisory authority, respecting guidance provided by it or by other relevant

authorities such as law-enforcement authorities. For example, the need to mitigate an immediate risk

of damage would call for prompt communication with data subjects whereas the need to implement

appropriate measures against continuing or similar personal data breaches may justify more time for

communication.”

94. Controllers might therefore wish to contact and consult the supervisory authority not only to seek

advice about informing data subjects about a breach in accordance with Article 34, but also on the

appropriate messages to be sent to, and the most appropriate way to contact, individuals.

95. Linked to this is the advice given in Recital 88 GDPR that notification of a breach should “take into

account the legitimate interests of law-enforcement authorities where early disclosure could

unnecessarily hamper the investigation of the circumstances of a personal data breach”. This may

mean that in certain circumstances, where justified, and on the advice of law-enforcement authorities,

the controller may delay communicating the breach to the affected individuals until such time as it

Adopted 22

would not prejudice such investigations. However, data subjects would still need to be promptly

informed after this time.

96. Whenever it is not possible for the controller to communicate a breach to an individual because there

is insufficient data stored to contact the individual, in that particular circumstance the controller should

inform the individual as soon as it is reasonably feasible to do so (e.g. when an individual exercises

their Article 15 right to access personal data and provides the controller with necessary additional

information to contact them).

D. Conditions where communication is not required

97. Article 34(3) GDPR states three conditions that, if met, do not require notification to individuals in the

event of a breach. These are:

• The controller has applied appropriate technical and organisational measures to protect

personal data prior to the breach, in particular those measures that render personal data

unintelligible to any person who is not authorised to access it. This could, for example, include

protecting personal data with state-of-the-art encryption, or by tokenization.

• Immediately following a breach, the controller has taken steps to ensure that the high risk

posed to individuals’ rights and freedoms is no longer likely to materialise. For example,

depending on the circumstances of the case, the controller may have immediately identified

and taken action against the individual who has accessed personal data before they were able

to do anything with it. Due regard still needs to be given to the possible consequences of any

breach of confidentiality, again, depending on the nature of the data concerned.

• It would involve disproportionate effort

to contact individuals, perhaps where their contact

details have been lost as a result of the breach or are not known in the first place. For example,

the warehouse of a statistical office has flooded and the documents containing personal data

were stored only in paper form. Instead, the controller must make a public communication or

take a similar measure, whereby the individuals are informed in an equally effective manner.

In the case of disproportionate effort, technical arrangements could also be envisaged to

make information about the breach available on demand, which could prove useful to those

individuals who may be affected by a breach, but the controller cannot otherwise contact.

98. In accordance with the accountability principle controllers should be able to demonstrate to the

supervisory authority that they meet one or more of these conditions

It should be borne in mind

that while notification may initially not be required if there is no risk to the rights and freedoms of

natural persons, this may change over time and the risk would have to be re-evaluated.

99. If a controller decides not to communicate a breach to the individual, Article 34(4) GDPR explains that

the supervisory authority can require it to do so, if it considers the breach is likely to result in a high

risk to individuals. Alternatively, it may consider that the conditions in Article 34(3) GDPR have been

met in which case notification to individuals is not required. If the supervisory authority determines

that the decision not to notify data subjects is not well founded, it may consider employing its available

powers and sanctions.

See WP29 Guidelines on transparency, which will consider the issue of disproportionate effort, available at

http://ec.europa.eu/newsroom/just/document.cfm?doc_id=48850

See Article 5(2) GDPR.

Adopted 23

IV. ASSESSING RISK AND HIGH RISK

A. Risk as a trigger for notification

100. Although the GDPR introduces the obligation to notify a breach, it is not a requirement to do

so in all circumstances:

• Notification to the competent supervisory authority is required unless a breach is unlikely to

result in a risk to the rights and freedoms of individuals.

• Communication of a breach to the individual is only triggered where it is likely to result in a

high risk to their rights and freedoms.

101. This means that immediately upon becoming aware of a breach, it is vitally important that the

controller should not only seek to contain the incident but it should also assess the risk that could

result from it. There are two important reasons for this: firstly, knowing the likelihood and the potential

severity of the impact on the individual will help the controller to take effective steps to contain and

address the breach; secondly, it will help it to determine whether notification is required to the

supervisory authority and, if necessary, to the individuals concerned.

102. As explained above, notification of a breach is required unless it is unlikely to result in a risk to

the rights and freedoms of individuals, and the key trigger requiring communication of a breach to data

subjects is where it is likely to result in a high risk to the rights and freedoms of individuals. This risk

exists when the breach may lead to physical, material or non-material damage for the individuals

whose data have been breached. Examples of such damage are discrimination, identity theft or fraud,

financial loss and damage to reputation. When the breach involves personal data that reveals racial or

ethnic origin, political opinion, religion or philosophical beliefs, or trade union membership, or includes

genetic data, data concerning health or data concerning sex life, or criminal convictions and offences

or related security measures, such damage should be considered likely to occur

B. Factors to consider when assessing risk

103. Recitals 75 and 76 of the GDPR suggest that generally when assessing risk, consideration should

be given to both the likelihood and severity of the risk to the rights and freedoms of data subjects. It

further states that risk should be evaluated on the basis of an objective assessment.

104. It should be noted that assessing the risk to people’s rights and freedoms as a result of a breach

has a different focus to the risk considered in a DPIA)

. The DPIA considers both the risks of the data

processing being carried out as planned, and the risks in case of a breach. When considering a potential

breach, it looks in general terms at the likelihood of this occurring, and the damage to the data subject

that might ensue; in other words, it is an assessment of a hypothetical event. With an actual breach,

the event has already occurred, and so the focus is wholly about the resulting risk of the impact of the

breach on individuals.

Example

A DPIA suggests that the proposed use of a particular security software product to protect personal

data is a suitable measure to ensure a level of security appropriate to the risk the processing would

otherwise present to individuals. However, if a vulnerability becomes subsequently known, this would

change the software’s suitability to contain the risk to the personal data protected and so it would

need to be re-assessed as part of an ongoing DPIA. A vulnerability in the product is later exploited and

See Recital 75 and Recital 85 GDPR.

See WP Guidelines on DPIAs here: http://ec.europa.eu/newsroom/document.cfm?doc_id=44137

Adopted 24

a breach occurs. The controller should assess the specific circumstances of the breach, the data

affected, and the potential level of impact on individuals, as well as how likely this risk will materialise.

105. Accordingly, when assessing the risk to individuals as a result of a breach, the controller should

consider the specific circumstances of the breach, including the severity of the potential impact and

the likelihood of this occurring. The EDPB therefore recommends the assessment should take into

account the following criteria

• The type of breach

106. The type of breach that has occurred may affect the level of risk presented to individuals. For

example, a confidentiality breach whereby medical information has been disclosed to unauthorised

parties may have a different set of consequences for an individual to a breach where an individual’s

medical details have been lost, and are no longer available.

• The nature, sensitivity, and volume of personal data

107. Of course, when assessing risk, a key factor is the type and sensitivity of personal data that has

been compromised by the breach. Usually, the more sensitive the data, the higher the risk of harm

will be to the people affected, but consideration should also be given to other personal data that may

already be available about the data subject. For example, the disclosure of the name and address of

an individual in ordinary circumstances is unlikely to cause substantial damage. However, if the name

and address of an adoptive parent is disclosed to a birth parent, the consequences could be very severe

for both the adoptive parent and child.

108. Breaches involving health data, identity documents, or financial data such as credit card

details, can all cause harm on their own, but if used together they could be used for identity theft. A

combination of personal data is typically more sensitive than a single piece of personal data.

109. Some types of personal data may seem at first relatively innocuous, however, what that data

may reveal about the affected individual should be carefully considered. A list of customers accepting

regular deliveries may not be particularly sensitive, but the same data about customers who have

requested that their deliveries be stopped while on holiday would be useful information to criminals.

110. Similarly, a small amount of highly sensitive personal data can have a high impact on an

individual, and a large range of details can reveal a greater range of information about that individual.

Also, a breach affecting large volumes of personal data about many data subjects can have an effect

on a corresponding large number of individuals.

• Ease of identification of individuals

111. An important factor to consider is how easy it will be for a party who has access to

compromised personal data to identify specific individuals, or match the data with other information

to identify individuals. Depending on the circumstances, identification could be possible directly from

the personal data breached with no special research needed to discover the individual’s identity, or it

may be extremely difficult to match personal data to a particular individual, but it could still be possible

under certain conditions. Identification may be directly or indirectly possible from the breached data,

but it may also depend on the specific context of the breach, and public availability of related personal

details. This may be more relevant for confidentiality and availability breaches.

Article 3.2 of Regulation 611/2013 provides guidance the factors that should be taken into consideration in

relation to the notification of breaches in the electronic communication services sector, which may be useful in

the context of notification under the GDPR. See http://eur-

lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2013:173:0002:0008:en:PDF

Adopted 25

112. As stated above, personal data protected by an appropriate level of encryption will be

unintelligible to unauthorised persons without the decryption key. Additionally, appropriately-

implemented pseudonymisation (defined in Article 4(5) GDPR as “the processing of personal data in

such a manner that the personal data can no longer be attributed to a specific data subject without the

use of additional information, provided that such additional information is kept separately and is

subject to technical and organisational measures to ensure that the personal data are not attributed

to an identified or identifiable natural person”) can also reduce the likelihood of individuals being

identified in the event of a breach. However, pseudonymisation techniques alone cannot be regarded

as making the data unintelligible.

• Severity of consequences for individuals

113. Depending on the nature of the personal data involved in a breach, for example, special

categories of data, the potential damage to individuals that could result can be especially severe, in

particular where the breach could result in identity theft or fraud, physical harm, psychological distress,

humiliation or damage to reputation. If the breach concerns personal data about vulnerable

individuals, they could be placed at greater risk of harm.

114. Whether the controller is aware that personal data is in the hands of people whose intentions

are unknown or possibly malicious can have a bearing on the level of potential risk. There may be a

confidentiality breach, whereby personal data is disclosed to a third party, as defined in Article 4(10),

or other recipient in error. This may occur, for example, where personal data is sent accidentally to the

wrong department of an organisation, or to a commonly used supplier organisation. The controller

may request the recipient to either return or securely destroy the data it has received. In both cases,

given that the controller has an ongoing relationship with them, and it may be aware of their

procedures, history and other relevant details, the recipient may be considered “trusted”. In other

words, the controller may have a level of assurance with the recipient so that it can reasonably expect

that party not to read or access the data sent in error, and to comply with its instructions to return it.

Even if the data has been accessed, the controller could still possibly trust the recipient not to take any

further action with it and to return the data to the controller promptly and to co-operate with its

recovery. In such cases, this may be factored into the risk assessment the controller carries out

following the breach – the fact that the recipient is trusted may eradicate the severity of the

consequences of the breach but does not mean that a breach has not occurred. However, this in turn

may remove the likelihood of risk to individuals, thus no longer requiring notification to the supervisory

authority, or to the affected individuals. Again, this will depend on case-by-case basis. Nevertheless,

the controller still has to keep information concerning the breach as part of the general duty to

maintain records of breaches (see section V, below).

115. Consideration should also be given to the permanence of the consequences for individuals,

where the impact may be viewed as greater if the effects are long-term.

• Special characteristics of the individual

116. A breach may affect personal data concerning children or other vulnerable individuals, who

may be placed at greater risk of danger as a result. There may be other factors about the individual

that may affect the level of impact of the breach on them.

• Special characteristics of the data controller

117. The nature and role of the controller and its activities may affect the level of risk to individuals

as a result of a breach. For example, a medical organisation will process special categories of personal

data, meaning that there is a greater threat to individuals if their personal data is breached, compared

with a mailing list of a newspaper.

• The number of affected individuals

Adopted 26

118. A breach may affect only one or a few individuals or several thousand, if not many more.

Generally, the higher the number of individuals affected, the greater the impact of a breach can have.

However, a breach can have a severe impact on even one individual, depending on the nature of the

personal data and the context in which it has been compromised. Again, the key is to consider the

likelihood and severity of the impact on those affected.

• General points

119. Therefore, when assessing the risk that is likely to result from a breach, the controller should

consider a combination of the severity of the potential impact on the rights and freedoms of individuals

and the likelihood of these occurring. Clearly, where the consequences of a breach are more severe,

the risk is higher and similarly where the likelihood of these occurring is greater, the risk is also

heightened. If in doubt, the controller should err on the side of caution and notify. Annex B provides

some useful examples of different types of breaches involving risk or high risk to individuals.

120. The European Union Agency for Network and Information Security (ENISA) has produced

recommendations for a methodology of assessing the severity of a breach, which controllers and

processors may find useful when designing their breach management response plan

V. ACCOUNTABILITY AND RECORD KEEPING

A. Documenting breaches

121. Regardless of whether or not a breach needs to be notified to the supervisory authority, the

controller must keep documentation of all breaches, as Article 33(5) GDPR explains:

“The controller shall document any personal data breaches, comprising the facts relating to the

personal data breach, its effects and the remedial action taken. That documentation shall enable the

supervisory authority to verify compliance with this Article.”

122. This is linked to the accountability principle of the GDPR, contained in Article 5(2) GDPR. The

purpose of recording non-notifiable breaches, as well notifiable breaches, also relates to the

controller’s obligations under Article 24 GDPR, and the supervisory authority can request to see these

records. Controllers are therefore encouraged to establish an internal register of breaches, regardless

of whether they are required to notify or not

123. Whilst it is up to the controller to determine what method and structure to use when

documenting a breach, in terms of recordable information there are key elements that should be

included in all cases. As is required by Article 33(5) GDPR, the controller needs to record details

concerning the breach, which should include its causes, what took place and the personal data

affected. It should also include the effects and consequences of the breach, along with the remedial

action taken by the controller.

124. The GDPR does not specify a retention period for such documentation. Where such records

contain personal data, it will be incumbent on the controller to determine the appropriate period of

retention in accordance with the principles in relation to the processing of personal data

and to meet

a lawful basis for processing

. It will need to retain documentation in accordance with Article 33(5)

ENISA, Recommendations for a methodology of the assessment of severity of personal data breaches,

https://www.enisa.europa.eu/publications/dbn-severity

The controller may choose to document breaches as part of if its record of processing activities which is

maintained pursuant to Article 30 GDPR. A separate register is not required, provided the information relevant

to the breach is clearly identifiable as such and can be extracted upon request.

See Article 5 GDPR.

See Article 6 and also Article 9 GDPR.

Adopted 27

GDPR insofar as it may be called to provide evidence of compliance with that Article, or with the

accountability principle more generally, to the supervisory authority. Clearly, if the records themselves

contain no personal data then the storage limitation principle

of the GDPR does not apply.

125. In addition to these details, the EDPB recommends that the controller also document its

reasoning for the decisions taken in response to a breach. In particular, if a breach is not notified, a

justification for that decision should be documented. This should include reasons why the controller

considers the breach is unlikely to result in a risk to the rights and freedoms of individuals

Alternatively, if the controller considers that any of the conditions in Article 34(3) GDPR are met, then

it should be able to provide appropriate evidence that this is the case.

126. Where the controller does notify a breach to the supervisory authority, but the notification is

delayed, the controller must be able to provide reasons for that delay; documentation relating to this

could help to demonstrate that the delay in reporting is justified and not excessive.

127. Where the controller communicates a breach to the affected individuals, it should be

transparent about the breach and communicate in an effective and timely manner. Accordingly, it

would help the controller to demonstrate accountability and compliance by retaining evidence of such

communication.

128. To aid compliance with Articles 33 and 34 GDPR, it would be advantageous to both controllers

and processors to have a documented notification procedure in place, setting out the process to follow

once a breach has been detected, including how to contain, manage and recover the incident, as well

as assessing risk, and notifying the breach. In this regard, to show compliance with GDPR it might also

be useful to demonstrate that employees have been informed about the existence of such procedures

and mechanisms and that they know how to react to breaches.

129. It should be noted that failure to properly document a breach can lead to the supervisory

authority exercising its powers under Article 58 GDPR and, or imposing an administrative fine in

accordance with Article 83 GDPR.

B. Role of the Data Protection Officer

130. A controller or processor may have a Data Protection Officer (DPO)

, either as required by

Article 37 GDPR, or voluntarily as a matter of good practice. Article 39 of the GDPR sets a number of

mandatory tasks for the DPO, but does not prevent further tasks being allocated by the controller, if

appropriate.

131. Of particular relevance to breach notification, the mandatory tasks of the DPO includes,

amongst other duties, providing data protection advice and information to the controller or processor,

monitoring compliance with the GDPR, and providing advice in relation to DPIAs. The DPO must also

cooperate with the supervisory authority and act as a contact point for the supervisory authority and

for data subjects. It should also be noted that, when notifying the breach to the supervisory authority,

Article 33(3)(b) GDPR requires the controller to provide the name and contact details of its DPO, or

other contact point.

132. In terms of documenting breaches, the controller or processor may wish to obtain the opinion

of its DPO as to the structure, the setting up and the administration of this documentation. The DPO

could also be additionally tasked with maintaining such records.

133. These factors mean that the DPO should play an key role in assisting the prevention of or

preparation for a breach by providing advice and monitoring compliance, as well as during a breach

See Article 5(1)(e) GDPR.

See Recital 85 GDPR.

See WP Guidelines on DPOs here: http://ec.europa.eu/newsroom/just/item-detail.cfm?item_id=50083

Adopted 28

(i.e. when notifying the supervisory authority), and during any subsequent investigation by the

supervisory authority. In this light, the EDPB recommends that the DPO is promptly informed about

the existence of a breach and is involved throughout the breach management and notification process.

VI. NOTIFICATION OBLIGATIONS UNDER OTHER LEGAL INSTRUMENTS

134. In addition to, and separate from, the notification and communication of breaches under the

GDPR, controllers should also be aware of any requirement to notify security incidents under other

associated legislation that may apply to them and whether this may also require them to notify the

supervisory authority of a personal data breach at the same time. Such requirements can vary between

Member States, but examples of notification requirements in other legal instruments, and how these

inter-relate with the GDPR, include the following:

• Regulation (EU) 910/2014 on electronic identification and trust services for electronic

transactions in the internal market (eIDAS Regulation)

135. Article 19(2) of the eIDAS Regulation requires trust service providers to notify their supervisory

body of a breach of security or loss of integrity that has a significant impact on the trust service

provided or on the personal data maintained therein. Where applicable—i.e., where such a breach or

loss is also a personal data breach under the GDPR—the trust service provider should also notify the

supervisory authority.

• Directive (EU) 2016/1148 concerning measures for a high common level of security of network

and information systems across the Union (NIS Directive)

136. Articles 14 and 16 of the NIS Directive require operators of essential services and digital service

providers to notify security incidents to their competent authority. As recognised by Recital 63 of NIS

security incidents can often include a compromise of personal data. Whilst NIS requires competent

authorities and supervisory authorities to co-operate and exchange information that context, it

remains the case that where such incidents are, or become, personal data breaches under the GDPR,

those operators and/or providers would be required to notify the supervisory authority separately

from the incident notification requirements of NIS.

Example

A cloud service provider notifying a breach under the NIS Directive may also need to notify a controller,

if this includes a personal data breach. Similarly, a trust service provider notifying under eIDAS may

also be required to notify the relevant data protection authority in the event of a breach.

• Directive 2009/136/EC (the Citizens’ Rights Directive) and Regulation 611/2013 (the Breach

Notification Regulation).

137. Providers of publicly available electronic communication services within the context of

Directive 2002/58/EC

must notify breaches to the competent national authorities.

See http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%3AOJ.L_.2014.257.01.0073.01.ENG

See http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.L_.2016.194.01.0001.01.ENG

Recital 63: “Personal data are in many cases compromised as a result of incidents. In this context, competent

authorities and data protection authorities should cooperate and exchange information on all relevant matters

to tackle any personal data breaches resulting from incidents.”

On 10 January 2017, the European Commission proposed a Regulation on Privacy and Electronic

Communications which will replace Directive 2009/136/EC and remove notification requirements. However,

until this proposal is approved by the European Parliament the existing notification requirement remains in

Adopted 29

138. Controllers should also be aware of any additional legal, medical, or professional notification

duties under other applicable regimes.

force, see https://ec.europa.eu/digital-single-market/en/news/proposal-regulation-privacy-and-

electroniccommunications

Adopted 30

VII. ANNEX

A. Flowchart showing notification requirements

Is the breach likely to

result in a high risk to

individuals’ rights and

freedoms?

Controll

er detects/is

made aware of a

security incident and establishes if

personal data beach has occurred

Is the

breach likely

to result in a risk to

individuals’ rights

and freedoms?

Yes

No requirement to notify supervisory authority

or individuals.

Notify competent supervisory authority.

If the breach affects individuals in more than

one Member State and the conntroller has an

establishment in the EEA,

notify the lead

supervisory authority.

If the breach affects individuals in more than

one Member state and the control

ler does not

have any establishments in the EEA, but is

subject to the GDPR by virtue of Article 3(2),

notify every supervisory authority for which

affected data subjects reside in their Member

state.

Yes

No requirement to notify

individuals.

Notify affected individuals and, where required, provide

information on steps they can take to prot

ect themselves from

consequences of the breach.

All breaches recordable under Article 33(5). Breach should be documented and

record maintained by the controller.

The controller becomes

“

aware

” of a

personal data breach and assesses risk

to individuals.

Adopted 31

B. Examples of personal data breaches and who to notify

The following non-exhaustive examples will assist controllers in determining whether they need to

notify in different personal data breach scenarios. These examples may also help to distinguish

between risk and high risk to the rights and freedoms of individuals.

Example

Notify the supervisory

authority

Notify the data

subject

Notes/recommendations

i A controller stored a

backup of an archive

of personal data

encrypted on a USB

key. The key is

stolen during a

break-in.

No.

As long as the data are

encrypted with a state of

the art algorithm, backups

of the data exist the unique

key is not compromised,

and the data can be

restored in good time, this

may not be a reportable

breach. However if it is later

compromised, notification

is required.

ii A controller

maintains an online

service. As a result

of a cyber attack on

that service,

personal data of

individuals are

exfiltrated.

The controller has

customers in a

single Member

State.

Yes, report to the

supervisory authority if

there are likely

consequences to

individuals.

Yes, report to individuals

depending on the nature

of the personal data

affected and if the

severity of the likely

consequences to

individuals is high.

iii A brief power

outage lasting

several minutes at a

controller’s call

centre meaning

customers are

unable to call the

controller and

access their records.

No.

This is not a notifiable

breach, but still a recordable

incident under Article 33(5).

Appropriate records should

be maintained by the

controller.

iv A controller suffers

a ransomware

attack which results

in all data being

encrypted. No back-

ups are available

and the data cannot

be restored. On

investigation, it

becomes clear that

the ransomware’s

only functionality

Yes, report to the

supervisory authority,

if there are likely

consequences to

individuals as this is a loss

of availability.

Yes, report to

individuals, depending

on the nature of the

personal data affected

and the possible effect

of the lack of availability

of the data, as well as

other likely

consequences.

If there was a backup

available and data could be

restored in good time, this

would not need to be

reported to the supervisory

authority or to individuals as

there would have been no

permanent loss of

availability or

confidentiality. However, if

the supervisory authority

became aware of the

Adopted 32

was to encrypt the

data, and that there

was no other

malware present in

the system.

incident by other means, it

may consider an

investigation to assess

compliance with the

broader security

requirements of Article 32.

v An individual

phones a bank’s call

centre to report a

data breach. The

individual has

received a monthly

statement for

someone else.

The controller

undertakes a short

investigation (i.e.

completed within

24 hours) and

establishes with a

reasonable

confidence that a

personal data

breach has occurred

and whether it has a

systemic flaw that

may mean other

individuals are or

might be affected.

Yes.

Only the individuals

affected are notified if

there is high risk and it is

clear that others were

not affected.

If, after further

investigation, it is identified

that more individuals are

affected, an update to the

supervisory authority must

be made and the controller

takes the additional step of

notifying other individuals if

there is high risk to them.

vi A controller

operates an online

marketplace and

has customers in

multiple Member

States. The

marketplace suffers

a cyber-attack and

usernames,

passwords and

purchase history are

published online by

the attacker.

Yes, report to lead

supervisory authority if

involves cross-border

processing.

Yes, as could lead to

high risk.

The controller should take

action, e.g. by forcing

password resets of the

affected accounts, as well as

other steps to mitigate the

risk.

The controller should also

consider any other

notification obligations, e.g.

under the NIS Directive as a

digital service provider.

vii A website hosting

company acting as a

data processor

identifies an error in

the code which

controls user

authorisation. The

effect of the flaw

means that any user

As the processor, the

website hosting company

must notify

its affected clients (the

controllers) without

undue delay.

Assuming that the

website hosting

If there is likely no high

risk to the individuals

they do not need to be

notified.

The website hosting

company (processor) must

consider any other

notification obligations (e.g.

under the NIS Directive as a

digital service provider).

If there is no evidence of

this vulnerability being

Adopted 33

can access the

account details of

any other user

company has conducted

its own investigation the

affected controllers

should be reasonably

confident as to whether

each has suffered a

breach and therefore is

likely to be considered as

having “become aware”

once they have been

notified by the hosting

company (the processor).

The controller then must

notify the supervisory

authority

exploited with any of its

controllers a notifiable

breach may not have

occurred but it is likely to be

recordable or be a matter of

non-compliance under

Article 32.

viii Medical records in a

hospital are

unavailable for the

period of 30 hours

due to a cyber-

attack.

Yes, the hospital is

obliged to notify as high-

risk to patient’s well-

being and privacy may

occur.

Yes, report to the

affected individuals.

Personal data of a

large number of

students are

mistakenly sent to

the wrong mailing

list with 1000+

recipients.

Yes, report to supervisory

authority.

Yes, report to individuals

depending on the scope

and type of personal

data involved and the

severity of possible

consequences.

x A direct marketing

e-mail is sent to

recipients in the

“to:” or “cc:” fields,

thereby enabling

each recipient to

see the email

address of other

recipients.

Yes, notifying the

supervisory authority

may be obligatory if a

large number of

individuals are affected,

if sensitive data are

revealed (e.g. a mailing

list of a psychotherapist)

or if other factors

present high risks (e.g.

the mail contains the

initial passwords).

Yes, report to individuals

depending on the scope

and type of personal

data involved and the

severity of possible

consequences.

Notification may not be

necessary if no sensitive

data is revealed and if only a

minor number of email

addresses are revealed.