GDPR Data Breach Notification
Comprehensive guide to GDPR data breach notification requirements under Articles 33 and 34, covering the 72-hour supervisory authority notification, communication to data subjects, breach documentation, and alignment with NIS2 incident reporting for organisations with dual obligations.
- 1
A personal data breach encompasses confidentiality, integrity, and availability incidents involving personal data — the definition is far broader than external cyberattacks alone.
- 2
The 72-hour supervisory authority notification clock starts at awareness, not at completion of investigation. Use phased notification under Article 33(4) when full details are unavailable.
- 3
Data subject communication is required only when the breach poses a high risk to rights and freedoms — but when in doubt, err toward transparency rather than reliance on exceptions.
- 4
All breaches must be documented in a breach register under Article 33(5), regardless of whether they meet the notification threshold.
- 5
Organisations subject to both GDPR and NIS2 must maintain parallel notification processes with distinct templates, timelines, and authority recipients.
1. What Constitutes a Personal Data Breach Under GDPR
Article 4(12) of the GDPR 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 deliberately broad. It encompasses not only the stereotypical external cyberattack resulting in data exfiltration, but also internal incidents such as an employee accidentally emailing personal data to the wrong recipient, a misconfigured cloud storage bucket exposing records to the public internet, or a ransomware event that renders personal data permanently inaccessible without backup recovery.
The European Data Protection Board (EDPB) categorises personal data breaches into three types: confidentiality breaches (unauthorised or accidental disclosure of, or access to, personal data), integrity breaches (unauthorised or accidental alteration of personal data), and availability breaches (accidental or unauthorised loss of access to, or destruction of, personal data). A single incident may involve one, two, or all three types simultaneously. A ransomware attack that encrypts a database and exfiltrates its contents before encryption is both a confidentiality breach and an availability breach. Classification matters because the type of breach influences the risk assessment that determines notification obligations.
Organisations frequently underestimate the scope of this definition. A lost unencrypted USB drive containing employee HR records is a personal data breach. A software bug that temporarily displays one customer's account data to another customer is a personal data breach. The accidental permanent deletion of personal data without a backup is a personal data breach. Establishing clear internal criteria for what constitutes a personal data breach — and training all employees to recognise and report potential incidents — is the essential first step in an effective notification programme.
Not every security incident is a personal data breach, and not every personal data breach triggers notification obligations. The key question is whether personal data was actually or likely compromised — and if so, whether the breach is likely to result in a risk to individuals' rights and freedoms.
2. The 72-Hour Notification to the Supervisory Authority (Article 33)
Article 33(1) requires the controller to notify the competent supervisory authority without undue delay and, where feasible, not later than 72 hours after having become aware of a personal data breach, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. The 72-hour clock starts when the controller has a reasonable degree of certainty that a security incident has resulted in personal data being compromised — not when the full scope of the breach has been determined. Waiting for a complete forensic investigation before starting the clock is not compliant.
The notification must contain, at minimum, the information specified in Article 33(3): 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; the name and contact details of the data protection officer or other contact point; the likely consequences of the breach; and the measures taken or proposed to address the breach and mitigate its possible adverse effects. Where all information cannot be provided within 72 hours, Article 33(4) permits phased notification — the initial notification within 72 hours, with supplementary information provided without undue delay as it becomes available.
The exception to notification — where the breach is 'unlikely to result in a risk to the rights and freedoms of natural persons' — requires a documented risk assessment. The EDPB's Guidelines 9/2022 provide a methodology: consider the type of breach, the nature and sensitivity of the personal data, the ease of identification of data subjects, the severity of consequences for data subjects, special characteristics of the data subjects (e.g., children), the number of affected data subjects, and special characteristics of the controller. Where encryption or pseudonymisation rendered the data unintelligible to any unauthorised party, the risk threshold may not be met. Document this assessment meticulously — a supervisory authority may later disagree with your risk conclusion, and a documented analysis demonstrates good faith even if the conclusion is challenged.
The 72-hour clock starts at 'awareness,' not at 'complete investigation.' If a processor reports a suspected breach to you on Friday evening, your 72 hours begin Friday evening — not Monday morning when your DPO reviews the report.
3. Communication to Data Subjects (Article 34)
Where a personal data breach is likely to result in a high risk to the rights and freedoms of natural persons, Article 34(1) requires the controller to communicate the breach to the affected data subjects without undue delay. Note the elevated threshold: notification to the supervisory authority is triggered by any risk to rights and freedoms, while communication to data subjects is triggered only by high risk. The distinction matters operationally — many breaches will require supervisory authority notification but not data subject communication.
The communication to data subjects must describe, in clear and plain language, the nature of the breach and include at least the information specified in Article 33(3)(b), (c), and (d): the DPO or contact point details, the likely consequences, and the measures taken or proposed. Unlike the supervisory authority notification, there is no prescribed form — but the communication must be direct and individual where feasible (email, letter, SMS), not buried in a general privacy policy update or press release. Where individual communication would involve disproportionate effort, Article 34(3)(c) permits a public communication or similar measure that informs data subjects equally effectively.
Article 34(3) provides three circumstances in which data subject communication is not required despite high risk: where the controller has applied appropriate technical and organisational protection measures to the affected data (encryption rendering data unintelligible), where subsequent measures ensure the high risk is no longer likely to materialise, or where individual notification would involve disproportionate effort (in which case public communication is required instead). Controllers should not over-rely on these exceptions — supervisory authorities scrutinise their application carefully. If in doubt, communicate. Proactive, transparent communication to data subjects typically generates less reputational damage and regulatory scrutiny than a delayed or withheld notification that surfaces later.
4. Breach Documentation and Record-Keeping
Article 33(5) imposes an independent documentation obligation that applies to all personal data breaches — not just those that meet the notification threshold. Controllers must document the facts relating to the personal data breach, its effects, and the remedial action taken. This breach register serves a dual purpose: it enables the supervisory authority to verify compliance with the notification obligations, and it provides the controller with institutional memory that improves breach response over time.
A well-structured breach register should record, for each incident: a unique reference identifier; the date and time the breach was discovered; the date and time the controller became 'aware' (these may differ); the nature of the breach (confidentiality, integrity, availability, or combination); the categories and approximate number of data subjects affected; the categories and approximate number of personal data records affected; the likely consequences assessed; the measures taken to contain and remediate the breach; the notification decision (supervisory authority notified: yes/no, with reasoned justification if no); the date and time of supervisory authority notification (if applicable); the data subject communication decision (communicated: yes/no, with reasoned justification if no); and a post-incident review summary identifying root cause and systemic improvements.
Retain breach records for at least the GDPR limitation period in your jurisdiction — typically five to six years from the date of the breach, though this varies by Member State. Structure the register so that it can be produced to a supervisory authority on request, which means it should be maintained by the DPO or privacy team in a format that is presentable without extensive redaction or reformatting. Periodic review of the breach register — at least annually — can reveal patterns (recurring breach types, systemic control weaknesses, departments with elevated incident rates) that inform the broader data protection programme.
The breach register is an accountability tool under Article 5(2). Even breaches that do not require supervisory authority notification must be documented. A complete, well-maintained register demonstrates mature data protection governance during audits and inspections.
5. Processor Notification and Controller-Processor Dynamics
Article 33(2) requires processors to notify the controller without undue delay after becoming aware of a personal data breach. The GDPR does not specify a precise timeline for processor-to-controller notification (unlike the 72-hour controller-to-supervisory authority deadline), but 'without undue delay' is interpreted strictly. In practice, the controller's 72-hour clock begins when the processor becomes aware of the breach, because the controller is deemed to have constructive awareness through its processor. This means delayed processor notification directly compresses the controller's response window.
Data processing agreements under Article 28 should specify processor breach notification obligations with precision: a concrete maximum notification window (24 hours is common practice and recommended by several supervisory authorities), the required content of the processor's notification (sufficient detail for the controller to assess whether the supervisory authority threshold is met), the communication channel (a dedicated security contact, not a general support email), and the processor's obligation to cooperate with the controller's investigation, including preserving forensic evidence and providing ongoing updates.
Controllers using multiple processors or sub-processor chains face compounded notification risk. A breach at a sub-processor must cascade through the processor to the controller within the agreed timelines. Map your processing chain, identify critical processors whose breach would affect large volumes of personal data, and ensure contractual notification obligations are binding through the entire chain. Conduct periodic exercises with key processors to test breach notification workflows — a contractual obligation that has never been operationally tested is a paper control, not an effective one.
6. Interaction with NIS2 Incident Reporting for Dual Obligations
Organisations subject to both GDPR and NIS2 face overlapping but distinct incident reporting obligations that require careful coordination. A ransomware attack that exfiltrates personal data and disrupts critical services triggers both GDPR breach notification (Article 33, 72 hours to the data protection supervisory authority) and NIS2 incident reporting (Article 23, 24-hour early warning and 72-hour incident notification to the competent authority or CSIRT). The timelines, recipients, content requirements, and legal thresholds differ — a single incident may require two separate notifications to two separate authorities within different timeframes.
The NIS2 Directive explicitly acknowledges this overlap. Article 35(1) provides that where the competent authority or CSIRT becomes aware, during incident handling, that the incident involves a personal data breach, it shall inform the relevant supervisory authority under GDPR without undue delay. Conversely, where the data protection supervisory authority determines that a notified breach also constitutes an incident under NIS2, it should inform the NIS2 competent authority. This cross-authority communication mechanism does not relieve the entity of its own dual notification obligations — you must notify both authorities independently and within their respective timelines.
Design your incident response process to handle dual reporting from the outset. Maintain parallel notification templates for GDPR (supervisory authority format) and NIS2 (ENISA/CSIRT format). Assign clear ownership for each notification stream — the DPO or privacy lead for GDPR notifications, the CISO or security lead for NIS2 notifications — while ensuring a single incident coordinator maintains overall coherence. Conduct tabletop exercises that simulate dual-reporting scenarios, testing whether your team can produce both notifications within their respective deadlines without the GDPR notification inadvertently disclosing NIS2-sensitive information about infrastructure vulnerabilities, or the NIS2 notification omitting personal data breach details that the data protection authority requires.
GDPR and NIS2 notifications go to different authorities with different content requirements. Do not submit a single notification to both — each authority expects information tailored to its statutory mandate. A GDPR notification focuses on personal data impact; a NIS2 notification focuses on service disruption and operational impact.
7. Building an Effective Breach Response Programme
An effective breach response programme is not built during a breach — it is designed, documented, tested, and refined before one occurs. The programme should define roles and responsibilities (who declares a breach, who leads the investigation, who drafts notifications, who approves external communications), escalation pathways (from initial detection through to board-level reporting), decision trees for notification assessment (structured criteria rather than ad hoc judgment), and communication templates for supervisory authorities, data subjects, media, and internal stakeholders.
Regular testing through tabletop exercises and simulated breach scenarios is essential. The EDPB's Guidelines on personal data breach notification emphasise that controllers should have procedures in place to detect, investigate, and internally report breaches. Test these procedures at least twice annually, varying the scenario type (external cyberattack, insider threat, accidental disclosure, processor breach) and the personnel involved. Post-exercise reviews should identify process gaps, timeline bottlenecks, and decision-making ambiguities that can be resolved before a real incident exposes them under pressure.
Invest in the tooling and automation that compresses response timelines. Automated breach detection from security monitoring platforms, pre-populated notification templates that pull incident data from your case management system, and workflow automation that tracks the 72-hour deadline and escalates when milestones are at risk all reduce the operational burden during a real breach. The organisations that handle breach notification smoothly are not the ones with the largest security teams — they are the ones that have practised, documented their process, and reduced manual steps through thoughtful automation.
What is the penalty for failing to notify a data breach within 72 hours?
Failure to comply with GDPR breach notification obligations under Articles 33 and 34 can result in administrative fines of up to EUR 10 million or 2% of the undertaking's total worldwide annual turnover, whichever is higher (Article 83(4)(a)). In practice, supervisory authorities have imposed significant fines for delayed notification, inadequate notification content, and failure to document breaches. The severity of the fine depends on factors including the duration of the delay, the nature and volume of personal data affected, whether the controller took steps to mitigate damage, and the controller's degree of cooperation with the supervisory authority.
Does the 72-hour deadline apply on weekends and public holidays?
Yes. The 72-hour deadline under Article 33(1) runs continuously from the moment of awareness and does not pause for weekends, public holidays, or out-of-hours periods. If your organisation becomes aware of a breach at 17:00 on Friday, the notification deadline is 17:00 on Monday. This is why breach response programmes must include on-call arrangements and out-of-hours escalation procedures — breaches do not observe business hours, and neither does the notification deadline.
Who is responsible for notifying the supervisory authority — the controller or the processor?
The controller bears the obligation to notify the supervisory authority under Article 33. The processor's obligation is to notify the controller without undue delay after becoming aware of a breach (Article 33(2)). In joint controller arrangements under Article 26, the joint controllers should determine which controller will handle supervisory authority notification and document this in their joint controller arrangement. Regardless of internal allocation, both controllers remain jointly liable. Where a processor processes data for multiple controllers, the processor must notify each affected controller individually.
What happens if a breach affects data subjects in multiple EU Member States?
Under the GDPR's one-stop-shop mechanism (Articles 56 and 60), a controller with establishments in multiple Member States notifies its lead supervisory authority, which then coordinates with other concerned supervisory authorities. For controllers with a single EU establishment, notification goes to the supervisory authority of that Member State. For controllers not established in the EU but subject to GDPR under Article 3(2), notification must be made to the supervisory authority in each Member State where affected data subjects reside. The EDPB's cooperation mechanisms facilitate cross-border coordination, but the initial notification responsibility falls on the controller.
Can we delay notification to coordinate with law enforcement?
The GDPR does not provide an explicit carve-out for law enforcement coordination in the way that some national data breach laws do. However, Recital 88 notes that notification may be delayed where necessary and proportionate for the purposes of prevention, investigation, detection, or prosecution of criminal offences. In practice, if law enforcement requests a delay in public disclosure, discuss with your supervisory authority — some DPAs will accept a brief delay in data subject communication (Article 34) where law enforcement provides a written request, but the 72-hour supervisory authority notification under Article 33 should still proceed, with a note that law enforcement has been engaged.
Ready to Operationalise This?
Turn this guide into working compliance workflows. Create an account or schedule a personalised demo.