Incident response plans have a bad reputation, and it is deserved. Most are long, generic, written to satisfy a questionnaire, and never opened again. During an actual incident nobody reads them, because at that moment people need a phone number and a decision, not a document with a revision history.
A useful plan is short and specific. It answers the questions people will actually ask in the first thirty minutes, and it survives the fact that the person reading it is tired, alarmed and possibly locked out of the systems the plan refers to.
The five things it must contain
1. Who to call, with phone numbers
Not roles. Not email addresses. Names and mobile numbers, for the two or three people who need to know immediately.
Email is the wrong channel for this and it is the one most plans use. It is slow, it is often the system affected, and during a credential compromise it is the channel you least want to trust. A plan whose escalation path runs through the potentially compromised mail system has a circular dependency in it.
This is the field that most often sits empty, and it is the field the whole document exists to fill.
2. What counts as an incident, and who says so
Two or three severity levels, described by consequence rather than technicality:
- High: customer data may have been accessed, or the service is down for everyone.
- Medium: a security control has failed but there is no evidence of access, or a subset of customers is affected.
- Low: something looks wrong and needs investigating.
Then say plainly who can declare one. The correct answer for a small team is anyone. Make it explicit, because the expensive failure is a junior person spending an hour deciding whether something is worth bothering anyone about.
3. The first three actions
Not a methodology. Three things to do in the first ten minutes:
- Write down the time and what you saw. Start a running log immediately, in a document with a timestamp on every line. You will not reconstruct this afterwards, and it is what you will need for the post-incident review and any notification.
- Contain, but preserve. Revoke the credential, take the endpoint offline, disable the account. Do not delete anything, do not rebuild the server yet. Evidence destroyed in the first ten minutes cannot be recovered later.
- Tell the person named in step one.
The tension between containing and preserving is the part worth spelling out, because the instinct under pressure is to make the problem disappear, and that instinct destroys the ability to know what happened.
4. Who tells customers, and roughly what they say
Decide now, calmly, who has authority to communicate externally. During an incident this question produces paralysis or, worse, several people saying different things in different channels.
A short holding statement drafted in advance is worth more than a communications policy. Something like: we are aware of an issue affecting X, we are investigating, we will update by a stated time. Having that ready removes the hardest thirty minutes of writing from the worst possible moment.
5. Who to call outside the company
Names and numbers for whoever you would need: your hosting provider's support path, your legal advisor, your insurer if you have cyber cover, and your most significant customers' security contacts if your contracts specify notification timelines.
Find out what those timelines are before you need them. Contracts commonly specify a notification window measured in hours, and reading the contract during the incident is not the moment.
What auditors actually look for
Three things, and existence is only the first.
That it exists and names people. A plan with role titles and no names reads as a template someone downloaded.
That it has been rehearsed. A dated note saying the team walked through a scenario for forty-five minutes carries more weight than twenty extra pages. Rehearsal is what distinguishes a plan from a document.
That it has been used, or at least reviewed, recently. A plan last touched three years ago describes a company that no longer exists.
Rehearsing it in forty-five minutes
You do not need a formal exercise. Get the team in a room, or a call, and pick a scenario: an API key has been found in a public repository and has been used from an address nobody recognises.
Then walk it. Who noticed? What is the first action? Who is called? Who can revoke that key, and do they have access right now? What do we tell customers, and who writes it?
The value is entirely in what you discover. The common findings are consistent across teams: nobody knows who can revoke the key at the weekend, the contact list is out of date, nobody has ever checked whether the provider logs key usage, and there is no agreement on what threshold triggers telling customers.
Each of those is a fix worth making, and none of them would have surfaced by rereading the document.
The severity call, and why people get it wrong
The hardest judgement in a live incident is whether customer data was actually accessed or merely could have been. Those lead to very different obligations, and the distinction is often unclear for hours.
The plan should say what to do while it is unclear, because the default is paralysis. A workable rule: act as though it happened, communicate as though it is unconfirmed. Contain fully, preserve everything, tell the people internally who need to know, and do not tell customers something definite until you can support it.
The related trap is a premature all-clear. Saying "no data was accessed" three hours in, then revising it two days later, damages trust far more than saying "we do not yet know" would have. Write that into the plan as a rule rather than leaving it to whoever is drafting under pressure.
It is also worth noting in the plan which evidence sources answer this question, and whether you actually have them. Access logs that pair the authenticated user with the resource requested will tell you; logs that record only the request path will not. Discovering that during an incident is too late, and it is the kind of thing a rehearsal surfaces cheaply.
Where the plan should live
This sounds trivial and defeats more plans than any drafting problem.
If the plan is in a wiki behind the single sign-on that is currently compromised, or on a laptop that is part of the incident, it does not exist. It needs to be reachable when things are broken.
The practical answer for a small team: a shared document everyone can reach, plus a PDF in everyone's password manager, plus a printed copy in a drawer if you have an office. That sounds excessive until the afternoon the identity provider is the thing that failed.
Keeping it short enough to use
The operational part, contacts, severity, first actions, communications, should be one page. Everything else is an appendix.
A good test: hand it to someone who was not involved in writing it and ask them to find the number they would call at 3am. If that takes more than ten seconds, the layout is wrong regardless of how good the content is.
Our incident response plan builder produces exactly this shape from a dozen questions, in the browser, with nothing uploaded. It is not a substitute for the thinking, and it does get the structure right and saves the blank-page problem.
The honest summary
Most teams either have no plan or have one nobody would use. The gap between those two states and a genuinely useful plan is about an hour of writing and forty-five minutes of walking through a scenario.
Start with the phone numbers. If you write nothing else today, write down who gets called and on what number, and put it somewhere reachable when the systems are not.