Data Breach Response Checklist: The First 72 Hours

The European Union is debating whether you should get more time to report a data breach. The Commission’s Digital Omnibus proposal, published in November 2025, would require a breach to be reported to a regulator only when it is likely to pose a high risk to people, and would stretch the deadline from 72 to 96 hours, according to a summary from Maples Group. It would also route reports through a single entry point run by ENISA, shared with NIS2, DORA, and other incident reporting regimes. In February 2026, Europe’s data protection authorities said in a joint opinion of the EDPB and EDPS that they back both the higher threshold and the longer deadline, and in June the EDPB adopted a common breach notification template that was open for public consultation until 5 August 2026.

None of it is law yet. The data protection part of the Omnibus is still with the Council, where the Irish Presidency is steering negotiations, as noyb reported this month. Until a final text is adopted and applies, Article 33 of the GDPR reads the way it has since 2018: notify the supervisory authority without undue delay and, where feasible, no later than 72 hours after becoming aware of a personal data breach.

In most small and mid-sized companies, the first person to become aware is not a lawyer or a data protection officer. It is whoever runs the systems. An alert fires, a colleague forwards a suspicious sign-in email, a laptop goes missing from a car, and the clock starts on the IT desk. This checklist is written for that person. It is general guidance rather than legal advice, and the decision to notify belongs to your organization as the controller, but the first 72 hours go far better when the facts reach that decision already organized.

The checklist at a glance

Within the first hour: record the exact time you became aware, open an incident record, tell whoever owns the notification decision, and preserve evidence before you clean anything up.
By hour 24: contain the breach, establish its scope (systems, data types, people, time window), and ask any vendor involved what they know.
By hour 48: assess the risk to the people affected, and write down the reasoning whichever way it falls.
By hour 72: notify the supervisory authority if the threshold is met, in phases if the picture is still incomplete.
Without undue delay: tell affected people directly when the risk to them is high.
Afterwards: finish remediation, record the root cause, and keep the breach on file even if you never reported it.

First, confirm it is a personal data breach

The GDPR defines a personal data breach as a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data. That covers far more than theft. The EDPB’s Guidelines 9/2022 on breach notification group breaches into three kinds, and IT teams tend to underestimate the last two.

Confidentiality: someone saw data they should not have. A compromised mailbox, an email with a customer spreadsheet sent to the wrong person, a storage bucket left public.
Integrity: data was changed without authorization. An attacker quietly editing the bank details on supplier records is the classic case.
Availability: data was lost or could not be reached. Ransomware that encrypts a customer database is a personal data breach even if nothing was copied out, and so is a deletion with no backup to restore from.

Not every security incident involves personal data. But nearly every personal data breach begins life as an ordinary security incident in someone’s queue, which is why the person who sees it first should ask the question early rather than on day three.

Know when the 72 hours actually start

The clock runs from awareness, not from the moment the breach happened. The EDPB guidelines treat you as aware once you have a reasonable degree of certainty that a security incident has occurred and compromised personal data. A raw alert is not yet awareness, and a short investigation to confirm what happened is acceptable. What the guidance does not allow is a leisurely investigation that conveniently postpones the moment you decide you knew.

Two practical consequences follow. The 72 hours are not business hours, so a breach confirmed at five on a Friday afternoon is due at five on Monday afternoon. And the time of awareness is the timestamp every later decision is measured against, so it needs to be written down to the minute. The ICO’s guide for small organisations on the first 72 hours puts it plainly: start the timer and start a log, even before you know whether the breach is reportable.

Within the first hour

Write down the time and the source. When you became aware, who told you, through which channel, and what they actually said. Their words, not your summary.
Open an incident record now. Do not wait for the full picture. A thin record opened in the first hour beats a thorough one opened on day two, because the record is where the timeline lives.
Tell the person who owns the decision. That might be a data protection officer, a privacy lead, or a founder. IT runs the response, but the organization decides what gets reported, and that person needs as much of the 72 hours as possible, not the leftovers.
Preserve before you clean. Export the relevant logs before retention windows roll them over, snapshot affected systems, and keep the phishing email with its full headers. Reimaging a laptop feels productive, and it destroys the evidence you will need to say what was accessed.

By hour 24: contain it and establish the facts

Containment and scoping run in parallel, and both feed the notification.

Contain. Revoke active sessions and tokens, reset affected credentials, disable compromised accounts, isolate hosts, remove public access from exposed storage, and remote wipe a lost device if you can. For a misdirected email, contact the recipient, ask them to delete it, and get their confirmation in writing.
Scope. Which systems, which kinds of data, roughly how many people and records, and over what time window. Approximate numbers are fine at this stage, since the regulation itself asks for approximate figures.
Separate facts from suspicions. Log what you have confirmed and what you still suspect as separate entries, each with a timestamp. A notification written from a clean timeline is faster to draft and easier to correct later.
Check the supply chain. If a vendor processes the data on your behalf, Article 33(2) requires them to tell you without undue delay, so ask what they know and when they knew it. If you are the vendor, your obligation is to tell your customer quickly, because they are the controller and the notification to the regulator is theirs to make.

By hour 48: assess the risk to people

The test is the risk to the individuals whose data was involved, not the embarrassment to the company. These questions do most of the work.

What kind of data is it? Names and email addresses sit at one end. Financial details, identity documents, health information, and the other special categories sit at the other.
How many people, and who are they? Scale matters, and so does vulnerability. Children’s data raises the stakes quickly.
How easily can someone be identified? Either from the data alone or combined with what is already public.
What could realistically happen? Fraud, identity theft, discrimination, or real distress.
Does the protection still hold? Strong encryption with keys that were not compromised can change the answer, particularly when the breach is about confidentiality.

The assessment lands in one of three places. If the breach is unlikely to result in a risk to people, you record it and do not notify. If there is a risk, you notify the supervisory authority. If the risk is high, you also tell the people affected. Whichever it is, write down the reasoning. Article 33(5) requires you to document every personal data breach, including its facts, its effects, and the remedial action taken, and that record is what a regulator will read if it ever asks why you decided a breach did not need reporting.

By hour 72: notify, even if the picture is incomplete

Under Article 33(3), a notification to the supervisory authority has to cover four things.

The nature of the breach, including where possible the categories and approximate number of people and records concerned.
The name and contact details of your data protection officer or another contact point.
The likely consequences of the breach.
The measures taken or proposed, including steps to limit possible harm.

You do not need all of it at once. Article 33(4) allows the information to be provided in phases, so send what you know inside the window and follow up as the investigation firms up. If you do miss the 72 hours, the notification has to include the reasons for the delay. The EDPB’s common template is meant to give these fields the same shape across Europe once data protection authorities implement it, on a timeline the Board will set after the consultation. Until then, use the form your national authority provides.

When the risk to people is high, Article 34 requires you to tell them without undue delay and in clear, plain language: what happened, who they can contact, the likely consequences, and what you have done about it. There are narrow exceptions, such as data that was encrypted and remains unintelligible. The ICO also recommends giving specific advice on how people can protect themselves, and specific is the operative word. “Change the password for this service and anywhere else you reused it, and treat any email quoting your order history as suspicious” helps. “Remain vigilant” does not.

After the 72 hours

Finish the remediation work and track every item through to done. The loose end nobody owns is the one that turns into the next breach.
Record the root cause, not just the fix. “Reset the password” is the fix. “No multi-factor authentication on the shared mailbox” is the cause.
Update your breach procedure with whatever slowed you down this time.
Keep the record. The breach stays on file whether or not anything was reported.

If you operate outside the EU and the UK, your regime may use a different threshold or count in days rather than hours. The shape of this checklist still holds: record awareness, contain, scope, assess, decide, notify, document. Check the exact deadline with your regulator before you need it.

Where ISO Mate fits

The hardest part of the first 72 hours is rarely the technical fix. It is keeping one accurate record while several people work the problem in different places. That is the job of Incident Management in ISO Mate.

One record from the first minute. Create an incident with the Data Breach category and ISO Mate asks for Data Subjects Affected, Data Types Compromised, and the Breach Discovery Date, then calculates the 72 hour Notification Deadline from that date. The discovery field records the day rather than the hour, so write the exact time of awareness into the description as well.
A deadline everyone can see. The GDPR Data Breach card on the incident shows People Affected, the Notification Deadline, and whether the supervisory authority has been notified and when. Mark the breach as high risk to data subjects and a Data Subjects Notified item joins it. The card reads Compliant or Action Required, so nobody has to work out the status from memory.
Named owners. Add people to the Response Team as Reporter, Assignee, or Stakeholder. An incident cannot move to Investigating until it has an Assignee, and assignees are reminded as an incident that is still Open or Investigating approaches 72 hours since it was logged, then again once it passes. One more reason to log it the moment you know.
Loose ends with owners. Link a task to each containment and remediation step, and link notes for the risk assessment and the reasoning behind the notification decision. An incident cannot be marked Resolved without a Root Cause and a Resolution Description, and it cannot be Closed until every linked task is complete.
A breach register that builds itself. Every change lands in the incident’s activity timeline with the user and a timestamp. The GDPR Compliance tab in Incident Reports shows total data breaches, how many were notified to the authority and to the people affected, overdue notifications, and a compliance rate, and incident lists export to CSV or PDF with your filters applied.

ISO Mate does not file the notification with your regulator, and it does not decide whether a breach is reportable. Those calls stay with your organization. What it gives you is the timeline, the owners, and the evidence in one place when you make them. The incident tracking guide walks through each field.

Rehearse it before you need it

If you have applied the GDPR framework template in Compliance Management, you already have a starting point: a draft Data Breach Response Policy and a Data Breach Notification Procedure. The procedure’s eight steps run from detection and containment through the Article 33 notification and the breach register to a review once the breach is closed, and it comes mapped to the template’s breach detection, response, and notification controls. Publish it, give it a Yearly recurrence, and ISO Mate generates a task carrying those steps each year, as described in managing procedures. Run that task as a tabletop exercise with an invented scenario, time each step, and you will find the gaps while no real clock is running.

The deadline may yet move to 96 hours, and the threshold may rise. Neither changes what decides how the first three days go: whether someone wrote down the time, opened a record, and gave every loose end an owner. If you would rather have that in place before the next alert fires, every ISO Mate account starts with a 14-day free trial.