Hour by hour: what to do and what to avoid from discovery to regulatory notification, and why preserving evidence is the most important early decision.
The first hours of an incident shape its outcome disproportionately. Not because that is when the attacker can be stopped (they have typically been inside for weeks), but because decisions are taken then that cannot be undone later: whether evidence survives, whether you will ever know how they got in, and whether you meet statutory deadlines.
This article runs in chronological order.
What to do immediately:
Record the time and how it came to light. This is the first line of the log, and both the investigation and the authority will ask for it later.
Convene a small group. Not the whole of IT: one decision-maker, one systems administrator, one communications lead. A crowded war room slows the first hours rather than speeding them.
What not to do:
Do not power off machines. This is the single most common and most costly mistake. Traces in memory (running processes, network connections, sometimes the encryption key itself) are permanently lost on shutdown. Disconnect from the network, yes; cut the power, no.
Do not start rebuilding. The "restore quickly and move on" reflex is understandable, but if it overwrites evidence you will never learn the entry point. Whoever does not know how they got in will be attacked the same way again.
Do not communicate on the compromised channel. If email or chat may be affected, the attacker is reading your response planning. Move to a separate channel (phone, an application on a separate device).
Now you decide how far the damage extends and what can safely be disconnected.
Scope assessment. How many systems are affected? Which accounts are compromised? Is there evidence of exfiltration (large outbound traffic to unknown destinations)? The state of domain controllers and backup infrastructure is a separate question.
Proportionate containment. Disconnection is not the default answer. In IT environments segments can be isolated relatively quickly. In industrial environments this can halt production or compromise process safety, so the decision must be made jointly with operations against pre-defined criteria. Safety systems (SIS) are not touched in the name of incident response.
Credentials. Where domain compromise is suspected, rotating key account passwords is urgent. At the same time, a hasty rotation can tell the attacker they have been noticed. This is a judgement call, usually best made together with the specialist you bring in.
Log collection. Firewall, domain controller, endpoint protection, VPN, mail, cloud services. Copy these immediately: logs typically rotate with short retention, and it is precisely the relevant part that gets lost.
Engaging a specialist. If there is no in-house incident response capacity, this is the decision point. The later help is called, the less evidence remains.
Insurance. If cyber insurance is in place, the notification deadline is often very short, and insurers frequently specify which responders may be engaged. Check this in the first hours, not the second week.
Legal and communications preparation. Who may speak? What is said to customers who ask? Silence is also a decision, and it is better made consciously.
This is where statutory deadlines start to bite.
| Obligation | Deadline | When it applies |
|---|---|---|
| NIS2 early warning | 24 hours | If the organisation is in NIS2 scope and the incident is significant |
| GDPR personal data breach | 72 hours | If personal data is affected and poses a risk |
| Cyber insurance | per policy, often 24 to 48 hours | If insured |
| Customer contracts | per contract | Often 24 hours, worth reviewing |
The NIS2 early warning requires less than many assume: it is enough to state that a significant incident is suspected, whether it appears to be caused by unlawful acts, and whether cross-border impact is possible. No full analysis is needed. The 72-hour notification and the one-month final report follow.
The most common mistake is delaying in the hope of "clarifying what happened first". The clock starts from suspicion, not from complete investigation.
The first 24 hours work only if you are not inventing them at the time. Four things worth preparing, each about half a day of work:
1. Contact list. Who is the decision-maker, who is legal, who is communications, contact details for the external specialist and the insurer. On paper too, because systems may be unavailable.
2. Notification templates. A skeleton for the NIS2 early warning and the GDPR notification. For an incident starting at a weekend this saves hours.
3. Escalation criteria. From what point is an incident "significant"? Who can authorise a shutdown? In OT, who approves isolating a segment?
4. Evidence preservation instruction. A single page on what must not be done. The on-call administrator will read this at three in the morning, so keep it short.
The plan is worth running through every six months. A two-hour tabletop where management and IT walk a scenario together is worth more than any document. The exercise always surfaces the same gaps: somebody's phone number is missing, nobody knows who decides, and it emerges that restoration takes three times as long as the business assumed.
We covered that last point in detail in our backup strategy article, and the ransomware-specific steps in ransomware defence.
If you want to build or test incident response capability, our IT security services and OT incident response both cover this.
Comprehensive IT security services including firewalls, WAF, IPS, SIEM, DLP and endpoint protection from…
How a modern ransomware attack actually unfolds, which controls genuinely stop it, and what to do in the…
A practical NIS2 checklist: determining whether you are in scope, the ten mandatory measures, incident…
Our specialists are happy to discuss what this means in your organisation's environment.