Incident response

The first hour decides the year.

Incident handling, forensic preservation and investigation, followed by the account of what happened that a board, an insurer and a regulator will each want in a different shape.

ContainmentForensic preservationExecutive reporting
The expensive mistake

Most evidence is destroyed by people trying to help.

The instinct during an incident is to fix it. Machines get rebuilt, logs roll over, accounts get reset, and the answer to how the attacker got in disappears along with the problem. Then the question arrives anyway, weeks later, from somebody who needs a real answer.

Preserve before you repair

Containment and evidence capture are not in conflict, but only if the order is decided before the incident rather than during it.

Scope honestly

The first estimate of what was reached is almost always too small. We keep asking until the boundary stops moving.

Write it down as you go

The timeline built during the response is the one that holds up later. Reconstructing it from memory afterwards rarely survives scrutiny.

Before anything happens

The cheapest incident work is the readiness work.

Knowing who has authority to disconnect a production system, and having that agreed while everyone is calm, is worth more than any tooling decision.

We look at whether the logs you would need actually exist and for how long, whether the people named in the plan still work there, and whether anyone has tested the plan in a room rather than a document. Readiness work is unglamorous and it decides how the bad week goes.

An organisation is not judged on whether it had an incident. It is judged on whether it could explain one afterwards.

What you are left holding

During, and long after.

The technical response ends quickly. The explaining goes on for months, and most of what you need for it has to be captured while things are still moving.

01

Hands on it while it is happening

Containment and forensic preservation, with the decisions recorded as they are taken rather than remembered afterwards.

02

An investigation report

Entry point, scope, movement and what was reached, built on a timeline written during the response rather than reconstructed from memory.

03

The account other people will ask for

A version your board, your insurer and your regulator can each read, at the level of detail each of them actually needs.

04

The changes worth making first

What to fix so the same path does not work a second time, ordered by what would have made the most difference.

Questions we get asked

Before you get in touch

The questions that come up most often, answered the way we would answer them on a call.

Something is happening right now. How fast can you engage?

Get in touch and say that plainly in the first line. Live incidents are triaged ahead of everything else, and the first conversation is about preservation and containment rather than paperwork.

What should we do before you arrive?

Stop changing things if you safely can. The instinct is to rebuild the host or reset the account, and both destroy the answer to how it started. Preserve first, and write down what you have already done.

Will this be usable by our insurer or regulator?

That is what the reporting is designed for. The timeline is built during the response rather than reconstructed afterwards, which is the difference between an account that holds up and one that gets questioned.

Can you help us prepare instead?

Yes, and it is considerably cheaper. Readiness work is mostly about deciding who has authority to do what, checking the logs you would need actually exist, and testing that the plan names people who still work there.

Dealing with something now, or preparing for it?

Both are worth a conversation, and the second one is considerably cheaper than the first.