Almost every organisation has an incident response plan. A meaningful fraction have never once run it. The plan is a document that was written to pass an audit, filed, and not opened since, and the first time anyone reads it properly is at the worst possible moment, with production down and a clock running. The gap between having a plan and having practised it is where the first hour of a real incident is won or lost.
This is about that first hour specifically, because it is disproportionately important. The decisions made in the first sixty minutes, who is in charge, whether to contain or observe, when the regulatory clock started, shape everything that follows. Get them right and a bad day stays a bad day. Get them wrong and you destroy the evidence, miss the disclosure deadline, or spend the hour with ten people improvising in a group chat.
Declaring it, which is harder than it sounds
The first failure is often the simplest: nobody actually declares an incident. An alert fires, an engineer starts poking at it, a second engineer joins, an hour passes, and it is still being treated as a curious technical problem rather than a security incident with a process attached. The transition from "something is odd" to "this is an incident, we are running the plan" needs to be an explicit act performed by a named person, because until it happens, none of the rest of the machinery starts.
So the first thing your plan needs is unglamorous: a clear answer to who can declare an incident, and permission for them to do it on incomplete information. The instinct to wait until you are certain is the enemy here. Declaring an incident and standing it down twenty minutes later because it was benign costs almost nothing. Failing to declare for an hour because nobody felt authorised costs you the hour, which is the one part of an incident you can never get back.
Declaring it also starts the clock, and there is more than one clock. There is your own response timeline, and there is the regulatory one, which may have started at the moment of detection rather than when you finish cleaning up. That distinction is why declaration is not just an internal nicety.
The two decisions that dominate the hour
Containment without destroying the evidence
The instinct when you find a compromised machine is to pull it off the network, or worse, to shut it down. Isolation is usually right. Shutting down is often wrong, because a powered-off machine loses everything that was in memory, and memory is frequently where the most useful evidence of a live intrusion lives. Rebooting, re-imaging, or hastily cleaning a box can wipe the very logs and artefacts you will need to understand what happened and to prove what did and did not leave.
The discipline is to contain in a way that stops the spread while preserving the state. Isolate the host at the network level rather than powering it off. Capture volatile data before you change anything. Take images before you remediate. This is the moment where the interests of getting back to normal and understanding what happened pull against each other, and in the first hour, preservation usually has to win, because you can restore service from a preserved system but you cannot recover evidence you have already destroyed.
The disclosure clock you may not know is running
This is the decision most technical teams underweight, and it connects directly to the accountability shift I have written about in the context of the modern CISO role. Regulatory reporting obligations increasingly start at the point of detection or determination, not at the point of resolution. That means the first hour is not only a technical event, it is potentially the start of a legally significant countdown, and the people who understand those obligations, legal and communications, need to be in the room from the beginning rather than discovering three days later that a deadline passed on day one.
You do not need to have disclosed anything in the first hour. You need to know, in the first hour, that the clock exists and when it started, so that the disclosure decision is made deliberately and on time rather than missed. An organisation that treats disclosure as a thing to worry about once the technical work is done has already taken on avoidable regulatory and reputational risk.
What makes the first hour survivable
Everything that makes the first hour go well is prepared before it starts. Five things in particular.
| Element | What it means in practice |
|---|---|
| Roles and authority | A named incident lead, and explicit answers to who may take a system offline and who is allowed to speak externally. |
| Communications | An internal bridge that everyone knows to join, a pre-drafted holding statement, and legal and comms engaged from the start. |
| Evidence | The habit of preserving logs and images and keeping a timeline from the first minute, not reconstructing it afterwards. |
| Decision rules | The ransomware stance and escalation thresholds agreed in advance, so the hard calls are policy, not improvisation. |
| The retainer | An incident response firm contracted before you need them, so hour one is a phone call, not a procurement exercise. |
That last row deserves emphasis because it is the one organisations most often skip and most regret. Sourcing an incident response firm during an incident means negotiating a contract while under attack, which is slow, expensive and weak. A retainer arranged in advance turns the worst hour into a single phone call to people who already know your environment and can start immediately. It is cheap insurance against the most expensive kind of delay.
The thing that actually makes this work
All of the above is necessary and none of it is sufficient, because a plan that has only ever been read is not a capability. The single highest-value thing an organisation can do for its incident response is to run the plan as a drill before a real incident forces it. A tabletop exercise, where the leadership and technical teams walk through a realistic scenario and actually make the decisions, surfaces every gap the document hides: the authority nobody has, the contact detail that is out of date, the assumption that someone else was handling comms.
The first time you run your plan should not be the day it broke. It should be a Tuesday afternoon in a meeting room, with coffee, where the cost of discovering that no one is sure who can declare an incident is a slightly awkward conversation rather than a lost hour during a live breach. Organisations that drill are visibly calmer and faster when the real thing happens, and the difference is almost entirely in that first hour.
The honest summary
The first hour of an incident is decided long before the incident, by whether the plan is a document or a practised drill. The declaration has to happen and someone has to be authorised to make it. Containment has to stop the spread without destroying the evidence. The disclosure clock has to be understood while it is still early enough to matter. And the roles, the comms, the decision rules and the retainer all have to exist before the alert fires, because the first hour is not when you build them, it is when you find out whether you did.
If you do one thing after reading this, book a tabletop exercise. Not a plan review, a drill, where real people make the real decisions against a real scenario. It is the cheapest way to find your gaps while finding them is still free.
If you want help building an incident response capability that holds up in the first hour, or running the tabletop that tests it, that is the kind of work I do through Cyber Spartans.