Data breach: the first 72 hours decide everything
What to do when a data breach happens — from confirming the incident, through limiting the impact, to GDPR obligations.
A data breach is the moment when chaos costs the most. The decisions made in the first hours — or the lack of them — determine the scale of financial, reputational and legal damage. The GDPR gives just 72 hours to report a breach to the supervisory authority. That’s short if the response plan is being written only during the incident.
First, confirm whether it really is a breach
Not every alert means a breach. The first step is to establish whether unauthorised access to data occurred, and if so — what data and to what extent. Prematurely announcing a breach that wasn’t one carries its own costs; ignoring a real breach is even worse.
At this stage, logs are key. If the organisation has centralised logging and can reconstruct the access path, establishing the scope takes hours. Without logs it becomes guesswork, and in the event of an inspection it’s hard to demonstrate exactly what happened.
Limit the impact, but don’t destroy evidence
The natural instinct is to “clean up” immediately: delete malicious files, rebuild the server, change all passwords. The problem is that hasty actions destroy the evidence needed to determine the cause and scope.
The correct order is isolation, not destruction: disconnecting affected systems from the network, securing disk and memory images, revoking credentials that may have been compromised. Where possible, analysis is done on copies, with the originals preserved as evidence.
GDPR obligations
If a breach affects personal data and may pose a risk to the data subjects, it must be reported to the supervisory authority within 72 hours of becoming aware of it (GDPR Article 33). Where the risk is high, the individuals themselves must also be notified without undue delay (Article 34).
The report must include, among other things, the nature of the breach, the categories and approximate number of people and records, the possible consequences and the measures taken. This is why the ability to quickly establish the scope of a breach has not only a technical but also a legal dimension.
Hour by hour: a sample run of the first 72 hours
A framework scenario that works in practice (assuming the plan and roles exist):
- Hours 0–2: confirming the signal (an alert, an internal report, outside information), convening the incident team, opening the incident log — from this moment every decision and hour is recorded.
- Hours 2–8: isolating affected systems, revoking potentially compromised credentials, securing logs and images. Initial assessment: what data, how many people, is the attacker still active.
- Hours 8–24: scope analysis based on logs, decisions on notifications (data protection authority? CERT? law enforcement? insurer?), preparing internal communication — employees must not learn about it from the media.
- Day 2: refining the scope, drafting the regulator notification and any notices to affected individuals, alignment with lawyers. If the scope is still uncertain — GDPR allows notification in phases (initial + supplement).
- Day 3: submitting the notification before the 72-hour deadline, publishing the statement (if required), opening a channel for questions from affected individuals.
The biggest enemy of this timeline is decision ambiguity: who is allowed to cut off a production system? Who approves the notification text? Those decisions must be made at the planning stage, not during the incident.
How you find out about a breach in the first place
In practice organisations learn about a breach in four ways, and each requires a different first step:
- Your own monitoring (EDR, SIEM, anomaly alerts) — the best scenario; what counts is the time from alert to response.
- An employee report — e.g. a clicked phishing link; this requires the no-blame culture we describe in phishing defence.
- Outside information — a customer, a security researcher, a CERT. Take every such report seriously and keep a publicly available security contact (e.g. security.txt).
- Publication by the attackers — the data appears on a forum or a ransomware group’s leak site. The worst variant: the GDPR clock is already ticking and you are only starting the analysis.
It’s also worth actively monitoring whether company data is circulating online: credential-leak notifications, monitoring of brand-impersonating domains and periodic checks of services like HIBP for company domains.
What it costs: numbers that convince the board
The average global cost of a data breach in IBM’s “Cost of a Data Breach 2025” study is USD 4.4 million, and detecting plus containing an incident takes on average over 240 days. Relevant for budgeting: organisations making heavy use of detection automation save on average more than USD 1.9 million per incident, and those with a rehearsed response plan shorten handling time by weeks. Regulatory fines (up to EUR 20 million or 4% of turnover under GDPR) are only part of the bill — downtime, customer churn and legal costs are usually more expensive.
Communication that doesn’t make things worse
How you communicate a breach can weigh on your reputation more than the incident itself. Customers and partners forgive far more when the message is honest, specific and tells them what to do. Silence, downplaying or — worst of all — denial that later turns out to be false destroys trust irreversibly.
It’s worth preparing message templates in advance, in calm conditions, and agreeing who decides on their publication and how.
Lessons after the incident
Every breach is an expensive lesson worth using. A post-mortem should answer the questions: how did the entry happen, why wasn’t it detected earlier and what changes will prevent a recurrence. Ideally it is run by someone not involved in handling the incident day-to-day — with a cool, outside perspective.
Prepare before you have to
The most important decision about a breach is made long before it: whether the organisation has a ready incident response plan, assigned roles, contact details and a rehearsed scenario. A plan that exists only on paper and has never been tested does not, in practice, exist.
Summary
An effective breach response is confirming the scope from logs, isolation rather than destroying evidence, meeting the 72-hour GDPR deadline and honest communication. All of this requires preparation in advance. If you’d like to build or test an incident response plan, get in touch — we’ll help you prepare before it’s needed.
Frequently asked questions (FAQ)
When does the 72-hour clock for notifying the regulator start? From “becoming aware” of the breach — the moment the controller knows with reasonable certainty that a personal data breach occurred, not from the attack itself nor from the first vague alert. You cannot, however, drag the analysis out indefinitely: the authority will assess whether verification proceeded without undue delay. An incident log with timestamps is the best evidence of diligence.
Does every breach have to be reported to the regulator? No. Notification is required for breaches likely to pose a risk to individuals’ rights and freedoms. If the risk is unlikely (e.g. leaked data that was effectively encrypted, with no key exposure), an entry in the internal breach register with a justification is enough. That assessment must be documented — “we didn’t report it because we didn’t feel like it” won’t survive an inspection.
Someone emailed us saying they found a vulnerability and our data. What now? Don’t ignore it and don’t threaten. Acknowledge receipt, verify the technical substance of the report, fix the vulnerability and secure the logs, and only then assess whether a notifiable breach occurred. A large share of reporters are good-faith researchers — a public security contact (security.txt) and a clear reporting path save a lot of nerves in such moments.
Is paying for “deletion” of stolen data worth it? There is no guarantee the data will actually be deleted — and paying does not lift your obligations towards the regulator and the affected individuals. Treat leaked data as permanently exposed and focus on limiting its usefulness: password resets, token revocation, fraud monitoring.
We have no security team. How do we prepare at minimal cost? Three elements give the best return: centralised logging of key systems (without logs you can’t establish the scope), a one-page response plan with roles and contacts (board, lawyer, IT, insurer, external DFIR support) and an annual tabletop exercise. We help build and rehearse this as part of our security support services.
