GDPR Data Breach Notification: 72-Hour Rule Explained (2026)

Under Article 33 of the GDPR, data controllers must notify their supervisory authority within 72 hours of becoming aware of a personal data breach, provided the breach is likely to result in risk to individuals. The clock starts when the controller has reasonable certainty a breach occurred, not when the investigation concludes.

When a personal data breach occurs, the clock starts immediately. Under the GDPR, data controllers have just 72 hours to notify their supervisory authority after becoming aware of a qualifying breach. Missing that window is a standalone violation that can trigger significant fines, and the cases against Meta, Bank of Ireland, and Permanent TSB show that DPAs pursue it.

Articles 33 and 34 of Regulation (EU) 2016/679 set out the breach notification framework. The EDPB Guidelines 9/2022 on personal data breach notification (version 2.0, adopted April 2023) and the accompanying EDPB Guidelines 01/2021 on breach examples provide the authoritative interpretation used by every EU and EEA supervisory authority.

This guide explains what counts as a breach, when each notification duty is triggered, exactly what to include, what "becoming aware" means, the processor's role, the breach register obligation, common pitfalls, enforcement, and how the GDPR's rules compare to other major frameworks.

For the broader regulatory context, see What Is GDPR. For compliance planning, see the GDPR compliance checklist. For penalty ranges, see GDPR fines and penalties.

This article is for informational purposes only and does not constitute legal advice. Consult a qualified data protection attorney or privacy professional for guidance specific to your situation.

Quick Answer

The 72-hour rule is shorthand for Article 33(1) of the GDPR. When a personal data breach occurs, the controller must notify the competent supervisory authority within 72 hours of becoming aware of it, unless the breach is unlikely to result in any risk to individuals' rights and freedoms.

If the notification cannot be made within 72 hours, it must still be submitted as soon as possible and accompanied by a reasoned justification for the delay.

A separate duty under Article 34 may require the controller to also notify affected individuals directly, but only when the breach is likely to result in a high risk, which is a higher threshold.

What Counts as a Personal Data Breach

Article 4(12) 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."

The European Commission and the EDPB SME guide on data breaches organise this around three types of security incident: the confidentiality/integrity/availability triad.

Confidentiality Breach

Unauthorised or accidental disclosure of, or access to, personal data. Examples:

• A cyberattack gains access to a customer database
• An employee emails personal data to the wrong recipient
• A stolen or lost laptop contains unencrypted personal data
• A processor's systems are compromised, exposing data shared with them under an Article 28 agreement
• A cloud storage bucket is misconfigured and becomes publicly accessible

Integrity Breach

Unauthorised or accidental alteration of personal data. Examples:

• A cyberattack modifies medical records
• A software bug corrupts payroll data
• An unauthorised user edits customer account details without authorisation

Availability Breach

Accidental or unauthorised loss of access to, or destruction of, personal data. Examples:

• A ransomware attack encrypts a database and no backup is available
• A server failure permanently destroys records with no recovery option
• An employee accidentally deletes a dataset with no backup in place

Ransomware attacks are particularly significant because they can trigger all three breach types simultaneously: encrypted data is an availability breach; if data was also exfiltrated before encryption, it is a confidentiality breach; and integrity cannot be guaranteed if the attacker had write access.

The ICO guidance on personal data breaches emphasises that a breach does not require malicious intent. Accidental loss, human error, and system failures all qualify if personal data is affected.

A note on ransomware and backups: an availability breach from ransomware may not require notification if the organisation has verified, clean backups and can restore the data promptly with no lasting effect on individuals. However, this assessment must be documented and the organisation must be certain no data was exfiltrated. When in doubt, notify.

The 72-Hour Rule: Notification to the Supervisory Authority (Article 33)

The Core Obligation

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 it", unless the breach "is unlikely to result in a risk to the rights and freedoms of natural persons."

Two elements make up the obligation:

First, speed. The notification must happen "without undue delay" and within 72 hours where feasible. These are distinct requirements: the 72-hour ceiling does not mean you can wait 71 hours if the information is ready sooner.

Second, threshold. Only breaches likely to result in at least some risk to individuals trigger the duty. Breaches that are genuinely unlikely to affect anyone need not be notified to the authority, but must still be documented internally.

What the Notification Must Include

Article 33(3) specifies four categories of required information:

• Nature of the breach: Categories and approximate number of data subjects affected; categories and approximate number of personal data records concerned; how the breach occurred
• Contact point: Name and contact details of the DPO or another point of contact
• Likely consequences: A description of the probable consequences of the breach for the individuals affected
• Measures taken: Steps taken or proposed to address the breach, including measures to mitigate possible adverse effects

Phased Notification

Article 33(4) explicitly permits phased notification. If the full picture is not available within 72 hours, submit an initial notification with whatever information is available within that window. Supplementary details should follow "without undue further delay" as the investigation progresses.

This is the mechanism regulators expect controllers to use in complex incidents. Submitting an initial notification that says "investigation ongoing" is far better than waiting for the full picture and missing the 72-hour deadline.

How to Notify

The EDPB maintains a directory of breach notification portals for each national supervisory authority. Most DPAs accept notifications through online forms.

Under the one-stop-shop mechanism, controllers with an EU main establishment notify the lead supervisory authority (the DPA of the member state where the controller's main establishment is located). If the breach primarily affects individuals in a specific member state, those authorities may be notified as well.

The "No Risk" Exception

Notification is not required if the breach "is unlikely to result in a risk to the rights and freedoms of natural persons." The EDPB Guidelines 9/2022 note this is a narrow carve-out. Most breaches involving personal data do carry at least some risk. When the assessment is close, the EDPB recommends erring toward notification.

Factors that reduce risk and may support a no-notification decision include:

• The data was fully encrypted and the encryption key was not compromised
• The data was already publicly available and exposure caused no incremental harm
• The breach was contained immediately with no outside access confirmed
• The categories of data involved are non-sensitive and the breach was brief

Even when you decide not to notify the supervisory authority, the breach must still be recorded in the breach register.

When the Clock Starts: "Becoming Aware"

The 72-hour clock runs from the moment the controller "becomes aware" of the breach: not from when the breach began, not from when the investigation is complete, and not from when the full scope is known.

The EDPB Guidelines 9/2022 define awareness as the point when "the controller has a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised."

Practical Scenarios

When your intrusion detection system, log monitoring, or SIEM alerts on a breach, awareness begins when a responsible person reviews and acknowledges that alert as indicating a likely breach. Simply receiving an automated alert that no one acts on does not necessarily constitute awareness, but organisations are expected to have reasonable response procedures so that alerts are reviewed promptly.

When a processor discovers a breach first and notifies the controller, the controller becomes aware when it receives the processor's notification. The clock does not run from the moment the processor discovered the incident, but only if the processor notified promptly.

When an external party (a security researcher, a customer, a journalist) credibly reports a breach, the controller becomes aware when it receives information that gives it a reasonable degree of certainty that a breach has occurred.

An ongoing investigation to determine the full scope of a breach does not suspend the clock. The controller must notify based on information available at the 72-hour mark and supplement with further information as the investigation proceeds.

Common Awareness Mistakes

Controllers sometimes treat the start of an investigation as the start of the clock. This is wrong. A phishing email that is opened, credentials that are compromised, or an access log showing unusual activity can all constitute sufficient certainty that a breach has occurred even before the investigation is complete.

DPAs have fined organisations specifically for concluding investigations before filing breach notifications, thereby exceeding the 72-hour window. France's CNIL, in particular, has cited inadequate risk assessments and delayed notification starts as recurring violations.

Notification to Data Subjects (Article 34)

The High-Risk Threshold

Article 34(1) requires controllers to communicate a breach to affected data subjects "without undue delay" when the breach "is likely to result in a high risk to the rights and freedoms of natural persons."

The high-risk threshold is meaningfully higher than the "risk" threshold for supervisory authority notification. Not every breach that must be reported to the DPA also requires individual notification.

The EDPB guidelines direct controllers to assess high risk by weighing:

• Sensitivity of the data: Health data, financial data, biometric data, ID numbers, and data on children carry heightened risk
• Volume: More affected individuals generally increases risk
• Ease of identification: Data that can easily be linked back to specific individuals poses greater risk
• Likely consequences: Identity theft, financial loss, discrimination, reputational damage, and physical safety risks all support a high-risk finding
• Special characteristics of affected individuals: Vulnerable groups (minors, patients, people in domestic violence situations) face greater potential harm

What the Communication Must Include

The communication to data subjects must convey:

• A clear, plain-language description of the nature of the breach
• The name and contact details of the DPO or another contact point
• A description of the likely consequences for the individual
• The measures taken or proposed to address the breach and mitigate its effects

The communication must be direct, sent to each affected individual, unless individual notification would involve disproportionate effort, in which case a public communication or an equally effective alternative measure is required.

Three Exceptions to Data Subject Notification

Article 34(3) provides three situations where individual notification is not required even when high risk exists:

First, encryption or equivalent protection. The controller applied appropriate technical measures (such as encryption) that render the personal data unintelligible to any unauthorised person, and those measures were applied to the data involved in the breach. For this exception to work, the encryption must have been robust and the key must not have been compromised.

Second, subsequent mitigation. The controller took subsequent measures ensuring the high risk to individuals is no longer likely to materialise. For example: credentials were compromised but the controller immediately revoked them before any unauthorised use occurred, and there is no evidence of data exfiltration.

Third, disproportionate effort. Where identifying and directly contacting every affected individual would require disproportionate effort, the controller must instead make a public communication that informs individuals equally effectively, typically a press statement, website notice, or social media announcement.

The Processor's Duty (Article 33(2))

Data processors have their own breach notification obligation under Article 33(2). After becoming aware of a personal data breach, the processor must notify the controller "without undue delay."

The GDPR does not set a fixed hour limit for processor-to-controller notification. However, the EDPB Guidelines 9/2022 recommend that processors aim to notify controllers within 72 hours of becoming aware of the breach themselves, because the controller's 72-hour window to the supervisory authority effectively depends on receiving timely processor notification.

What This Means for Contracts

Article 28 data processing agreements should specify:

• A maximum notification window from processor to controller (24 hours is common practice; 72 hours is the practical maximum)
• The minimum information the processor must include in the notification (nature of the breach, affected data categories, approximate number of individuals, likely consequences, initial containment steps)
• An obligation for the processor to assist the controller in preparing the supervisory authority notification and any data subject communication
• The processor's obligation to cooperate with the supervisory authority investigation
• Escalation contacts and out-of-hours procedures

A processor that fails to notify the controller in time, causing the controller to miss the 72-hour window, may itself face regulatory scrutiny. The EDPB One-Stop-Shop Case Digest on Security of Processing and Data Breach Notification (2024) documents how DPAs have handled processor chain failures in cross-border cases.

The Breach Register (Article 33(5))

Article 33(5) requires controllers to document all personal data breaches, regardless of whether notification to the supervisory authority was required. This internal breach register must include:

• The facts of the breach (what happened, how it was discovered, when it occurred and when it was detected)
• The effects of the breach on affected individuals
• The remedial actions taken and proposed
• The controller's risk assessment: the analysis of likelihood and severity of risk to individuals
• The reasoning for notifying or not notifying the supervisory authority
• Where applicable, the reasoning for not notifying data subjects
• Details of any notifications made (date, content, recipient authority)

The breach register must be available to the supervisory authority on request. It is the primary documentary evidence that the controller managed the breach in compliance with GDPR. In investigations and audits, the absence of a proper register is itself treated as a violation.

The register should be maintained securely and reviewed periodically. Organisations handling significant volumes of personal data should treat the breach register as a living document, not a one-off filing.

Common Mistakes

Waiting for the investigation to finish before notifying. This is the most frequently cited error. The clock starts at awareness, not at the end of the investigation. Phased notification is the intended mechanism. File the initial notification with available information within 72 hours, then supplement.

Treating the processor's discovery as your starting point. If your processor discovered the breach days before notifying you, your 72-hour clock does not start at the processor's discovery date. But if the processor's delayed notification caused you to miss the window, both you and the processor may face regulatory scrutiny.

Assuming a small breach needs no documentation. Every breach, however minor, requires a breach register entry. Only the notification threshold differs. Skipping the register for low-risk incidents is a compliance gap that surfaces in audits.

Vague risk assessments. Supervisory authorities, particularly France's CNIL, have cited inadequate risk assessments as a standalone violation. Stating "we assessed risk as low" without reasoning, data volumes, affected categories, and severity analysis is insufficient. The register entry must show your work.

Failing to notify data subjects when high risk is present. Where a breach involves sensitive data and there is a realistic threat of identity theft, financial harm, or discrimination, controllers sometimes wrongly assume the encryption exception applies or that the risk has been mitigated. When in doubt, notify individuals.

Inadequate content in the supervisory authority notification. Article 33(3) specifies required content. Meta's EUR 251 million DPC decision in December 2024 included a specific finding that its breach notification did not contain all required information under Article 33(3), and a separate finding under Article 33(5) for inadequate breach register documentation. Incomplete notifications are treated as a violation separate from late notification.

Enforcement Examples

Meta: EUR 251 Million (Irish DPC, December 2024)

The Irish DPC fined Meta EUR 251 million following a 2018 breach in which attackers exploited vulnerabilities in Facebook's "View As" feature to steal access tokens for approximately 29 million accounts globally (around 3 million in the EU/EEA). The fine comprised multiple infringements: EUR 8 million for a breach of Article 33(3) because Meta's notification did not contain all required information; EUR 3 million for inadequate breach documentation under Article 33(5); EUR 130 million for poor system design under Article 25; and EUR 110 million for failing to process only necessary data by default.

The Meta decision is significant because it shows DPAs issuing standalone fines for incomplete notification content, not just for late notification.

Bank of Ireland: EUR 463,000 (Irish DPC, March 14, 2022)

The Irish DPC fined Bank of Ireland EUR 463,000 following an inquiry into 22 breach notifications made between November 2018 and June 2019. The DPC found that 19 of those incidents qualified as personal data breaches. One breach alone affected approximately 47,000 data subjects; BOI's initial notification had stated only one person was affected. The DPC found BOI had breached Article 33(1) by failing to report breaches without undue delay: in several cases, breaches were detected internally but not escalated to the DPO for nine days or more, placing the notification well outside the 72-hour window.

Permanent TSB: EUR 277,500 (Irish DPC, May 2026)

The Irish DPC fined Permanent TSB EUR 277,500 following an inquiry into personal data breaches reported from May 2022 onward. The breaches arose when malicious actors called the bank's Open24 Contact Centre, posed as customers using partial customer information, and accessed and amended account details. EUR 27,500 of the fine was specifically for Article 33(1) infringement: PTSB failed to notify the DPC within 72 hours of becoming aware of the breaches. A further EUR 250,000 was imposed for related Article 5 and Article 32 violations.

Booking.com: EUR 475,000 (Dutch DPA, 2021)

The Dutch DPA fined Booking.com EUR 475,000 after the company notified the DPA 22 days after becoming aware of a breach that exposed personal data (including financial information and passport details) of more than 4,000 customers. The delay was cited as a standalone Article 33(1) violation. The case remains a key reference point in DPA guidance on what constitutes an unacceptable notification delay.

Breach Notification in Context: How Other Jurisdictions Compare

The GDPR's 72-hour rule is among the strictest breach notification timelines in the world. A high-level comparison:

NIS2 overlap. The NIS2 Directive, which all EU member states were required to transpose by October 2024, imposes a separate 24-hour early warning followed by a 72-hour full notification to the national CSIRT or competent authority for significant cybersecurity incidents at essential and important entities. An organisation subject to both GDPR and NIS2 may need to notify two separate authorities about the same incident: the supervisory authority (DPA) under GDPR Article 33, and the NIS2 competent authority or CSIRT. The two regimes have different thresholds and different required content.

Breach Response Infrastructure

Organisations that handle breaches well have typically built the following before any incident occurs.

Detection capability. Breach notification obligations are impossible to meet without the technical ability to detect breaches quickly. Intrusion detection systems, SIEM tools, endpoint monitoring, and anomaly detection should generate actionable alerts that reach the relevant staff within hours of an incident.

A named response team. Designate roles before an incident: incident coordinator, IT/security lead, legal or DPO contact, communications lead, and executive escalation. Everyone should know their role and be reachable out of hours.

A risk assessment framework. A pre-approved scoring template (covering data categories, number of individuals, likelihood of harm, and severity) allows your team to conduct the Article 33 and 34 threshold assessments quickly and consistently. Speed at this stage directly affects whether you make the 72-hour window.

Notification templates. Draft supervisory authority notification forms and data subject letters for the most common breach scenarios (credential theft, lost device, system compromise, accidental disclosure) before an incident. Pre-approved templates save critical hours during the response.

Processor procedures. Confirm your key processors have documented breach detection and notification procedures, that their contracts specify the notification timeframe, and that you have out-of-hours escalation contacts.

A tested breach register. The register format should be established and understood by the people responsible for completing it. Untested registers often have gaps that only become visible during a supervisory authority investigation.

Tabletop exercises. Run at least one scenario exercise per year. Walk from detection through assessment, notification, and remediation. Identify where the process breaks down.

Notification Timeline Reference

More GDPR Guides

• What Is GDPR for a comprehensive overview of the regulation
• GDPR Compliance Checklist for a step-by-step compliance guide
• GDPR Fines and Penalties for enforcement data and penalty structure
• GDPR Data Subject Rights for all eight individual rights
• GDPR Consent Requirements for valid consent standards
• GDPR for Small Businesses for SME-specific guidance
• EU Data Privacy Laws for the complete EU data protection overview