The GDPR 72-Hour Breach Notification Rule (Articles 33 & 34)

A personal data breach starts a clock: notify your supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware. Here is what Articles 33 and 34 require, when you must also tell affected individuals, and how to run a response.

What counts as a personal data breach — and when the clock starts

The GDPR defines a personal data breach narrowly and precisely. Under Article 4(12), it is "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 important thing to notice is that this is broader than the everyday sense of "breach" as a hacker stealing data. A lost laptop, a misdirected email containing client records, ransomware that encrypts your only copy of a database, an employee deleting files they should not have, or a contractor accessing personal data without authorisation can all be personal data breaches. Regulators group these into three types: confidentiality breaches (unauthorised disclosure or access), integrity breaches (unauthorised alteration), and availability breaches (accidental or unlawful loss or destruction). A breach can fall into more than one type at once.

The other half of the rule that people most often get wrong is when the deadline starts running. The 72-hour clock in Article 33 does not start when the breach happens; it starts when you become "aware" of it. Regulator guidance treats you as aware once you have a reasonable degree of certainty that a security incident has occurred that compromised personal data — not at the first vague alert, but you cannot stall indefinitely by refusing to investigate. A short, prompt investigation to confirm whether a breach occurred is acceptable; deliberately staying ignorant is not.

It is also worth being clear that the 72 hours are calendar hours, not business hours. The clock keeps running over weekends and public holidays. A breach you confirm at 5pm on a Friday is not paused until Monday morning. This is general information, not legal advice — the assessment of any specific incident should be made against the official GDPR text and, where the stakes warrant it, with privacy counsel.

Article 33: notifying the supervisory authority within 72 hours

Article 33(1) sets the core obligation for controllers. When a personal data breach occurs, you must notify the competent supervisory authority "without undue delay and, where feasible, not later than 72 hours after having become aware of it." If you cannot make the deadline, you may still notify late, but the notification must be accompanied by reasons for the delay. There is one important carve-out: notification is not required where the breach is "unlikely to result in a risk to the rights and freedoms of natural persons." Note how low that bar is — the default is to notify, and you only skip the authority if you can justify that there is no real risk at all. This is a deliberately lower threshold than the one for telling individuals, which we come to next.

Article 33(3) sets out what the notification must contain. At minimum it must describe 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 concerned; the name and contact details of your data protection officer or other contact point; the likely consequences of the breach; and the measures you have taken or propose to take to address it, including, where appropriate, measures to mitigate possible adverse effects. You are not expected to have a forensic report ready in 72 hours.

That is why Article 33(4) explicitly permits phased notification. Where it is not possible to provide all the information at once, you may provide it in phases without undue further delay — notify what you know within the window, then follow up with the rest as your investigation establishes it. Getting an initial notification in on time, even an incomplete one, is better than waiting for a complete picture and blowing the deadline.

The internal breach-recording duty under Article 33(5)

There is one obligation under Article 33 that applies to every breach, regardless of whether you decide it is reportable: the recording duty in Article 33(5). It requires the controller to document any personal data breach, comprising the facts relating to the breach, its effects, and the remedial action taken. That documentation must enable the supervisory authority to verify compliance with Article 33.

The practical consequence is easy to miss. Even when you conclude that a breach is unlikely to result in a risk and therefore decide not to notify the authority, you must still record it — including your reasoning for why notification was not required. The decision not to report is itself something you have to be able to justify after the fact. An empty breach log is not evidence of a clean record; to a regulator, it can look like breaches are going undetected or unrecorded.

In practice this means maintaining a breach register: a running log of every incident, what data was involved, who was affected, what you did, when, and the risk assessment that drove your notify-or-not decision. This register is one of the first things a supervisory authority will ask to see if it ever examines your handling of an incident, so it is worth keeping it disciplined and current rather than reconstructing it under pressure later.

Article 34: when you must tell the affected individuals

Article 34 governs communication to the people whose data was breached, and it sets a deliberately higher threshold than notifying the authority. Under Article 34(1), you must communicate the breach to the affected data subjects without undue delay only when the breach is "likely to result in a high risk to the rights and freedoms of natural persons." Two tiers, two bars: you tell the supervisory authority unless the breach is unlikely to result in any risk, but you tell individuals only when it is likely to result in a high risk. Many reportable breaches therefore go to the regulator but not to the affected people.

When you do communicate to individuals, Article 34(2) says it must be in clear and plain language and must describe the nature of the breach. It must also contain at least the same three elements required for the authority notification under Article 33(3) points (b), (c) and (d): the name and contact details of your DPO or contact point, the likely consequences of the breach, and the measures taken or proposed to address it and mitigate adverse effects. Notably, the breakdown of categories and approximate numbers of affected people and records — point (a) — is for the authority, not for the individuals; the message to people should be practical and help them protect themselves.

Article 34(3) provides three exceptions where you do not have to communicate to individuals even though a high risk would otherwise be present. First, if you had applied appropriate technical and organisational protection measures to the affected data and those measures render the data unintelligible to anyone not authorised to access it — strong encryption is the textbook example. Second, if you have taken subsequent measures that ensure the high risk is no longer likely to materialise. Third, if individual communication would involve disproportionate effort — in which case you must instead make a public communication or take a similar measure by which the affected individuals are informed in an equally effective manner.

Processors, the recording duty in practice, and UK GDPR

If you are a processor rather than a controller, your obligation is different and tighter on timing in one respect. Under Article 33(2), a processor must notify the controller without undue delay after becoming aware of a personal data breach. The processor does not notify the supervisory authority or individuals directly; that responsibility sits with the controller. But because the controller's own 72-hour clock effectively depends on hearing from its processors promptly, well-drafted data processing agreements under Article 28 typically spell out exactly how fast and through what channel a processor must alert the controller. If you rely on vendors who handle personal data on your behalf — a cloud host, an email provider, a payroll bureau — your breach readiness is only as good as theirs.

The processor and recording duties work together in practice. When a processor notifies you of a breach, that triggers your own "awareness" and your Article 33 and 34 assessment, and the whole incident — the processor's report, your risk decision, and any notifications you make — belongs in your breach register under Article 33(5). The chain only works if every link is documented.

For UK organisations, the framework mirrors the EU regulation almost exactly. The UK GDPR retains the same definition of a personal data breach and the same Article 33 and Article 34 obligations, including the 72-hour deadline and the two-tier risk thresholds. The main practical difference is the regulator: in the UK the competent supervisory authority is the Information Commissioner's Office (the ICO), which operates its own breach-reporting process. Organisations active in both the EU and the UK should be ready to report to the relevant authority on each side.

A practical breach-response workflow — and where documentation fits

Because the clock is short and starts at awareness, the time to design your response is now, not during an incident. A workable sequence looks like this. First, detect and triage: get the suspected incident reported to a named owner immediately, and log the time you became aware — that timestamp anchors your 72 hours. Second, contain and investigate: stop the bleeding (revoke access, isolate systems, recover backups) and establish quickly what data and how many people are involved. Third, assess the risk on two questions in turn — is the breach likely to result in any risk (which drives the Article 33 notification), and is it likely to result in a high risk (which drives the Article 34 communication to individuals). Fourth, notify as required: the supervisory authority within 72 hours where the risk threshold is met, using phased notification if needed, and the affected individuals where the high-risk threshold is met and no Article 34(3) exception applies. Fifth, record everything in your breach register under Article 33(5), including a no-notify decision and its reasoning. Sixth, review afterwards to close the gap that allowed the breach.

The single biggest determinant of whether an organisation hits the 72-hour window is whether it had a decision-ready procedure before the incident. Cost and timing here vary enormously by incident and organisation; any figures you see are illustrative estimates, not quotes, and your actual situation will differ.

This is where the documentation layer earns its place. The ComplianceDocs GDPR Compliance Pack for Small Business includes an editable personal-data breach-response procedure alongside the related artifacts — a breach register, a DPIA procedure, processor-management materials, and an Article 30 Records of Processing Activities workbook — so you tailor a tested structure to how your organisation actually works rather than drafting one under pressure. Be clear about what that does and does not achieve: a template gives you a defensible, ready-to-run procedure and the records the regulation expects you to keep, but it does not make you "GDPR compliant." Compliance comes from operating the process — detecting breaches, assessing risk honestly, notifying on time, and keeping your register current — and, where your facts warrant it, confirming the specifics with privacy counsel.

Frequently asked questions

Does the 72-hour clock start when the breach happens or when I find out?

It starts when you become "aware" of the breach, not when the breach occurs. Under Article 33(1) you have, where feasible, up to 72 hours after becoming aware to notify the supervisory authority. Regulator guidance treats you as aware once you have a reasonable degree of certainty that a security incident compromising personal data has occurred — a brief, prompt investigation to confirm is acceptable, but you cannot delay by deliberately avoiding the question. Note the 72 hours are calendar hours and run over weekends and holidays.

Do I have to report every personal data breach to the regulator?

Not every one, but the threshold is low. Article 33(1) requires notifying the supervisory authority unless the breach is unlikely to result in a risk to individuals' rights and freedoms, so the default is to notify and you only skip it when you can justify that there is no real risk. Separately, Article 33(5) requires you to document every breach — including ones you decide not to report — together with your reasoning, so the regulator can verify your decisions. An incident you do not report is still an incident you must record.

When do I have to tell the affected individuals, not just the authority?

Article 34 requires communicating to affected individuals without undue delay only when the breach is likely to result in a high risk to their rights and freedoms — a higher bar than the one for notifying the authority. So many breaches are reported to the regulator but not to the people involved. There are three exceptions in Article 34(3): the data was protected by measures such as strong encryption that render it unintelligible; you have since taken steps so the high risk is no longer likely to materialise; or individual contact would involve disproportionate effort, in which case you make an equally effective public communication instead.

What does the breach notification to the supervisory authority have to contain?

Article 33(3) requires the notification to describe the nature of the breach, including where possible the categories and approximate number of data subjects and personal data records affected; the name and contact details of your DPO or contact point; the likely consequences of the breach; and the measures taken or proposed to address it and mitigate harm. You are not expected to have everything within 72 hours — Article 33(4) allows phased notification, so you report what you know on time and follow up with the rest without undue further delay.

What are my obligations if I am a processor rather than a controller?

Under Article 33(2), a processor must notify the controller without undue delay after becoming aware of a personal data breach. The processor does not notify the supervisory authority or individuals directly — that is the controller's responsibility — but the controller's 72-hour clock effectively depends on a prompt processor alert, which is why Article 28 data processing agreements usually specify how quickly a processor must report. The UK GDPR mirrors these duties exactly, with the ICO as the competent supervisory authority instead of an EU regulator.

Related guides: GDPR

Toolkits that help

← All articles