The First Hour of an Incident Is Decided by What You Wrote Down in March

In the first hour of a real incident, nobody reads a document to learn how something works. Reading comprehension collapses under adrenaline and sleep debt, and the person holding the pager has no spare attention for a narrative. What they do instead is retrieve: a name, a number, a permission, a command, a threshold. If the retrieval takes more than about thirty seconds, they stop looking and guess.

That single behaviour determines what an incident response artefact should be. Not a procedure describing how to respond, which is what most organisations have written, but a set of facts that cannot be derived at speed. The difference sounds like editing. It is actually the difference between an hour spent containing something and an hour spent finding out who is allowed to authorise containment.

What actually gets consulted in hour one

Watch an incident and the pattern is consistent. Three kinds of question get asked, and only one of them can be answered by thinking harder.

Technical questions get answered by the responder. What is this process, where did this connection go, which account was used. These are skills, and a document adds nothing.

Situational questions get answered by looking. Which service is this host, what does it talk to, when did it last change. These need an inventory that is current, which is a data problem rather than a documentation problem.

Authority and obligation questions cannot be answered by either. Who can revoke this token at two in the morning. Who signs off on taking a customer-facing service offline. Which contract requires notification, to whom, within how many hours. Nobody derives these under pressure, and nobody has them memorised, and they are the questions that stall the first hour.

Question asked in hour one	Where the answer has to already exist	Cost when it does not
Who can revoke this credential right now	Named on-call owner per identity system, with a phone number	Twenty minutes of paging a rota to find someone awake with rights
Am I allowed to isolate this host	Standing containment authority, written and pre-approved	The host stays live while permission is sought upward
Where is the break-glass account	Location, custodian, and the process to use it	Response blocked by the exact access control designed to block attackers
Does this trigger a notification clock	Contract and regulatory obligation register per data class	A compliance failure discovered days later during the review
Who tells the customer, and what	Named comms owner and a holding statement	An engineer improvising a statement in a shared channel
What do we preserve before we act	Evidence order written per platform	Containment destroys the only record of how it started

Every row is a fact that was cheap to record on an ordinary Tuesday and expensive to establish at three in the morning. None of them are technical. That is the uncomfortable part: the first hour is usually lost to organisational facts, not to technical difficulty.

Prose fails at three in the morning

Most runbooks are written in paragraphs by someone who understands the system, for a reader assumed to be calm. The result is a document that is accurate, complete, and unusable at the moment it is needed, because retrieving one fact requires reading four paragraphs to locate it.

What survives contact with a tired responder has a specific shape.

1. One page per scenario, and the page starts with the first action, not with a description of the scenario. If the reader has to confirm they are in the right document before finding an instruction, the document is too slow.
2. Facts in tables and lists, never in sentences. A name, a number, a command, a threshold. Sentences are for the reasoning, and the reasoning belongs in a separate section that nobody reads during the incident and everybody reads during the review.
3. Commands written to be copied, with the placeholder fields obvious. A responder retyping a command from prose introduces errors nobody has time to debug.
4. Decision points stated as conditions with outcomes, not as guidance. If the condition holds, do this specific thing. Guidance defers a decision to the most pressured person in the room.
5. Every fact dated and owned. A phone number with no review date is a phone number nobody trusts, and an untrusted fact gets verified live, which costs the same as not having it.

The structural detail of a page built this way, including what to leave out, is set out in our guide to an incident response runbook that works at three in the morning. What that page is used for, minute by minute, is covered in our walkthrough of the first hour of a real incident.

Pre-authorisation is the highest-value thing you write

Of everything that goes in the file, the standing authority to contain is worth more than the rest combined, and it is the item most often missing.

The mechanism is straightforward. Decide in advance, in writing, which containment actions a responder may take without asking: isolating a host from the network, disabling a user account, revoking a session or token, blocking an outbound destination, suspending a build agent. Name the actions, name the roles who hold the authority, and name the conditions. Then say plainly which actions still require an escalation, so the responder knows immediately which category they are in.

Without this, the pattern is predictable. The responder sees active compromise, is unsure whether isolating a production host is their decision, and pages a manager. The manager wants to understand the impact before agreeing, which is reasonable and takes twenty minutes. The attacker has those twenty minutes.

The reason this is not written down is the same reason noisy alerts stay enabled. Whoever grants standing authority owns the outage if a responder isolates something important on a false positive. That is a real risk, and the answer is to bound it rather than avoid it: authority scoped to defined asset classes, with a requirement to notify immediately rather than to ask first. The judgement is made once, calmly, by someone with the standing to make it, instead of being pushed onto the least rested person in the organisation.

Keep it in version control, not in a wiki

The facts in these pages go stale silently. People change teams, escalation numbers change, a system is retired, an obligation register is updated after a new contract. A wiki page has no mechanism for noticing.

Treating the runbook the way you treat detection content solves most of this. Files in a repository, changes through review, an owner per file, and a scheduled check that the named people still work here and the commands still run. The discipline is identical to the one we describe in our guide on managing detection rules as code, and the payoff is the same: a change to a fact leaves a record of who changed it and when it was last verified.

The verification step is the one that matters. An untested runbook fact is a hypothesis. Calling the number, running the command, and confirming the person still holds the permission takes an hour a quarter and is the entire difference between a document and a functioning capability.

What to do next

Take the six rows in the table above and answer them for one real service this week. Not all services, one. Write the answers on a single page, put the page in a repository, and put a date and an owner at the top.

Then test one row by actually using it: ring the number, or run the isolation command in a maintenance window. Whatever fails is what would have failed at three in the morning. If you would rather work through containment authority and evidence order against your own environment before writing any of it, that is the work our threat detection and response practice does with clients.