The incident you will actually have

Read most incident response plans and you will find them written for a particular kind of event. An intrusion is detected. A team assembles. Containment begins. Communications go out on a schedule. Everything has a phase, and the phases arrive in order.

Real incidents almost never behave like that, and the difference is where the plan quietly fails.

What actually happens

It usually starts with something ambiguous. A finance colleague mentions that a supplier's bank details changed and it felt slightly off. A monitoring alert fires that has fired before and been nothing. Somebody notices a login from a country where you have no staff, at a time that is not quite odd enough to act on alone.

Nobody knows yet whether this is an incident. That is the defining feature of the first hour, and it is the part most plans skip entirely. They begin at the point where someone has already declared it, which is precisely the decision that is hardest to make.

So the first thing worth writing down is not the containment procedure. It is who can declare, on what evidence, and what happens if they are wrong.

Make it safe to be wrong about calling an incident. A team that fears overreacting will always underreact, and the second mistake is far more expensive than the first.

The three things that decide how the week goes

Whether anyone preserved anything. The instinct under pressure is to fix it. Rebuild the host, reset the account, restore the service. Every one of those actions is reasonable and every one destroys the answer to how it started. Weeks later, when an insurer or a regulator asks for scope, you will either have an image or you will have a theory.

Agree now, while nothing is burning, who has the authority to take a copy before a rebuild. One decision, made in advance, made once.

Whether the logs you need still exist. Every organisation discovers its real retention period during an incident. The system you most need to look at is usually the one keeping seven days, and the activity you care about was eleven days ago. Find that out this month instead.

Whether the plan names people who still work there. Plans age badly and silently. Read yours as though tonight were the night, and check every name, every number, every system reference, and every external contact. It takes an afternoon.

Being able to explain it afterwards

The technical response ends long before the incident does. What follows is months of explaining, to a board, an insurer, a regulator, a customer, and sometimes all four with different levels of detail and different tolerances for uncertainty.

The single most useful artefact in that period is a timeline that was written as things happened rather than reconstructed afterwards from memory and chat history. Somebody should be keeping it from the first hour, and it does not need to be elegant. Time, what we saw, what we did, who decided.

The NIST guide to computer security incident handling remains the most practical public structure for this, and MITRE ATT&CK gives you a shared vocabulary for describing what happened that other people will already understand. Where reporting obligations apply, knowing the clock before it starts matters, and CISA publishes clear material on what that involves.

The rehearsal that is worth an afternoon

Forget the full simulation for a moment. Run the small version.

Get five people in a room. Describe an ambiguous signal, of the kind that would genuinely arrive on a Tuesday. Then ask three questions and time the answers.

Who decides this is an incident. What is the first thing we preserve, and who does it. Who makes the call to take a production system offline, and what do we do if that person is unreachable.

If those answers come quickly and agree with each other, your readiness is real. If the room goes quiet, you have just found the gap at the cheapest moment you will ever find it.

The point

We run DFIR engagements and the pattern holds almost every time. The organisations that come through well are rarely the ones with the most sophisticated tooling. They are the ones where a handful of decisions had already been made, calmly, months earlier, by people who took an afternoon to think about it.

That afternoon is the highest return investment available in incident response, and it does not appear on anybody's budget line.

Common questions

What should you do first in a security incident

Decide whether it is one, and preserve before you repair. The instinct is to rebuild the host or reset the account, and both destroy the answer to how it started. Agree in advance who has authority to take an image before anybody rebuilds.

Who should declare a security incident

Somebody named in advance, on evidence agreed in advance, and it has to be safe for them to be wrong. A team that fears overreacting will always underreact, and the second mistake is considerably more expensive than the first.

Why do incident response plans fail

They are usually written for a dramatic confirmed breach and begin after the declaration, which skips the hardest decision in the sequence. They also age silently, naming people who have left and systems that have been replaced.

How do we prepare for an incident cheaply

Get five people in a room for ninety minutes with an ambiguous scenario. Ask who declares it, what gets preserved first and who can take production offline. The silence in that room is the finding, and it is the cheapest one you will ever get.