GDPR 72-hour breach notification rule and how to meet it

The GDPR 72-hour rule is in Article 33: when a personal data breach puts people's rights at risk, the data controller must notify its supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it. The clock runs through weekends, the report can be completed in phases, and a late report must say why it is late. Breaches unlikely to cause any risk need no report, but every breach goes into your internal register.

A personal data breach under GDPR is not limited to hackers stealing credit card numbers. It covers any security incident that leads to accidental or unlawful destruction, loss, alteration, or unauthorised disclosure of personal data. An employee emailing a spreadsheet of customer records to the wrong recipient counts. A ransomware attack locking access to a patient database counts. A laptop left on a train counts.

That three-day window is one of the most discussed - and most frequently misunderstood - provisions in the entire regulation.

What Article 33 says

The text of Article 33(1) is precise. The controller must notify the supervisory authority competent under Article 55 unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. Two things stand out here. First, the default position is to notify. The exception - where no risk exists - is narrow. Second, the 72-hour deadline runs from the moment you become aware of the breach, not from when it happened.

Awareness, according to the EDPB Guidelines 9/2022 on personal data breach notification (Version 2.0), means having a reasonable degree of certainty that a security incident has compromised personal data. If your IT team spots suspicious database queries on Monday morning but only confirms data exfiltration on Wednesday afternoon, the 72 hours start on Wednesday.

That distinction matters enormously. Regulators will scrutinise your awareness timeline during any investigation, so documenting when you learned what - and how - is not optional.

When the clock starts, and what counts as awareness

The EDPB gives several examples to illustrate the concept. If a controller receives an email from an individual claiming to have accessed its customer database and provides verifiable evidence, the controller should be considered aware once it has confirmed the breach. A controller is not expected to react to vague rumours, but neither can it ignore credible reports and claim it was never "aware".

Processors have their own obligation under Article 33(2): they must notify the controller without undue delay after discovering a breach. The GDPR does not set a specific deadline for processor-to-controller notification, but the EDPB recommends this happens promptly so the controller can meet the 72-hour window. This is precisely why your Data Processing Agreement (DPA) should specify a concrete timeframe - 24 hours is common - for your processors to alert you.

Weekends and public holidays do not pause the countdown. If you discover a breach at 5pm on Friday, the deadline expires at 5pm on Monday. Incident response teams that operate only during business hours are a liability.

Not every breach requires notification

Article 33(1) includes an important exemption: breaches that are unlikely to result in a risk to the rights and freedoms of individuals do not need to be reported to the supervisory authority. The classic example is encrypted data. If a USB drive containing customer records is lost, but those records were encrypted with a strong algorithm and the encryption key was not compromised, the risk to those individuals is negligible.

But be cautious with this exemption. You bear the burden of proving that the risk was indeed unlikely, and supervisory authorities can challenge your assessment after the fact. Article 33(5) requires you to document every breach - including those you decided not to notify - along with the facts, effects, and remedial actions taken. Your breach register must demonstrate that you assessed the risk and reached a defensible conclusion.

Organisations are reporting more, not less. The Irish Data Protection Commission (DPC) recorded 7,781 valid breach notifications in 2024, an 11% increase over 2023, according to its 2024 annual report.

Risk and high risk are two different thresholds

GDPR uses two distinct risk thresholds that trip up many organisations:

The threshold for notifying your DPA is deliberately low: any risk to rights and freedoms. The threshold for contacting affected individuals under Article 34 is higher: the breach must be likely to result in a high risk. Think identity theft, financial fraud, discrimination, or reputational damage. A misdirected email containing someone's home address might require DPA notification but not individual notification. A breach exposing medical records, religious beliefs, or login credentials almost certainly requires both.

GDPR breach notification requirements: what to include

Article 33(3) lists four categories of information that every notification to the supervisory authority must include:

The nature of the breach, including (where possible) the categories and approximate number of data subjects affected, and the categories and approximate number of personal data records involved. The name and contact details of your Data Protection Officer or another contact point. A description of the likely consequences of the breach. A description of the measures you have taken or propose to take to address the breach, including steps to mitigate its effects.

The word "approximate" appears twice in Article 33(3)(a), and the phrase "where possible" is deliberate. Regulators understand that you will not have a complete picture within 72 hours, especially for complex cyber incidents where forensic investigation may take weeks.

Phased notification is allowed

Article 33(4) explicitly permits phased reporting. You can submit an initial notification with the information available, then supplement it as your investigation progresses. Most DPAs provide online breach notification forms with fields for indicating that additional details will follow.

This is important. Some organisations delay notification because they want to gather all the facts first. That instinct is understandable but wrong under GDPR. The regulation prioritises speed over completeness. File your initial report within 72 hours, explain what you know and what you are still investigating, and then update the authority as new information emerges.

If you do miss the 72-hour window, Article 33(1) requires you to provide reasons for the delay alongside your notification. The EDPB recognises that full compliance within 72 hours is not always feasible - that is why the text says "where feasible" - but you need to be able to justify any overrun.

Will the 72 hours become 96?

Possibly, but not yet. In its Digital Omnibus proposal of 19 November 2025 (COM(2025) 837), the European Commission proposed extending the deadline for notifying the authority to 96 hours, notifying the authority only of breaches likely to cause a high risk, and a common EU reporting template. As of October 2026, the proposal is still at committee stage in the European Parliament, with a draft report published on 22 June 2026 and no vote, according to the Legislative Observatory file 2025/0360(COD). Until a change is adopted and applies, Article 33 still means 72 hours and the lower "risk" threshold.

What happens when you get notification wrong

Failure to comply with breach notification requirements under Articles 33 and 34 carries administrative fines of up to EUR 10 million or 2% of global annual turnover, whichever is higher. These sit in the lower tier of GDPR fines (the upper tier, for violations of data processing principles, can reach EUR 20 million or 4% of turnover).

But the real cost often compounds. On 17 December 2024, the Irish DPC fined Meta Platforms Ireland Limited EUR 251 million following a 2018 breach that affected approximately 29 million Facebook accounts worldwide, including 3 million in the EU/EEA. The breach had exposed users' full names, email addresses, phone numbers, dates of birth, religious views, and children's personal data through exploited user tokens.

Of that EUR 251 million total, EUR 8 million was specifically for violating Article 33(3) - submitting an incomplete breach notification that omitted information Meta could and should have included. A further EUR 3 million was imposed under Article 33(5) for failing to properly document the breach. The remaining EUR 240 million (EUR 130 million under Article 25(1) and EUR 110 million under Article 25(2)) covered data protection by design failures, which were only uncovered because the DPC investigated the breach notification in the first place.

Three months earlier, in September 2024, the same regulator fined Meta EUR 91 million after discovering that the company had stored certain user passwords in plaintext on its internal systems. That inquiry also found violations of Articles 33(1) and 33(5) - Meta had failed to notify the DPC of the breach and failed to document it adequately.

The pattern is instructive. A poor notification does not just attract a fine for the notification itself. It invites deeper regulatory scrutiny that can uncover far more expensive violations.

The breach register: Article 33(5) in practice

Every organisation processing personal data must maintain a breach register. Article 33(5) requires you to document the facts relating to each personal data breach, its effects, and the remedial action taken. This documentation must be sufficient for the supervisory authority to verify that you met Article 33.

Your breach register should capture, at minimum: the date and time the breach was discovered, who discovered it, the nature and scope of the personal data affected, the risk assessment you carried out (and the reasoning behind your notification decision), the timeline of your response, and the measures you implemented to prevent recurrence.

Even breaches you decide not to report to the DPA must be recorded. If a regulator audits your organisation and finds undocumented breaches - or breaches where no risk assessment was performed - that is itself a breach of Article 33(5). This internal documentation obligation sits alongside your broader duty to maintain records of processing activities under Article 30.

Notifying individuals under Article 34

When a breach is likely to result in a high risk to the rights and freedoms of individuals, Article 34 requires you to communicate the breach directly to those affected, without undue delay. Unlike Article 33, there is no fixed 72-hour deadline for individual notification, but "without undue delay" means you cannot sit on it either.

The notification to individuals must be in clear and plain language. Technical jargon aimed at minimising the apparent severity of the breach will not satisfy the requirement. You must describe the nature of the breach, provide your DPO's contact details, outline the likely consequences, and explain what you are doing about it - and what steps the individuals themselves can take to protect themselves.

Article 34(3) provides three exceptions where individual notification is not required. First, if you had applied appropriate technical measures - such as encryption - to the affected data, rendering it unintelligible to any unauthorised person. Second, if you have taken subsequent measures that ensure the high risk is no longer likely to materialise. Third, if individual notification would involve disproportionate effort, in which case you must make a public communication or similar measure that informs data subjects equally effectively. A prominent notice on your website, for example.

Even where you believe an exception applies, the supervisory authority retains the power under Article 34(4) to require you to notify individuals if it disagrees with your assessment.

A breach response plan that meets the deadline

Having a documented incident response plan is not a GDPR requirement in the strict legal sense - Article 33 does not mention one. But in practice, you cannot meet a 72-hour reporting deadline without one. The EDPB's guidelines describe the ability to detect, address, and report a breach in a timely manner as an essential element of the security measures required under Article 32.

What an incident response plan needs

Your plan should assign clear roles. One person needs to be the first point of contact when a potential breach is discovered. Another leads the technical investigation, and a third owns the legal and regulatory response, including the DPA notification. In smaller organisations, these might be the same person. In larger ones, you might have a dedicated breach response team spanning IT, legal, communications, and senior management.

Establish an internal escalation procedure. A front-line support agent who receives a report of suspicious account activity needs to know exactly whom to notify and how. Delays caused by ambiguity - "I wasn't sure who to tell" - eat into your 72-hour window.

Your processor contracts should include specific breach notification clauses. The GDPR requires this under Article 28, and the EDPB recommends that processor-to-controller notification happens promptly enough to give you time to assess the breach and file your own notification within 72 hours. Build in a contractual deadline - 24 hours is reasonable for most situations.

Test the plan. Tabletop exercises, where you walk through a simulated breach scenario, reveal gaps that documentation alone cannot. Run them at least annually, and involve your DPO, IT security team, and senior leadership.

Breach reporting timeframes outside the GDPR

If your website serves visitors from outside the EU/EEA, other breach notification regimes may apply in parallel. The timelines and thresholds vary considerably:

India's rules were notified on 13 November 2025 and give companies 18 months before the breach rule applies, so the 72-hour report to the Board becomes mandatory in May 2027, according to the Digital Personal Data Protection Rules, 2025. A single breach affecting users in several jurisdictions can trigger parallel obligations under several of these regimes at once, each with its own clock. Your incident response plan needs to account for this.

Common mistakes that lead to enforcement action

Regulators have seen the same errors repeatedly. Avoiding these will put you ahead of most organisations:

Waiting for the full picture before notifying. Article 33(4) allows phased notification precisely because the GDPR drafters knew that 72 hours is rarely enough for a complete investigation. File what you know, then update. Delay is the single most common reason breach notifications attract enforcement attention.

Submitting incomplete notifications without flagging the gaps. If your notification is missing information required under Article 33(3), say so explicitly and indicate when you expect to provide the rest. The Irish DPC fined Meta EUR 8 million in December 2024 specifically because the company's notification omitted information it could have included.

Failing to maintain a breach register. Article 33(5) requires documentation of all breaches, not just those reported to the DPA. An empty or patchy breach register is a red flag during any audit or investigation.

Confusing processor and controller obligations. Processors must notify controllers of breaches, not the DPA directly. Controllers must notify the DPA. If your organisation acts as both a controller and a processor for different datasets, ensure you know which hat you are wearing for each processing activity.

Assuming encryption eliminates all risk. Encryption is a strong mitigating factor - if the keys were not compromised. But encryption alone does not automatically exempt you from notification. You still need to assess the specific circumstances and document your reasoning.

Your cookie inventory feeds the breach report

Article 33(3) asks for the categories and approximate number of people affected, which is hard to answer if you do not know what your _ga or _fbp cookies collect and where it goes. A free cookie scan lists the first-party and third-party cookies your site sets and the services behind them, which is part of the data inventory a fast breach assessment depends on.

Quick answers on the 72-hour rule

Know what your website collects before a breach

Breach notification under Article 33 is one of those GDPR requirements that rewards preparation and punishes improvisation. If you do not know what personal data your website collects, you cannot assess the impact of a breach. Without an incident response plan, the 72-hour deadline is out of reach. If you do not maintain a breach register, you have already failed Article 33(5).

Kukie.io's cookie scanner finds the cookies your pages set, sorts them into categories and names the services behind them, so you know what data is in play when you assess a breach.

Start free