Plenty of organisations know they have a breach notification obligation. Far fewer are in a position to meet it.
The difference comes down to one thing: the clock starts the moment you learn of the breach, and by then there is no time left to prepare.
Where the hours go
In an unprepared organisation the sequence typically runs like this:
| Hour | What actually happens |
|---|---|
| 0–6 | Debate over whether this is really a breach. Nobody is clearly the decision-maker. |
| 6–18 | Hunting for logs. Discovering some were never collected. |
| 18–36 | Trying to establish scope: what data, how many people, what date range. |
| 36–60 | Legal and management step in; the notification wording is debated. |
| 60–72 | A notification is assembled in a hurry, with incomplete information. |
Actual technical investigation in that sequence gets a few hours. The rest is organisational delay — and all of it can be removed in advance.
Four things to settle before the clock starts
1. Who decides
Who determines whether an event counts as a breach must be written down in advance, along with who takes over if that person is unreachable. Where the decision-maker is unclear, the first hours go to debate.
2. Where the evidence comes from
The sources needed for an investigation must already exist at the moment of the breach:
- Authentication and authorisation logs
- Database access logs
- Web server access logs
- Endpoint telemetry
- Network flow records
How far back they reach matters just as much. If the attacker got in three months ago and your logs are kept for two weeks, you cannot establish scope — and when you cannot establish scope, you have to assume the worst case.
3. What the notification will say
The information a notification must carry is known: the nature of the breach, the approximate number of people and records affected, its likely consequences, and the measures taken and planned.
A template for those headings can be prepared in advance. Text first drafted during a breach is not good text.
4. Who investigates
If the organisation has no forensic capability in-house, the external firm must be selected in advance with a contract already in place. Sourcing a supplier and negotiating terms on the day consumes half the window.
The most expensive mistake: destroying the evidence
In unprepared organisations the first reflex is usually to restore service fast: the affected server is rebuilt, disks are wiped, the service is restarted.
The consequence is that you will never learn what happened. Evidence in memory is lost, deleted files are overwritten, the attacker’s traces disappear. Unable to establish scope, you end up writing “the number of affected individuals could not be determined” — which is itself read as evidence of inadequate measures.
The correct order is: image first, then respond. No system should be rebuilt before disk and memory images are taken. This belongs as the first line of the incident response plan.
The ransomware case
Most ransomware operations now exfiltrate data before encrypting it. The incident is therefore not only an availability problem but a probable confidentiality breach.
The practical consequence: work on the assumption of exfiltration until proven otherwise. A judgement of “it was only encrypted, nothing left” cannot be made without examining outbound network traffic.
Testing the plan
A response plan that has been written but never exercised is only slightly better than none. A table-top exercise closes that gap: a scenario is given, the team walks through what it would do, and the gaps surface.
Typical findings from an exercise: the decision-maker was in fact undefined, a critical system logs nothing, restoring from backup takes three times the estimate, two people on the contact list have left.
Learning those things on the day of a breach is expensive.
Building the capability
Incident response is not something to improvise. Team, process and tooling have to be in place beforehand.
normSight’s CSIRT / Incident Response training targets exactly this: establishing the response process, detection, containment and safe recovery. For the evidence side see Digital Forensics, and for proactively hunting undetected adversaries, Cyber Threat Hunting.
The wider set of compliance obligations is covered in KVKK compliance.
This article is general information and does not constitute legal advice. For notification deadlines, content and recipients specific to your organisation, consult your legal counsel.
- data breach
- incident response
- KVKK
- CSIRT