GDPR Data Breach Notification Requirements

Article 4(12) defines a personal data breach 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. This definition is broader than many organisations assume — it encompasses not only deliberate cyberattacks and data theft but also accidental incidents such as employee errors, system misconfigurations, lost devices, and misdirected communications.

The EDPB categorises personal data breaches into three types based on the information security triad. A confidentiality breach occurs where there is unauthorised or accidental disclosure of, or access to, personal data — for example, sending personal data to the wrong recipient, a hacking incident that exfiltrates data, or an employee accessing records without authorisation. An integrity breach occurs where there is unauthorised or accidental alteration of personal data — for example, modification of medical records, corruption of a database, or ransomware that encrypts data without exfiltration. An availability breach occurs where there is accidental or unauthorised loss of access to, or destruction of, personal data — for example, a ransomware attack that makes data inaccessible, accidental deletion without backup, or a hardware failure that destroys data permanently.

A single incident may involve multiple breach types simultaneously — a ransomware attack, for instance, may constitute an availability breach (data encrypted and inaccessible), a confidentiality breach (data exfiltrated), and potentially an integrity breach (data modified). Each aspect must be assessed independently when evaluating risk to data subjects and determining notification obligations.

Article 33 establishes the obligation to notify the competent supervisory authority of a personal data breach. The controller must notify without undue delay and, where feasible, not later than 72 hours after having become aware of the breach. Where notification is not made within 72 hours, the notification must be accompanied by reasons for the delay.

The 'becoming aware' threshold is critical. The EDPB has clarified that a controller should be considered as having become aware when it has a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised. For incidents reported by a processor, Article 33(2) requires the processor to notify the controller without undue delay after becoming aware of a personal data breach — triggering the controller's 72-hour clock upon receipt of that notification. Organisations should ensure that processor contracts include clear breach notification timelines, typically requiring processor notification within 24-48 hours to give the controller adequate time to assess and report within the 72-hour window.

The notification to the supervisory authority must include, at minimum: a description of the nature of the breach including, where possible, the categories and approximate number of data subjects concerned and the categories and approximate number of personal data records concerned (Article 33(3)(a)); the name and contact details of the DPO or other contact point (Article 33(3)(b)); a description of the likely consequences of the breach (Article 33(3)(c)); and a description of the measures taken or proposed to address the breach, including measures to mitigate its possible adverse effects (Article 33(3)(d)).

Where it is not possible to provide the information at the same time, the information may be provided in phases without undue further delay (Article 33(4)). This phased approach recognises that full details may not be available within 72 hours, particularly for complex breaches. The initial notification should contain whatever information is available, with supplementary notifications providing additional details as the investigation progresses.

Notification is not required where the breach is unlikely to result in a risk to the rights and freedoms of natural persons (Article 33(1)). This risk assessment must be documented as part of the breach record. However, the EDPB advises that controllers should err on the side of notification where they are uncertain about the level of risk.

Article 34 imposes a separate obligation to communicate the breach to affected data subjects when the breach is likely to result in a high risk to the rights and freedoms of natural persons. The threshold for data subject notification ('high risk') is higher than for DPA notification ('risk') — not every breach that requires DPA notification will require data subject communication.

The communication to data subjects must describe in clear and plain language the nature of the breach and contain at least: the name and contact details of the DPO or other contact point (Article 34(2) referencing Article 33(3)(b)); a description of the likely consequences of the breach (Article 34(2) referencing Article 33(3)(c)); and a description of the measures taken or proposed to address the breach, including measures to mitigate adverse effects (Article 34(2) referencing Article 33(3)(d)). Unlike DPA notifications, data subject communications should be accessible and understandable to a non-specialist audience.

Article 34(3) provides three exceptions where communication to data subjects is not required despite a high-risk breach. First, where the controller has implemented appropriate technical and organisational protection measures that render the personal data unintelligible to any person not authorised to access it — such as encryption where the encryption key has not been compromised (Article 34(3)(a)). Second, where the controller has taken subsequent measures which ensure that the high risk to rights and freedoms is no longer likely to materialise (Article 34(3)(b)). Third, where individual communication would involve disproportionate effort — in which case the controller must instead make a public communication or similar measure ensuring that data subjects are informed equally effectively (Article 34(3)(c)).

The supervisory authority may also require the controller to communicate a breach to data subjects where it considers that the breach is likely to result in a high risk, or may decide that one of the exceptions in Article 34(3) applies (Article 34(4)).

Article 33(5) 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. This documentation obligation applies to all breaches — including those that are assessed as unlikely to result in risk and therefore do not trigger notification to the supervisory authority or data subjects.

The breach register serves multiple compliance functions. It provides evidence of compliance with the accountability principle under Article 5(2) — demonstrating that the controller has a systematic process for identifying, assessing, and responding to breaches. It enables the supervisory authority to verify compliance during inspections or audits. It provides a historical record that can inform risk assessments and security improvements. And it supports the controller's decision-making on notification obligations by documenting the risk assessment methodology and conclusions for each breach.

Best practice for breach documentation includes: a unique breach identifier and date/time of discovery; description of the breach including type (confidentiality, integrity, availability); how and when the breach was detected; categories and approximate number of data subjects affected; categories and approximate number of data records affected; assessment of likely consequences and severity for data subjects; risk assessment methodology and conclusion; measures taken to contain and remediate the breach; notification decisions (DPA notification: yes/no with reasons; data subject communication: yes/no with reasons); timeline of all actions taken including DPA and data subject notifications; and lessons learned and preventive measures implemented.

The breach register must be available for inspection by the supervisory authority at any time. Many DPAs provide standardised templates for breach documentation, and organisations should ensure their internal documentation meets or exceeds these templates.

For organisations processing personal data across multiple EU member states, the GDPR's one-stop-shop mechanism (Articles 55-56) determines which supervisory authority has jurisdiction over breach handling. The lead supervisory authority — generally the DPA in the member state where the controller or processor has its main establishment — serves as the primary point of contact for cross-border processing matters.

Article 56(1) establishes that the lead supervisory authority is competent to act as lead authority for cross-border processing in accordance with the cooperation procedure under Article 60. This means that a breach affecting data subjects in multiple member states should be notified to the lead supervisory authority, which then coordinates with concerned DPAs through the cooperation mechanism.

However, the one-stop-shop principle has important limitations. Under Article 56(2), each supervisory authority remains competent to handle a complaint lodged with it or a possible infringement of the GDPR if the subject matter relates only to an establishment in its member state or substantially affects data subjects in only its member state. The EDPB's consistency mechanism (Articles 63-67) provides for dispute resolution where concerned DPAs disagree with the lead authority's approach.

In practice, cross-border breach notification requires careful coordination. The controller must identify its lead supervisory authority in advance and establish notification procedures. Where urgency requires, Article 56(3)-(5) allows any DPA to adopt provisional measures on its territory and to refer the matter to the EDPB's urgency procedure under Article 66. Organisations with multi-state operations should establish internal escalation procedures that account for both lead authority notification and local DPA engagement requirements.

The practical reality is that many national DPAs also request to be informed of breaches affecting their residents, even where the lead authority is in another member state. Controllers should monitor national guidance and, where feasible, provide courtesy notifications to concerned DPAs in parallel with the formal lead authority notification.