All guides

// guide

What happens in the first hour of a cyber incident?

Most of what determines what an incident will cost an organisation is settled in the first hour — before any specialist arrives, and usually by people doing exactly what seems sensible to them.

Why the first hour in particular

Two reasons, and both push the same way.

First: an attacker who is inside keeps moving. Every minute is another permission, another machine, another backup deleted. Early containment limits the scope; late containment deals with a much larger one.

Second, and less obvious: evidence decays. RAM is wiped on shutdown, logs roll over and overwrite, temporary files are cleared. What is not preserved in the first hour usually cannot be recovered later — and that is what decides whether you can state with certainty what was exposed, or only estimate.

Four mistakes that happen almost every time

Powering the machine off. It is the instinctive response, and it erases memory — exactly where the evidence of running processes, open connections and malware never written to disk lives. Disconnect it from the network instead; that stops the spread and keeps the evidence.

Restoring from backup immediately. A restore overwrites the state of the system, and if you do not know how the attacker got in, they will come back the same way — into a system that no longer holds the evidence to investigate.

Resetting every password at once. It sounds sensible, and in practice it tells the attacker they have been spotted before you have mapped the full extent of their access. They move to a route you have not found.

Discussing the incident inside the system you suspect. If corporate email is compromised, correspondence about the incident in that email is read by whoever compromised it.

What does help in the opening minutes

Isolate what is affected from the network, and leave it running.

Write down what was seen and when — the first symptom and the exact time. It is the one thing that cannot be reconstructed afterwards, and it is the starting point of every timeline.

Preserve logs, alerts and any ransom note exactly as they are, without editing or tidying.

Move to a communication channel that is not part of the suspected environment.

What is worth having ready beforehand

Who decides. An incident needs somebody authorised to approve taking a system offline, and at night it is not always clear who that is.

Who to call, and from what number. If the usual channel is suspect, there has to be an agreed alternative.

How long logs are retained. A log kept for seven days will not help with an incident that began three weeks ago, and this is usually discovered too late.

What has to work again first. That order of priority is settled far better when nothing is on fire.

Disconnect from the network, do not power off, and do not restore before you know how they got in.