GDPR Data Breach Reporting Obligations and Timelines
Under GDPR, a personal data breach is any security event leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. Three categories fall within that definition: confidentiality breaches, integrity breaches, and availability breaches. You don't need malicious intent. A misconfigured cloud storage bucket qualifies. So does an unencrypted laptop going missing, or an email sent to the wrong person.
Once an event fits the definition, the clock starts and the documentation obligations begin.
The law then creates two separate triggers. A breach "likely to result in a risk to the rights and freedoms of natural persons" triggers mandatory notification to the relevant supervisory authority under Article 33. Elevate that to a "high risk" and Article 34 adds a direct obligation to notify the affected individuals. A third path exists: breaches assessed as unlikely to produce any risk carry no DPA notification requirement, but documentation is mandatory regardless of where that assessment lands.
Determining where a specific breach falls means weighing the sensitivity of the data, the volume of individuals affected, ease of identification, and whether special categories were compromised, including health information, financial data, or religious views. The European Data Protection Board directs organisations to evaluate both the likelihood and severity of harm: reputational damage, financial loss, discrimination, physical harm.
Meta's 2024 fine of €251 million, issued by the Irish Data Protection Commission over a 2018 breach affecting 29 million Facebook users globally, centred substantially on exposed religious views. That classification as high-risk drove the enforcement outcome.
Risk assessment is not a box to tick after the real decisions are made. Underestimating risk and failing to notify when required creates enforcement exposure. Overestimating and notifying unnecessarily draws regulatory scrutiny of a different kind. Both directions carry consequences.
When the 72-Hour Clock Actually Starts
Article 33 requires notification "without undue delay and, where feasible, not later than 72 hours after having become aware" of a breach. The operative question, and the one organisations consistently misread, is what "aware" actually means.
The EDPB's Guidelines 9/2022, adopted in March 2023, define awareness as a reasonable degree of certainty that a security incident has occurred and that personal data has been compromised. The clock starts when that threshold is crossed, not when the investigation concludes.
This distinction catches organisations off guard more than almost anything else in this framework. When a third party delivers concrete evidence of unauthorised disclosure, the clock starts on receipt. When ransomware unfolds and affected data must be established forensically, awareness builds gradually; the clock starts when sufficient certainty is reached, which is before forensics conclude. Organisations that wait for a complete picture before treating themselves as "aware" are already in breach of the timeline by the time they file.
The 72-hour window is not time to investigate. It is time to notify with whatever accurate information is available, supplemented by updates as the picture clarifies.
Processor obligations feed directly into this. Processors must notify controllers "without undue delay" following discovery of a breach. The statute specifies no hour limit for that step, but any processor contract lacking a concrete service level agreement for breach notification — one specific enough to let the controller meet its own 72-hour obligation — is a compliance gap waiting to matter.
When notification cannot be made within 72 hours, the law requires the filing be accompanied by reasons for the delay. This is an explanation appended to a late notification, not a deadline extension. Regulators treat those two things very differently.
What a Notification to the Supervisory Authority Must Contain
Article 33(3) specifies four minimum required elements: the nature of the breach, including the categories and approximate number of data subjects and personal data records involved; contact details for the DPO or another designated contact point; likely consequences, meaning a description of the probable effects; and measures taken or proposed to address the breach and mitigate its effects.
The word "approximate" carries real weight. Precise figures are not required. Honest estimates based on what is known at the time of filing are acceptable. The obligation is accuracy, not exhaustive completeness.
Article 33(4) explicitly permits phased notification where providing all required information simultaneously is not possible. The initial filing must explain what is missing and when follow-up is expected. Multi-system cyberattacks and supply-chain breaches are the obvious cases where this applies. It is a built-in mechanism, not a workaround, but each follow-up must arrive without undue further delay.
The Meta enforcement case illustrates where this distinction bites. The Irish DPC found that Meta submitted incomplete notifications and failed to fully document the breach affecting those 29 million users. Incomplete is not the same as phased. Phased notification requires transparency about what is missing and a genuine commitment to follow through promptly. Silence about the gap is a different matter entirely.
Where to file also matters practically. Each EU member state data protection authority operates its own notification portal and form, a point addressed further below.
Notifying Affected Individuals Under Article 34
The trigger for individual notification sits at a higher threshold: the breach must be "likely to result in a high risk" to the rights and freedoms of the individuals concerned. Article 34 carries no fixed hour deadline; the obligation runs "without undue delay," and regulators expect communication as soon as practicable after the high-risk determination is made.
The required communication must use clear and plain language. No legal jargon. It must convey the nature of the breach, the contact details of the DPO or designated contact point, the likely consequences, and the measures taken or proposed. The standard is comprehension by the recipient.
Three exceptions remove the direct notification obligation. First, effective encryption: if the controller implemented measures rendering the data unintelligible to anyone without the decryption key, direct notification is not required. Second, subsequent mitigation: if the controller takes steps ensuring the high risk is no longer likely to materialise, the obligation falls away. Third, disproportionate effort: where contacting individuals directly is not feasible, a public communication such as a press notice may substitute. That third exception is narrow, not a general escape route.
The encryption exception deserves particular attention. Encryption transforms a high-risk breach into a situation where individual notification is not legally required. That is a direct legal consequence of a technical control, and it belongs in every internal conversation about security investment, framed exactly that way.
The Norwegian municipality case involving Østre Toten shows what happens when the response process fails. Following a cyberattack exposing health and social service records, the supervisory authority found the municipality failed to notify affected individuals in a timely manner. Both Article 33 and Article 34 obligations were found deficient. The resulting fine was substantial.
The Internal Breach Register Every Controller Must Maintain
Article 33(5) requires controllers to document all personal data breaches: all of them, including those assessed as not requiring DPA notification.
Each entry must capture the facts surrounding the breach, its effects, the remedial action taken, and the risk assessment and reasoning behind any decision not to notify. That last element is where organisations most frequently create vulnerability. If a controller decides a breach does not clear the notification threshold, that decision must be documented and justified in terms a supervisory authority can evaluate during an audit or investigation. Absence of documentation is exposure, not neutrality.
The register is the accountability mechanism. It is how a controller demonstrates compliance rather than merely achieving it, a distinction the GDPR's accountability principle takes seriously. An organisation that handled breaches appropriately but documented nothing has a difficult conversation ahead during any regulatory review.
Triage needs to generate a register entry for every security incident, including those resolved quickly and assessed as low-risk. Building the register retrospectively from memory, after an investigation begins, is not a viable approach. Regulators can usually tell when that is what happened, and they ask pointed questions.
How the One-Stop-Shop Mechanism Works, and When It Does Not Apply
The one-stop-shop principle allows a controller with a main establishment in an EU member state to file a single breach notification with its lead supervisory authority, which then coordinates with other national DPAs as needed. For organisations with a clear EU main establishment, this is a meaningful administrative simplification.
The exception matters enormously. A controller without a main establishment in the EU cannot use the one-stop-shop mechanism. EDPB Guidelines 9/2022 clarified at paragraph 73 that the presence of an Article 27 representative in an EU member state does not trigger the one-stop-shop. A representative is not a main establishment. These organisations must notify each relevant national DPA separately, using each authority's own form and portal.
Germany illustrates the practical scale of that burden. A breach affecting German residents can require separate submissions to supervisory authorities across up to sixteen federal states. Multiply that across multiple member states and the administrative weight accumulates fast.
Knowing which DPA is the lead authority, or which national DPAs must each be notified individually, is a question that needs answering before a breach occurs. Resolving it during a breach, under a running 72-hour clock, is not a planning failure that happens rarely. It happens to organisations that assumed they had time to work it out later.
What Enforcement Data Reveals About Where Regulators Focus
European DPAs received 443 breach notifications per day in the year to January 2026, the first time daily reports exceeded 400 since GDPR came into force, according to Kiteworks GDPR Compliance 2026 analysis. By country, the Netherlands led with 39,773 notifications, followed by Germany with 34,467 and Poland with 19,065. Adjusted for population, the Netherlands topped at 223.79 notifications per 100,000 residents, followed by Liechtenstein and Denmark.
DLA Piper's 2025 survey noted a levelling-off trend in notification growth and identified something worth naming directly: organisations are becoming more cautious about reporting, precisely because notifications can trigger investigations, enforcement actions, fines, and compensation claims. This tension is structural, built into the framework itself, and treating it as a background consideration rather than an explicit compliance decision produces a worse posture.
The fine structure runs on two tiers. Notification failures under Articles 33 and 34 carry penalties of up to tens of millions of euros or 2% of global annual turnover. Deliberate concealment or underlying security failures can reach tens of millions of euros or a higher percentage of global annual turnover. Cumulative GDPR fines since May 2018 have reached €7.1 billion, with annual figures stabilising at approximately €1.2 billion.
The enforcement pattern across cases is consistent: authorities are systematically more lenient about the breach itself and more severe about failures to notify transparently and on time. The breach is frequently treated as a security failure that could happen to any organisation. The notification failure is treated as a choice.
Meta's €251 million fine centred on incomplete notifications and inadequate documentation; the Irish DPC found explicit violations of Article 33, not just underlying security failures. A French healthcare operator was fined by the CNIL in 2024 following a breach affecting 33 million patients, with citations for delayed notification and inadequate security measures. Østre Toten's approximately €400,000 fine was driven by procedural failures in the response, not the breach itself. Ireland's position as lead supervisory authority for major technology firms has produced outsized enforcement totals; the Irish DPC accounts for €4.04 billion in cumulative fines.
Building a Breach Response Process That Meets These Obligations in Practice
Here is what I have seen repeatedly: organisations that struggle through breach response are not, as a rule, the ones with the weakest security infrastructure. They are the ones that expected to figure it out when the time came. The 72-hour clock does not pause while you work out who owns the decision or which portal to use.
A functional process requires five things to work, and in practice, the gaps tend to cluster in predictable places.
Detection and internal escalation: clear ownership of who declares a potential breach and triggers the response. Define which events must be escalated, to whom, and connect IT security, legal, and the DPO from the outset, not after initial decisions are already made.
Triage and risk assessment: a documented evaluation against the risk and high-risk thresholds, producing a register entry regardless of outcome. The register entry is generated by the triage process, not after it resolves. Low-risk assessments get documented with the reasoning; incidents clearing the notification threshold feed directly into the DPA filing.
DPA notification, or a documented decision not to notify. If the risk threshold is met, the process must specify who files, using which portal, with what initial content, and who owns follow-up under the phased notification mechanism.
Individual notification where the breach is high-risk. Pre-draft the communication template. Define the channel for reaching affected individuals. Build the process for invoking the exceptions where they apply, and document the reasoning when they do.
Post-incident review and register maintenance: close out the register entry with final findings, ensure the DPA file is complete, and feed lessons back into detection and triage.
The organisations that handle breaches well built a process before they needed it. That is the whole advantage. When the pressure hits, they run the process. Everything else follows from that.
