In a data breach, the costliest mistake is often not the breach itself. Missing the notification window turns a technically minor event into an administrative problem — and that transformation happens within hours.
Short answer: what must I do in a data breach?
On learning that personal data has been unlawfully obtained by others, you as data controller must notify the supervisory authority without undue delay — in practice within 72 hours — and inform affected individuals as soon as reasonably possible. The clock starts not when the breach occurred but when it was discovered. The most common cause of delay is not bad faith but uncertainty over who decides — which is why the real preparation is an incident plan written before anything happens.
What counts as a breach and what does not
| Situation | Breach? | Why |
|---|---|---|
| A file containing a customer list leaks | Yes | Obtained by unauthorised parties |
| An e-mail account is compromised | Yes | Grants access to personal data in correspondence |
| Data encrypted by ransomware | Usually yes | Loss of availability plus possible exfiltration |
| Bulk e-mail exposing all recipients to each other | Yes | Unauthorised disclosure of addresses |
| A disk fails but a backup exists | No | No loss, no disclosure |
| An encrypted backup is lost (key secure) | Assessment-dependent | Whether the data is readable decides |
The essence: not every security incident is a data breach, but every data breach is a security incident. What decides is whether personal data was obtained, altered or rendered inaccessible without authorisation. Where there is doubt, record the assessment; how you concluded "not a breach" must also be documented.
A 72-hour timeline
| Time | Action | Owner |
|---|---|---|
| 0–1 hour | Confirm the event, isolate the affected system, preserve logs | Systems lead |
| 1–4 hours | Determine scope: which data, how many people, what period | Systems + data owner |
| 4–12 hours | Revoke access, rotate passwords and keys, close the flaw | Systems lead |
| 12–24 hours | Legal assessment: does a notification duty arise? | Legal adviser |
| 24–72 hours | Notify the authority, inform affected individuals, complete the internal report | Data controller |
| After 72 hours | Root cause analysis, preventive action plan, archive records | Management |
In practice, most time is lost at the second stage: scope determination. Establishing quickly which data was affected is only possible where a data inventory already exists. Businesses without one spend the first 24 hours asking "what did we lose" while the clock keeps running.
Who is notified, and how?
- The supervisory authority. Through the prescribed form. Where details are still unclear, prefer phased notification to delay: report what is known and update as gaps close.
- Affected individuals. Inform them as soon as reasonably possible, in plain language. The notice should cover the nature of the breach, likely consequences, measures taken, and steps individuals can take themselves.
- Partners and processors. If the breach happened at a service provider, contractual notification duties apply. In the reverse case, you must inform them.
- Internal record. Every breach must be recorded internally whether or not it is notified. That record is usually the first thing an audit asks for.
Two mistakes to avoid in the notice: understating the event, and drowning it in technical detail without telling the individual what to do. The purpose of the notice is enabling affected people to protect themselves.
An incident plan template
- Definition: what counts as a breach for us, which events trigger this plan.
- First 60 minutes: who to call, which system to isolate, which records to preserve.
- Decision authority: who decides on notification, and who deputises.
- Scope questions: which data, how many people, what date range, which systems.
- Communication templates: ready drafts for the authority and for affected individuals.
- External parties: legal, hosting provider, bank, insurer — with phone numbers.
- Closure criterion: when the incident is considered closed, and who writes the root cause report.
The plan's most valuable property is not its content but that it was written before the event. A plan written during a crisis is not a plan but improvisation.
Netişlem expert view: delay comes from a decision gap, not a technical one
In the incidents we examine, most notification delays have no technical cause. The event is noticed, but a full day disappears into "does this require notification", "who decides", "should we ask a lawyer". Those answers can be written on one page beforehand. Where decision authority is defined, the same event becomes a manageable process within hours.
Our second observation is the decisive role of the data inventory. A business that knows which personal data sits in which system establishes scope in hours; one that does not searches for days. The inventory is less a compliance document than a crisis instrument — as we noted in our compliance audit article.
Third, record-keeping matters. Even for events not notified, there must be a written answer to "why not". Where the assessment itself is documented, a later audit stays on technical ground; without it, the appearance is one of neglect.
Checklist
- Personal data inventory current — which data, which system, on what legal basis.
- Breach definition and triggering events written down.
- Decision authority and deputy identified.
- First-60-minute steps written and accessible.
- Notification templates prepared in advance.
- Notification windows defined in provider contracts.
- A method for preserving logs and records defined (for evidential value).
- Restore time from backup known — see backup and disaster recovery.
- An internal breach register maintained.
- A tabletop exercise run annually.
Frequently asked questions
When does the 72 hours start?
Not when the breach occurred but when the controller became aware of it. Awareness follows reasonable verification, though stretching verification unnecessarily can itself count as delay. Timestamped records of the first hours' actions therefore matter.
Should I notify if few people are affected?
The duty is assessed by the nature of the breach and its likely consequences rather than headcount. A breach affecting few people but involving sensitive data can carry heavier consequences than a routine one affecting many.
The data was encrypted — is it still a breach?
Encryption markedly reduces risk because the data is unreadable, and it affects the assessment. But it provides no protection if the key was also obtained or the method was inadequate. What decides is whether the data is in fact readable.
If the breach happened at a supplier, who is responsible?
Where you remain the data controller, the notification duty generally remains yours. Provider contracts should therefore state notification windows and cooperation duties in writing — see supply chain risk.
Does notifying guarantee a penalty?
No. Notification is compliance with a duty and is generally treated as a favourable factor. The real risk lies in failing to notify or notifying late, which raises both the breach and a breach of duty.
Is all this structure necessary for a small business?
The structure scales, but three elements are needed regardless of size: a data inventory, a defined decision-maker, and a one-page plan. Together they amount to about half a day of preparation.
Conclusion
What decides breach management is not technical capacity but decisions taken in advance. Where it is already written who decides, where the data sits and who must be told when, 72 hours is ample. Where it is not, the same window is barely enough to start asking questions.
If you would like help preparing your incident response plan, get in touch. You can review our corporate backup and secure hosting solutions.