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 28 March 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.

A European Commission proposal published in November 2025 would move the deadline to 96 hours and raise the notification threshold, but it is not law. See Proposed Changes (Not Yet Law) below.

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 EDPB SME guide on data breaches and EDPB Guidelines 9/2022 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). The lead authority is not necessarily the one where the affected individuals are, or where the breach happened. When you notify it, indicate which member states' data subjects are likely to have been affected.

If you are genuinely unsure which authority is the lead, EDPB Guidelines 9/2022 paragraph 69 says to notify at minimum the local supervisory authority of the member state where the breach took place.

The one-stop-shop is only for controllers established in the EU or EEA. A controller caught by Article 3(2) that has no EU establishment, and only an Article 27 representative, does not get it. Paragraph 73 of the same guidelines states that the breach must then be notified to every supervisory authority in whose member state affected data subjects reside, and that those notifications remain the responsibility of the controller under Article 27(5). A representative may file only where the controller has expressly mandated it.

This is the rule that catches US and other non-EU companies serving EU customers: filing with a single DPA is not enough when the affected individuals live in several member states.

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.

Proposed Changes (Not Yet Law)

On 19 November 2025 the European Commission published its Digital Omnibus proposal, COM(2025) 837 final (procedure 2025/0360(COD)). It would rewrite Article 33(1) in three ways.

The deadline would move from 72 hours to 96 hours. The trigger would rise from a risk to individuals to a likely high risk, matching the Article 34 threshold. And notifications would be filed through the single entry point set up under Article 23a of the NIS2 Directive, with the EDPB asked to produce a common notification template.

This is a proposal, not law. The file is still in first reading and is listed as awaiting committee decision in the European Parliament as of 10 September 2026. Until it is adopted and applies, the 72-hour deadline and the risk threshold described on this page apply in full.

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. EDPB Guidelines 9/2022 paragraph 44 puts it directly: the controller should in principle be considered aware once the processor has informed it. A processor that sat on the incident for days does not move the controller's start point backwards, but it may itself face regulatory scrutiny under Article 33(2).

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

The guidance sets a two-step rule, and controllers get it wrong in both directions.

A short initial investigation to establish whether a breach happened at all does not itself start the clock. EDPB Guidelines 9/2022 paragraph 34 says that during that period the controller may not be regarded as aware. But that investigation must begin as soon as possible, and once the controller has a reasonable degree of certainty that personal data was compromised, awareness is fixed and the 72 hours run even though the scope and cause are still unknown.

The guidelines give clear-cut cases where awareness is immediate: an unencrypted USB key is lost, a third party produces evidence that it received someone else's personal data, or an attacker contacts the controller demanding a ransom after a confirmed intrusion. An unexplained alert on its own is the opposite case. In the guidelines' own example, a detected possible intrusion becomes awareness only when the controller checks its systems and confirms personal data was compromised.

What controllers cannot do is let the full forensic investigation run past the deadline. Notify on what you have and supplement under Article 33(4).

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. Paragraph 45 of the EDPB Guidelines 9/2022 recommends that the processor notify the controller promptly, with further information provided in phases as more details become available, precisely so that the controller can still meet its own 72-hour deadline to the supervisory authority.

The 72 hours in Article 33(1) belongs to the controller alone. A processor that waits three days before telling the controller has consumed the controller's entire statutory window, and "without undue delay" in Article 33(2) does not stretch that far.

What This Means for Contracts

Article 28 data processing agreements should specify:

• A maximum notification window from processor to controller (24 hours is common commercial practice, not an EDPB recommendation; the EDPB sets no fixed limit and expects prompt notification)
• 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. The article names three things the register must contain:

• 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 action taken

The same paragraph adds that the documentation must enable the supervisory authority to verify compliance with Article 33. Because a bare conclusion does not do that, the EDPB and national DPAs expect the register to also record:

• 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. Article 33(5) requires the register to let the supervisory authority verify compliance, and a bare conclusion does not. 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 that BOI infringed Article 33 in respect of 17 of the reported breaches: Article 33(1) where breaches were not reported without undue delay, and Article 33(3) where the notifications did not contain the information the article requires. It also found infringements of Article 34(1), for failing to communicate breaches to the affected customers, and of Article 32(1), for inadequate technical and organisational measures. The reported delays ran from days to months after BOI became aware. The two breaches that drew Article 33 fines were reported 23 days and 10 days after BOI became aware of them. In the largest incident the breach had been running since January 2018 and BOI notified it on the day it finally became aware, 26 April 2019; the DPC found Article 33(1) infringed because BOI ought to have detected it far earlier. People in Ireland whose data is caught up in a breach like this can complain to the Data Protection Commission.

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 reported a breach on 7 February 2019 that it had been informed of on 13 January 2019. That is 25 days after becoming aware, or 22 days past the 72-hour deadline. Criminals had obtained the names, addresses, telephone numbers and booking details of 4,109 customers who had booked hotel rooms in the United Arab Emirates, plus the credit card data of 283 of them, including the security code in 97 cases. 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, and then a final report no later than one month after that incident notification (Article 23(4)(d)), plus an intermediate progress report if the authority asks for one. 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

Read the left column as an outer limit, not a schedule. Article 33(1)'s primary duty is to notify without undue delay, so a notification that is ready at hour 10 is filed at hour 10, not held until hour 72.

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