The First Hour of a Cyber Attack: What to Do, and What Not To

Almost every incident we are called into has already been made harder by the response.

Not through negligence — through entirely reasonable instincts. Someone powered off the server.

Someone wiped and reissued the laptop to get the person working again. Someone deleted the

attacker's mailbox rules before recording them.

Here is the sequence that keeps your options open.

Do this

1. Disconnect, do not power off

Pull the network cable or disable Wi-Fi on affected machines. Leave them running. Volatile memory

frequently holds the evidence that explains what happened, and it is gone the moment the machine

powers down.

2. Reset passwords and revoke sessions

A password reset alone is not enough — existing session tokens keep working. Revoke sessions

explicitly for any account you suspect is compromised, starting with administrators.

3. Check for mailbox rules and forwarding

Record them before removing them. They tell you what the attacker was after.

4. Stop pending payments

Alert finance immediately. Invoice fraud frequently accompanies email compromise, and same-day bank

recall is sometimes possible where next-week recall is not.

5. Start a timeline

Write down what was noticed, when, and by whom, from this moment forward. It will be reconstructed

badly from memory a week later, and you will need it.

Do not do this

• Do not power off machines you may need evidence from
• Do not wipe, reimage or reissue suspect devices
• Do not delete mailboxes or accounts to "clean up"
• Do not restore from backup until you know when the compromise began
• Do not pay a ransom before taking advice
• Do not tell staff to say nothing — tell them who to report to instead

The 72-hour clock

If personal data is involved and the incident poses a risk to the people it relates to, you must

notify the Information Commissioner's Office within 72 hours of becoming aware of it. The clock

starts at awareness, not at the end of the investigation.

This surprises people, so it is worth being direct: a partial notification followed by an update is

the correct approach. A complete notification submitted on day nine is not. Where the risk to

individuals is high, you must also tell them without undue delay.

Even where the threshold is not met, record the incident internally with your reasoning. The ICO can

ask to see that record, and its absence looks considerably worse than a marginal decision not to

report.

Restoring safely

The instinct is to restore from backup as fast as possible. The risk is restoring the attacker along

with the data, or restoring onto systems they still control.

1. Establish when the compromise began, from evidence rather than assumption
2. Verify your backup pre-dates that point
3. Rebuild from known-good sources rather than cleaning infected systems
4. Rotate every credential, API key and certificate that was reachable
5. Close the weakness that allowed entry
6. Only then reconnect, with monitoring in place

Prepare before you need it

All of the above is dramatically easier when it is written down in advance. An incident response

plan names who decides what, lists the contacts you will need at six o'clock on a Friday, and sets

out the first-hour actions in a form somebody can follow under pressure.

Keep a copy offline. A plan stored on the file server that just got encrypted is not a plan.

If you are reading this during a live incident, stop and call +44 7424 967568. We triage the same

business day, and we will talk you through containment on the phone whether or not you become a

client.