Handling Data Breaches: The 72-Hour Notification Rule Under GDPR Article 33

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.

Article 33 of the GDPR sets out what happens next: the data controller must notify the relevant supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of the breach. That three-day window is one of the most discussed - and most frequently misunderstood - provisions in the entire regulation.

What Article 33 Actually 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's 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 5 p.m. on Friday, the deadline expires at 5 p.m. 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.

The Irish Data Protection Commission (DPC) received 7,781 valid breach notifications in 2024, an 11% increase over 2023. Across the EU/EEA more broadly, the daily average of breach notifications surged by 22% in the year to January 2026, reaching 443 per day. The trend is clear: organisations are reporting more, not less.

Risk vs High Risk: 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.

What Your Notification Must Contain

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.

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. In 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 covered data protection by design failures under Article 25, 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 your compliance.

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 compliance failure. 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.

Building a Breach Response Plan That Works

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.

Key Elements of an Incident Response Plan

Your plan should assign clear roles. Someone needs to be the first point of contact when a potential breach is discovered. Someone needs to lead the technical investigation. Someone needs to own 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 Notification Beyond 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:

A single breach affecting users in multiple jurisdictions can trigger parallel notification obligations under several of these regimes simultaneously. 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.

How Cookie Consent Relates to Breach Preparedness

Cookie consent management and breach notification might seem like separate compliance domains, but they share a common foundation: knowing what personal data you collect, where it is stored, and who has access to it.

A website that sets analytics, advertising, and functional cookies without a clear inventory of what data those cookies collect will struggle to assess the impact of a breach involving that data. If your _ga or _fbp cookies feed into a user profile that gets exposed, can you identify the categories and approximate number of data subjects affected, as Article 33(3) requires? Without a