Why Companies Keep Failing the 72-Hour GDPR Data Breach Rule?

Nobody plans to mishandle a data breach. But when one happens, there is usually a lot of pressure, and the information is almost never complete. In most cases, the systems are down, the security team is still trying to understand what happened, and at the same time, legal is on the phone. And somewhere in the middle of all that chaos, a clock is already running.

The GDPR in Article 33(1) gives organisations 72 hours to notify their supervisory authority after becoming aware of a personal data breach. Seventy-two hours. That is three days, and in reality, far less than it sounds.

What is striking is not that companies miss this deadline. It is how often they do, and how consistently they give the same reasons. “They say they were still investigating, they were not sure the breach was serious enough to report, or they did not know the clock had already started.” And looking at the enforcement record across Europe, regulators have not been sympathetic in many of those cases.

So what is actually going wrong? Is it a lack of awareness? Poor internal processes? Could the 72-hour GDPR data breach rule be harder to follow in reality than it looks on paper? Probably all three. But the starting point has to be the rule itself because a surprising number of organisations have never really read it closely.

That is where this article begins.

Table of Contents

The Most Common Failure Patterns

Reading through enforcement decisions on GDPR data breach cases published by supervisory authorities across Europe, a pattern becomes clear. The breach itself is rarely the whole story. In many cases, the data exposure was limited, and the number of affected individuals was small, meaning the harm was containable. And yet the fine still came. What triggered it, in decision after decision, was not what happened but how the organisation responded. Specifically, whether it notified on time, whether it notified correctly, and whether it could prove it had a process in place when things went wrong.

These are the failure patterns that keep appearing.

1: The Clock Debate

When did your organisation “become aware” of the breach?

This question sounds simple. In reality, though, it is where many organisations lose their case with regulators. The GDPR law in Article 33(1) states that the 72-hour window begins when the controller becomes aware that a breach has occurred. Not when your legal team is briefed and certainly not when the investigation is complete.

The European Data Protection Board addressed this directly in its Guidelines 9/2022 on personal data breach notification. It states that a controller should be regarded as having become aware when they have “a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised.” You do not need to know everything. You just need to know enough.

Many organisations stumble at this point. An IT administrator notices something unusual on a Monday. It gets flagged internally on Wednesday. Legal is looped in on Friday. The notification goes out on the following Tuesday. By that point, the organisation is already outside the window, and when a regulator asks when the breach was first detected internally, the answer is rarely helpful.

Ultimately, what matters is when the organisation, as a whole, has sufficient information to recognise that a breach was likely. Internal delays between teams do not pause the clock.

2: Misclassifying a Breach as Low Risk

Not every breach needs to be reported. Article 33(1) includes a threshold. Notification is not required if the breach is “unlikely to result in a risk to the rights and freedoms of natural persons.” That exemption exists simply because not every incident warrants regulatory involvement.

The problem is that organisations sometimes use this exemption too literally. A breach gets logged internally as low risk. The decision not to notify is made quickly, sometimes without proper documentation. And when a regulator later reviews the incident, the risk assessment either does not exist or does not hold up.

The burden sits with the controller. Recital 85 of the GDPR makes clear that failure to notify when required “may result in greater damage to individuals.” Regulators take that seriously. If you decide not to notify, you need to be able to show your reasoning, and that reasoning needs to be grounded in a genuine assessment of the likely impact on the individuals whose data was involved.

In 2020, the Austrian Data Protection Authority issued a decision against an organisation that had experienced a breach involving customer data and chose not to notify on the basis that the risk was low. The authority disagreed with that assessment and found a violation of Article 33. The fine was modest, but the reputational cost of appearing in an enforcement decision was not.

3: Internal Escalation Delays

This failure pattern is operational, but its consequences are legal.

In many organisations, the people who first detect a breach are not the people who decide whether to notify. IT or security teams often identify an incident first. It then needs to travel up through the organisation to whoever holds responsibility for data protection decisions. If that escalation path is slow or unclear, days can disappear before the right people even know a breach has occurred.

Yes, Article 33 places the obligation on the controller. But internally, that obligation depends entirely on how well information moves through the organisation. The EDPB’s Guidelines on breach notification note that controllers should have internal reporting procedures in place that allow breach information to be escalated quickly. Without those procedures, the 72-hour window can close before a decision has even been made.

The Bank of Ireland case illustrates this failure clearly. Ireland’s Data Protection Commission found that a breach was detected by the bank’s internal systems but was not escalated to the Data Protection Officer for nine days, triggering violations of both Article 33(1) and Article 33(2) of the GDPR. The DPC emphasised that an organisation should have measures in place to facilitate awareness in a timely manner, and noted that a number of incidents were notified outside the 72-hour window on the basis that they were still “under investigation.” The DPC ultimately found that Bank of Ireland had failed to report 17 data breaches without undue delay, in violation of Article 33, and fined the bank €463,000.

The point is, the people who detect a breach and the people who report it are rarely the same. If there is no clear path between them, the clock runs anyway.

4: Phased or Incomplete Notifications

Sometimes organisations do notify within 72 hours. But the notification itself is so thin that it creates a separate problem.

In Article 33(3), the law sets out what a valid notification must contain:

It must describe the nature of the breach, including the categories and approximate number of individuals affected and the records involved.
It must provide the contact details of the data protection officer.
It must describe the likely consequences of the breach.
And it must describe the measures taken or proposed to address it.

That is a substantive list, and when organisations are still in the middle of an incident response, pulling all of that together in under 72 hours is genuinely difficult. The law, however, acknowledges this as Article 33(4) allows for information to be provided in phases where it is not possible to provide everything at once, as long as the initial notification is made within the window and further details follow without undue delay.

What regulators have pushed back on is organisations using phased notification as a workaround. Filing a bare-bones notification within 72 hours and then providing almost nothing further is not compliance. The CNIL in France has issued findings against organisations whose initial notifications were so incomplete that they provided no meaningful information to the authority, and whose follow-up communication took weeks.

The standard the EDPB applies is simple and practical: Just provide what you have. Be honest about what you do not yet know. Follow up promptly. That is a workable process. What does not work is treating the 72-hour submission as a box to tick and then going quiet.

Why the GDPR 72-Hours Rule Is Harder Than It Sounds

There is a version of the 72-hour rule that looks manageable on paper. A breach happens, you find out, and then you notify. Simple.

Then a real breach happens.

Systems go down. Your security team is still trying to understand what was accessed and what was not. The third-party vendor involved is not returning calls. Your legal team is asking questions nobody can answer yet. And in the middle of all of that, a clock is running that most people in the room did not even know had started.

The 72-hour window is a tight deadline that kicks in at the worst possible moment, when information is incomplete, teams are under pressure, and the full picture is nowhere close to being clear. Understanding why organisations struggle with it requires looking honestly at what the window actually demands in practice.

The Information Gap: You Rarely Have Full Facts in Time

When a breach first surfaces, the natural instinct is to investigate before acting. Find out exactly what happened, confirm the scope, and try to understand which data was affected. Only then, the thinking goes, is there enough information to make a proper notification.

That instinct is understandable. However, from a legal standpoint, it is a problem.

The GDPR law in Article 33(1) requires you to notify within 72 hours of becoming aware that a breach has occurred. It does not require you to have complete information before notifying. The EDPB’s Guidelines 9/2022 on personal GDPR data breach notification state that a controller should be considered aware once they have “a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised.” Certainty about the full extent of the breach is not the threshold. Reasonable awareness that something has gone wrong is.

However, in reality, by the time most incident response teams feel confident they understand what happened, 72 hours have frequently already passed. The investigation that feels responsible is, legally, a reason for a late notification finding.

Regulators have seen this pattern repeatedly. The response to it is not to wait until the investigation is complete. It is to notify with what you have and update the notification as more information becomes available. That mechanism exists in the law and is addressed directly in the next point. But first, it is worth sitting with the reality that the information gap is real. Organisations are not always being negligent when they miss the window. Sometimes they are simply trying to do the right thing in the wrong order.

The Partial Notification Mechanism Challenge

The data protection law in Article 33(4) provides a direct solution to the information gap problem. It states that where it is not possible to provide all required information at the same time, the information may be provided in phases “without undue further delay.”

This means the law does not require a complete, fully verified notification within 72 hours. It requires an initial notification within 72 hours, followed by supplementary information as it becomes available. The two obligations are separate.

This provision is, however, underused. Organisations either wait until they have enough information to file what they consider a proper notification, which often means missing the 72-hour window entirely, or they assume that filing an incomplete notification will itself attract regulatory scrutiny. That assumption is not supported by the enforcement record. What attracts scrutiny is late notification. What regulators have consistently accepted is timely notification that is honest about what is not yet known.

The EDPB’s guidance describes what an initial notification should look like when full information is unavailable:

It should describe the nature of the breach to the extent known.
It should identify the DPO or a contact point.
It should outline the likely consequences as far as they can be assessed at that stage.
It should describe any immediate containment measures already taken.
And it should be clear that further information will follow.

That is a workable submission. It does not require certainty, just transparency. Organisations that understand this tend to fare significantly better in regulatory investigations, not because they had better answers, but because they had the right process.

The CaixaBank case decided by Spain’s data protection authority, the AEPD, in November 2022, illustrates what happens when this mechanism is not used. The bank experienced a breach caused by a configuration error in an internal application. The breach affected a large number of customers. The notification did not reach the AEPD for 11 days, as the bank had been investigating. But by waiting for complete information rather than notifying with what was available, it put itself squarely in violation of Article 33(1). The AEPD issued a fine of €200,000 specifically for the notification failure.

Cross-Border Incidents

For organisations that operate across more than one EU member state, the 72-hour window comes with an additional layer of complexity. Which supervisory authority do you actually notify?

The GDPR’s answer lies in Article 56 and the one-stop-shop mechanism. Where a controller has its main establishment in one member state, it notifies the lead supervisory authority for that establishment. For a company headquartered in Ireland, that authority is the Irish Data Protection Commission. For a company with its main EU operations in France, it is the CNIL. The lead authority then coordinates with other relevant national authorities where the breach affects individuals in those jurisdictions.

In theory, this simplifies things. In reality, though, determining your lead authority is not always straightforward. Some organisations operate in multiple member states without a clearly defined main establishment. Others have different entities in different countries with separate processing activities. According to the EDPB, the main establishment is the place of central administration in the EU, or the place where decisions about the purposes and means of processing are taken. But applying that definition to a complex corporate structure under time pressure is genuinely difficult.

There is also the question of data processors. Article 33(2) requires that where a breach occurs at the level of a processor, the processor must notify the controller without undue delay. But the GDPR does not give processors the same 72-hour window that applies to controllers. The processor’s obligation is to notify as quickly as possible, so that the controller can then assess and notify the relevant supervisory authority within its own 72-hour window.

Where the breach spans multiple jurisdictions outside the EU as well, separate notification obligations under other legal frameworks may also apply. The UK GDPR, for instance, operates independently following Brexit and has its own 72-hour notification requirement to the ICO. An organisation that experiences a breach affecting individuals in both the EU and the UK faces parallel obligations to separate authorities, each with their own requirements and processes.

Organisations that have not mapped this in advance before a breach occurs are likely to find themselves scrambling to work it out mid-incident. That is not a good position to be in when every hour counts.

Third-Party Breaches

A growing number of data breaches do not originate inside the organisation that faces the regulatory obligation. They start with a vendor: a cloud provider, a data processor, or a software supplier. Under these circumstances, the controller did not cause the breach, but under the GDPR, it is still their obligation to notify.

Article 4(7) defines the controller as the entity that determines the purposes and means of processing personal data. It does not matter that the data was held by a third party at the time of the breach. If the controller is responsible for the processing, the controller is responsible for the notification.

In addition, Article 33(2) requires that processors notify controllers of a breach “without undue delay” after becoming aware of it. The processor’s swift notification is what allows the controller to meet its own 72-hour window. But if the processor delays, or if the controller does not have adequate contractual provisions in place to ensure prompt notification, the controller can find itself outside the window through no direct fault of its own.

Third-party and supply chain breaches have become one of the most common sources of data exposure. When a widely used software platform or cloud service provider experiences a security incident, the downstream effect can involve hundreds of controllers simultaneously facing notification obligations. Each of them has 72 hours from when they became aware. None of them controls the speed at which the processor shares information.

Article 28 of the GDPR requires that processing by a processor be governed by a contract that sets out, among other things, the processor’s obligations in the event of a breach. The EDPB’s standard contractual clauses for controller-processor relationships include provisions on breach notification. But many organisations have data processing agreements that are either silent on notification timelines or set timelines that are far too generous to allow the controller to meet its own regulatory deadline.

The practical consequence is that an organisation can do everything right internally and still end up with a late notification because its vendor did not tell it quickly enough. This is rarely accepted as a full defence. The expectation is that controllers will have contractual safeguards in place and will monitor their processors. Where those safeguards are absent, the controller bears the risk.

What Companies That Get It Right Do Differently

After looking at how and why organisations fail, a reasonable question follows. What does it actually look like when an organisation handles this well?

The answer is less about having more resources and more about having made certain decisions before a breach ever happens. The organisations that consistently meet the 72-hour window are not necessarily larger or better funded than those that miss it. They are just better prepared, and that preparation follows a recognisable pattern.

Pre-Defined Internal Escalation With Hard Deadlines

The single biggest operational difference between organisations that notify on time and those that do not is how quickly information moves internally when a breach is detected.

In organisations that struggle, escalation tends to be informal. Someone notices something unusual. They investigate quietly and then loop in a colleague. Eventually, it reaches someone with enough seniority to make a decision. By that point, hours or days have passed, and the 72-hour window is already closing or closed.

In organisations that get this right, escalation is a defined process with fixed timelines. There is a written procedure that specifies exactly who must be notified when a potential breach is identified, in what order, and within what timeframe. Those timelines are treated as hard deadlines, not guidelines.

And as the EDPB makes clear, controllers must have internal reporting procedures that allow breach information to flow quickly to the people responsible for making notification decisions. The guidelines note that the controller should be considered aware once any part of the organisation has sufficient information to recognise that a breach is likely. Internal delays between teams do not pause the clock under Article 33(1). The law does not distinguish between when the IT department knew and when the legal team found out. Awareness is attributed to the organisation as a whole.

What this means practically is that the escalation procedure needs to be short, clear, and enforceable. It should specify that any employee who identifies a potential security incident must report it to a designated point of contact within a set number of hours. That contact must then notify the DPO or the person responsible for data protection decisions within a further defined window. The total time from first detection to the right person being informed should be measured in hours, not days.

Organisations that have this in place tend to have one other thing in common. They test it. Running a simulated breach exercise once or twice a year, where teams practise the escalation process under realistic conditions, surfaces gaps that would otherwise only appear during an actual incident. By then, of course, it is too late to fix them.

A Breach Register That Forces Documentation From Hour One

The law in Article 33(5) requires controllers to document all personal data breaches. This includes breaches that do not meet the threshold for notification to the supervisory authority. The documentation must include the facts relating to the breach, its effects, and the remedial action taken. The supervisory authority can request access to this register at any time.

Most organisations know this requirement exists. Fewer treat the breach register as the active operational tool it is intended to be.

In well-prepared organisations, the breach register is not something that gets filled in after the incident is resolved. It is opened at the moment a potential breach is identified, and entries are made in real time as the situation develops. Every assessment, every decision, every piece of information received is recorded as it happens. This serves two purposes.

The first is practical. During a fast-moving incident, having a running record of what is known at each point in time helps the team make better decisions. When the question of notification arises, the register already contains the information needed to assess whether the threshold under Article 33(1) is met and what can be included in an initial notification.

The second is legal. If a supervisory authority later investigates the incident, the breach register is the primary evidence of how the organisation responded. A register that shows real-time documentation demonstrates that the organisation took the incident seriously from the outset. A register that was clearly filled in retrospectively tells a very different story.

The EDPB has noted that the documentation obligation under Article 33(5) is part of the broader accountability principle set out in Article 5(2). Accountability is not just about doing the right things. It is about being able to demonstrate that you did them. A breach register is one of the clearest ways to do that.

Some organisations go further and build their breach register into their incident response workflow, so that logging and escalation happen through the same system. This means that the act of raising an incident ticket automatically creates a breach register entry. Nothing falls through the gaps because the process does not allow for it.

Pre-Drafted Notification Templates

One of the most avoidable causes of late or incomplete notifications is the time it takes to produce a notification document during a live incident. Consider that the team is under pressure, multiple people could be involved in drafting, and there could be disagreements about what to include. And while that process plays out, the 72-hour window keeps running.

Organisations that handle this well solve the problem in advance. They prepare notification templates before any breach occurs, structured specifically around the requirements under the GDPR law.

As previously mentioned, Article 33(3) sets out four mandatory elements that every notification to a supervisory authority must contain:

A description of the nature of the breach, including, where possible, the categories and approximate number of individuals affected and the records involved.
The name and contact details of the DPO or another designated contact point.
A description of the likely consequences of the breach.
A description of the measures taken or proposed to address the breach, including steps to mitigate its effects.

A pre-drafted template maps directly to these four elements. Each section of the template corresponds to one of the Article 33(3) requirements, with prompts that guide whoever is completing it. Some sections, such as the DPO contact details, can be filled in permanently in advance. Others need to be completed at the time of the incident, but the structure is already there.

The template should also include a section for cases where information is not yet available, with language that explains what is known, what is still under investigation, and when the supervisory authority can expect a follow-up. This reflects the phased notification mechanism under the law and makes it easier to submit a timely initial notification even before the full picture is clear.

Having the template does not mean the notification writes itself. But it removes the blank-page problem at the worst possible time. In a 72-hour window, removing even two or three hours of drafting uncertainty can make the difference between meeting the deadline and missing it.

Several supervisory authorities publish their own notification forms, which can serve as the basis for these templates. The ICO in the UK, the CNIL in France, and the Irish DPC all provide structured notification formats. Using these as the foundation for internal templates also ensures that the format is already familiar to the authority receiving the notification, which can streamline the process at the regulatory end as well.

A Designated DPO With Actual Authority

Article 37 requires certain organisations to appoint a Data Protection Officer. The obligation applies to public authorities, organisations that carry out large-scale systematic monitoring of individuals, and organisations that process special categories of data on a large scale. For organisations that fall outside these categories, appointing a DPO is optional but widely recommended.

Where a DPO is appointed, the law requires:

That the organisation ensure the DPO is involved in all matters relating to the protection of personal data,
That the DPO has the resources necessary to carry out their tasks,
And that the DPO reports directly to the highest level of management.
In addition, Article 38(3) is explicit that the DPO must not receive instructions regarding the exercise of their tasks.

That last point matters more than many organisations appreciate. A DPO who lacks genuine authority within the organisation is not a DPO in any meaningful sense. They are a title on an organisational chart. And when a breach occurs, and decisions need to be made quickly, a DPO who has to wait for sign-off, who is routinely excluded from operational conversations, or who does not have direct access to senior management is not in a position to lead an effective response.

In too many enforcement cases, investigators have found that the DPO existed on paper but was not embedded in the organisation in a way that gave them real influence. They were consulted after decisions were made rather than before. They were informed of incidents after the initial response was already underway. The result was that the organisation’s breach response lacked the legal grounding it needed, because the person responsible for that grounding was not in the room.

Organisations that handle breaches well treat the DPO as an operational role, not a compliance formality. The DPO is part of the incident response team from the moment a potential breach is flagged. They advise on whether the notification threshold is met. They oversee the completion of the breach register under Article 33(5). They review the notification before it is submitted. And they maintain the relationship with the supervisory authority, which matters significantly if the authority follows up with questions.

Article 39 sets out the DPO’s tasks, which include advising the controller on its obligations, monitoring compliance, and cooperating with the supervisory authority. These functions are not just passive, as they require a DPO who has access, authority, and the trust of the organisation’s leadership. Where that trust exists, breach responses tend to be faster, better documented, and more defensible. Where it does not, the consequences show up in enforcement decisions.

Bottom Line

The 72-hour rule has been in force since May 2018. Eight years on, organisations are still missing it. Not because the law is unclear or regulators have been inconsistent. But because too many organisations have treated breach notification as something to figure out when it happens, rather than something to prepare for before it does.

A breach is, by nature, chaotic. The 72-hour window does not pause for that chaos. It runs through it. And the only thing that cuts through chaos reliably is a process that was built before the pressure arrived.

That is the real lesson in almost every enforcement decision out there. The organisations that faced fines were not all negligent. Some had capable teams, while others had a genuine intent to do the right thing. What they lacked was a system that could convert that intent into action fast enough to meet a legal deadline in the middle of a crisis.

The GDPR does not expect perfection. It expects accountability. It expects that when something goes wrong, you know about it quickly, you escalate it properly, you notify honestly, and you document everything. None of that requires unlimited resources. It requires preparation.

If there is one thing worth taking from this article, it is this. The organisations that consistently get this right are not the ones with the most sophisticated technology or the largest legal teams. They are the ones that asked the hard questions before the breach arrived. Who gets told first? How fast? What do we file? Who files it?

Answer those questions now, and the 72-hour window becomes manageable. Leave them for the moment a breach happens, and the clock will almost certainly win.