Adopted on 14 December 2021 – Version 2.0

Version history

1. INTRODUCTION

1. The GDPR introduces, in certain cases, the requirement for a personal data breach to be notified to the competent national supervisory authority (hereinafter “SA”) and to communicate the breach to the individuals whose personal data have been affected by the breach (Articles 33 and 34).
2. The Article 29 Working Party already produced a general guidance on data breach notification in October 2017, analysing the relevant Sections of the GDPR (Guidelines on Personal data breach notification under Regulation 2016/679, WP 250) (hereinafter “Guidelines WP250”). However, due to its nature and timing, this guideline did not address all practical issues in sufficient detail. Therefore, the need has arisen for a practice-oriented, case-based guidance, that utilizes the experiences gained by SAs since the GDPR is applicable.
3. This document is intended to complement the Guidelines WP 250 and it reflects the common experiences of the SAs of the EEA since the GDPR became applicable. Its aim is to help data controllers in deciding how to handle data breaches and what factors to consider during risk assessment.
4. As part of any attempt to address a breach the controller and processor should first be able to recognize 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”.
5. In its Opinion 03/2014 on breach notification and in its Guidelines WP 250, 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; and
• “Availability breach” – where there is an accidental or unauthorised loss of access to, or destruction of, personal data.

1. 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. One of the most important obligation of the data controller is to evaluate these risks to the rights and freedoms of data subjects and to implement appropriate technical and organizational measures to address them.
2. Accordingly, the GDPR requires the controller to:

• document any personal data breaches, comprising the facts relating to the personal data breach, its effects and the remedial action taken;
• notify the personal data breach to the supervisory authority, unless the data breach is unlikely to result in a risk to the rights and freedoms of natural persons;
• communicate the personal data breach to the data subject when the personal data breach is likely to result in a high risk to the rights and freedoms of natural persons.

1. Data breaches are problems in and of themselves, but they may be also symptoms of a vulnerable, possibly outdated data security regime, they may also indicate system weaknesses to be addressed. As a general truth, it is always better to prevent data breaches by preparing in advance, since several consequences of them are by nature irreversible. Before a controller can fully assess the risk arising from a breach caused by some form of attack, the root cause of the issue should be identified, in order to identify whether any vulnerabilities that gave rise to the incident are still present, and are still therefore exploitable. In many cases the controller is able to identify that the incident is likely to result in a risk, and is therefore to be notified. In other cases the notification does not need to be postponed until the risk and impact surrounding the breach has been fully assessed, since the full risk assessment can happen in parallel to notification, and the information thus gained may be provided to the SA in phases without undue further delay.
2. The breach should be notified when the controller is of the opinion that it is likely to result in a risk to the rights and freedoms of the data subject. Controllers should make this assessment at the time they become aware of the breach. The controller should not wait for a detailed forensic examination and (early) mitigation steps before assessing whether or not the data breach is likely to result in a risk and thus should be notified.
3. If a controller self-assesses the risk to be unlikely, but it turns out that the risk materializes, the competent SA can use its corrective powers and may resolve to sanctions
4. Every controller and processor should have plans, procedures in place for handling eventual data breaches. Organisations should have clear reporting lines and persons responsible for certain aspects of the recovery process.
5. Training and awareness on data protection issues for the staff of the controller and processor focusing on personal data breach management (identification of a personal data breach incident and further actions to be taken, etc.) is also essential for the controllers and processors. This training should be regularly repeated, depending on the type of the processing activity and size of the controller, addressing latest trends and alerts coming from cyberattacks or other security incidents.
6. The principle of accountability and the concept of data protection by design could incorporate analysis that feeds into a data controller’s and data processor’s own “Handbook on Handling Personal Data Breach” that aims to establish facts for each facet of the processing at each major stage of the operation. Such a handbook prepared in advance would provide a much quicker source of information to allow data controllers and data processors to mitigate the risks and meet the obligations without undue delay. This would ensure that if a personal data breach was to occur, people in the organisation would know what to do, and the incident would more than likely be handled quicker than if there were no mitigations or plan in place.
7. Though the cases presented below are fictitious, they are based on typical cases from the SA’s collective experience with data breach notifications. The analyses offered relate explicitly to the cases under scrutiny, but with the goal to provide assistance for data controllers in assessing their own data breaches. Any modification in the circumstances of the cases described below may result in different or more significant levels of risk, thus requiring different or additional measures. These guidelines structure the cases according to certain categories of breaches (e.g. ransomware attacks). Certain mitigating measures are called for in each case when dealing with a certain category of breaches. These measures are not necessarily repeated in each case analysis belonging to the same category of breaches. For the cases belonging to the same category only the differences are laid out. Therefore, the reader should read all cases relevant to relevant category of a breach to identify and distinguish all the correct measures to be taken.
8. The internal documentation of a breach is an obligation independent of the risks pertaining to the breach, and must be performed in each and every case. The cases presented below try to shed some light on whether or not to notify the breach to the SA and communicate it to the data subjects affected.

Go to the full Guidelines.