🇪🇺 GDPR🗺️ Implementation🚨 Breach Response

GDPR Data Breach Response — A 72-Hour Compliance Plan

The clock starts when awareness lands, not when the team is ready. What the first three days have to look like.

GK
Gauri Khatate
🔐 Cybersecurity Expert & Technical Writer·📖 7 min read
📅 May 2026·🏢 SecComply
GDPR data breach response 72 hours notification supervisory authority

Breach response is graded on the worst day of the year — against a 72-hour clock that does not pause for weekends.

A breach response is graded on the worst day of the year, under the worst conditions, against a clock that does not pause for weekends. By the time an incident is confirmed, the hard calls-is this reportable, to whom, how fast, what to say-are being made by tired people under pressure, and the regulation allows seventy-two hours to get them right. The teams that move through that window cleanly are never the ones improvising it. They rehearsed it. What follows is what “rehearsed” actually means.

72 hours
To notify the supervisory authority after becoming aware of a reportable breach (Art 33)
Undue delay
The standard for telling affected individuals when the risk to them is high (Art 34)
€20M / 4%
The fine tier for breach and security failures (Art 83)
Every breach
Must be logged internally-even the ones that don’t have to be reported (Art 33(5))

The Clock Starts at “Aware,” Not “Understood”

The most misread word in breach response is “aware.” The seventy-two hours don’t begin when the investigation is finished, the root cause is known, or legal review is complete. They begin the moment the organisation has a reasonable degree of certainty that a personal data breach has occurred-which is usually long before anyone has the full picture. This is deliberate. The regulation expects an initial notification on partial information, updated as facts come in, rather than a perfect report delivered late. Treating “aware” as “fully understood” is exactly how organisations talk themselves into missing the deadline while feeling responsible.

Not Every Incident Is a Reportable Breach

A personal data breach is broader than a hack. It’s any breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data-which covers a lost laptop, an email to the wrong recipient, ransomware that locks data that can’t be restored, or a misconfigured storage bucket. But not every breach has to be reported. The test is risk to people: notify the authority unless the breach is unlikely to result in a risk to individuals’ rights and freedoms, and notify the individuals themselves only when that risk is high. The judgment-risk or no risk, high or not-is the part that has to be made fast and documented either way.

ObligationWhen it appliesThe trap
Notify the authority (Art 33)Within 72h of awareness, unless unlikely to risk individualsWaiting for full facts; missing the clock on a partial report
Notify individuals (Art 34)Without undue delay, when the risk to them is highOver- or under-notifying; vague wording that panics or does nothing
Document everything (Art 33(5))Every breach, reportable or notNo internal log; unable to show the reasoning behind a “no report” call

You Can’t Notify What You Can’t Detect

The seventy-two-hour clock has a precondition that lives months earlier: detection. An organisation that cannot tell when its systems have been accessed has no hope of meeting a deadline measured from awareness, because awareness never arrives-or arrives years late. This is the uncomfortable truth running through most of the largest breach fines: the failure wasn’t slow notification, it was blind monitoring. Logging, alerting, and the ability to reconstruct who touched what and when are not security niceties. They are what makes the legal deadline achievable at all.

UNDETECTED FOR YEARS-MARRIOTT (ICO, 2020)

Marriott was fined £18.4 million by the UK regulator over a breach affecting an estimated 339 million guest records. The detail that matters for breach response: the underlying intrusion began in 2014, in systems Marriott later acquired with Starwood, and went undetected until 2018. The regulator’s central criticism wasn’t the speed of notification-it was the insufficient monitoring and logging of privileged accounts that let an attacker move through the environment unseen for years. A seventy-two-hour obligation is meaningless against a four-year blind spot. The lesson sits upstream of any incident plan: detection capability is the first line of a breach response, not the last.

Fast and Honest Beats Slow and Polished

When a breach is real and reportable, the instinct to wait-for certainty, for a cleaner story, for legal sign-off on every word-is the instinct to resist. Regulators consistently treat prompt, cooperative notification as a mitigating factor, and concealment or delay as an aggravating one. A short, honest “here is what is known and what is still being investigated” notification inside the window is worth far more than a comprehensive one that arrives late. The same logic governs the message to individuals: tell them what happened, what data was involved, what the risk is, and what to do about it-in plain language, without minimising.

SPEED AS MITIGATION-BRITISH AIRWAYS (ICO, 2020)

British Airways was fined £20 million after a 2018 attack compromised the data of around 500,000 customers-and notably, the company learned of the breach from a third party, a sign of the same monitoring gap. But once aware, BA notified the regulator and began contacting affected customers the very next day. The penalty notice reflected that prompt notification and cooperation as mitigating factors, and the final fine landed far below the £183 million originally proposed. The two halves of the case make a single point: weak detection drove the breach and the size of the penalty, while fast, clean notification afterward measurably reduced the damage. Both are decisions made long before the incident-one in the architecture, one in the rehearsed plan.

The First 72 Hours, Sequenced

A plan that holds up assigns names and timeboxes, not intentions. Hour zero to one: contain and preserve-stop the bleed, protect the logs and evidence, and convene the named response team. Hour one to twenty-four: assess-what data, whose, how much, what risk-and crucially, log the assessment as it evolves. Hour twenty-four to seventy-two: notify the authority with what is known, flagging what is still under investigation, and decide whether individual notification is triggered. Throughout: one owner of the timeline and one record of decisions, so the “why we did what we did” is captured in real time rather than reconstructed under scrutiny later. Roles, contacts, and the decision tree are agreed in advance-the incident is not the moment to discover who has authority to notify.

Improvised vs. Rehearsed

Pattern-matching from real incident reviews-the gap between a response that scrambles and one that holds tends to follow the same shape:

Improvised responseRehearsed response
✗ Clock assumed to start when the investigation ends✓ Clock tracked from the moment of awareness
✗ “Is this reportable?” argued from scratch under pressure✓ A decision tree agreed and tested in advance
✗ No one sure who can authorise notification✓ Named owner, deputy, and contacts on a call tree
✗ Detection depends on a customer or third party noticing✓ Logging and alerting that surface intrusions internally
✗ Notification delayed for a perfect, complete report✓ Initial notice on partial facts, updated as they firm up
✗ Only reportable breaches recorded, if any✓ Every breach logged with the reasoning behind the call
✗ Decisions reconstructed weeks later for the regulator✓ A contemporaneous decision log built as events unfold

Rehearse the Worst Day Before It Arrives

The distance between a £183 million proposal and a £20 million fine is partly luck and partly preparation-and only one of those is controllable. A breach plan that lives in a document nobody has opened is not a plan; it’s a liability with a cover page. The organisations that handle the seventy-two hours well run the drill: a tabletop exercise that forces the team to make the reportability call, draft the notification, and find out-in a room, not in a crisis-who freezes, what’s missing, and which contact details are out of date. The plan is only ever as good as the last time it was tested.

Final Thought

A data breach is the one privacy event where an organisation’s competence is measured publicly, on a deadline, with regulators and customers watching at once. The regulation’s seventy-two hours are generous enough to be achievable and tight enough to expose anyone improvising. Everything that makes the window survivable-detection, a decision tree, named owners, a contemporaneous log, the instinct to notify fast and honestly-is built in calm conditions, long before it’s needed.

The test: if a confirmed breach landed this afternoon, could the team name who leads, decide reportability against an agreed standard, draft a defensible notification, and start the regulator’s clock correctly-today, not after a week of meetings. If any of that is improvised, the next seventy-two hours are already at risk.

Could You Survive a Breach Clock Today?

SecComply builds breach response plans, notification templates, and the internal breach log GDPR requires — so the worst day of the year is one you have rehearsed.

Frequently Asked Questions

When does the GDPR 72-hour clock start?

When you become aware of a personal data breach, not when the investigation is finished. Awareness means you have a reasonable degree of certainty that a security incident has compromised personal data (Article 33).

Do I have to report every breach to the authority?

No. You must notify the supervisory authority within 72 hours unless the breach is unlikely to result in a risk to individuals — but you must log every breach internally, including the ones you decide not to report (Article 33(5)).

When must I tell the affected individuals?

Without undue delay when the breach is likely to result in a high risk to their rights and freedoms (Article 34). The communication has to be clear and help them protect themselves.

What are the fines for getting breach response wrong?

Breach and security failures fall in the tier of up to €20 million or 4% of global annual turnover, whichever is higher (Article 83).