The fifty-page version is for the auditor. The version people use at 7am is short, printed, and decides who gets to say the word "incident".
There is a particular silence that happens in the first twenty minutes of a real incident. Something is clearly wrong, several people have noticed, nobody has said out loud that this is now An Incident, and so nobody is doing the things the plan describes, because the plan has not been invoked.
That silence is what an incident response plan exists to prevent. Most of them do not, because they were written to satisfy a requirement rather than to be read under pressure.
The decision that has to be made first
Before any technical content: one named person has the authority to declare an incident, and one named deputy has it when they are unreachable.
That is the single most load-bearing sentence in the document. Without it, the first forty minutes go into a group chat where everyone is waiting for somebody more senior to make it official.
Give that person a low threshold and explicit cover for being wrong. Declaring an incident that turns out to be a misconfigured firewall rule costs an hour of several people's time. Not declaring one that turns out to be ransomware costs considerably more. Say so in the document, so the person holding the pager knows they will not be criticised for a false alarm.
The first hour
The step people get wrong is the third one. The instinct on finding a compromised machine is to clean it: remove the malware, reset the password, get the user working again. That instinct destroys the evidence needed to answer the question everyone will ask next, which is what else was touched.
Isolate rather than clean. Disconnect from the network, leave it powered on if you can, disable the account, revoke active sessions, and preserve logs before anything rotates them out. You can always clean later. You cannot un-destroy a timeline.
The fourth step matters more than it looks. A contemporaneous log of decisions and times is what your insurer, your lawyer and possibly a regulator will work from months later. Memory at that distance is unreliable and known to be unreliable. One person, writing things down as they happen, in a document that is not on the affected system.
Who does what
In a small organisation one person will hold two of these. That is fine. What does not work is the incident lead also being the person doing the technical work, because the two jobs compete: the technical work is absorbing, and the lead's job is to keep looking up.
The role most often missing is spend authority. At 11pm, somebody may need to engage a specialist firm at a rate nobody has approved. If that decision has to wait for a finance process, you lose the night. Name the person, name the limit.
Build the contact list before you need it
Four categories, with numbers that have been dialled at least once:
- Internal: the roles above, with mobile numbers and deputies.
- Provider: your IT provider's escalation path, including out of hours, and your account reference.
- Specialists: incident response firm, legal counsel, and your insurer's notification line. Check the insurer's requirements now: many policies require notification within a set period and some require you to use their panel firms, and discovering that at 2am can void cover.
- Obligations: regulator contacts for the regimes you fall under, and the deadlines attached.
Keep this list somewhere reachable when your systems are not. Printed, and in someone's wallet or glovebox.
Agree the out-of-band channel today
If the incident is in Microsoft 365 and your email and chat are Microsoft 365, you need somewhere else to coordinate, and the middle of an incident is not when to choose it.
Agree a specific alternative. A group on a separate messaging platform, a conference bridge with a dial-in that does not depend on your identity provider, or simply a phone tree. Test it once a year by using it for a scheduled meeting. If it has never been used, it will not work.
The four pages
One. Declaration and roles. Who declares, who deputises, the named roles, and the explicit statement that declaring in error is acceptable.
Two. The first hour. The four steps, with the specific actions for your environment: how to isolate a device, how to disable an account and revoke sessions, where the logs are and how long they are kept.
Three. Contacts. The four categories above, with numbers.
Four. Notification. Who must be told, within what time, and by whom. Insurer, regulator, affected clients, staff. Include the drafts, written on a calm day.
Everything else, the asset inventory, the detailed playbooks, the policy framing, belongs in a separate longer document that nobody reads during an incident and that is entirely appropriate to have.
Exercise it, briefly
An hour, twice a year, with a scenario and the people named in the plan. Not a technical exercise: a decision exercise. Read out a scenario, have each person say what they would do and who they would call, and write down every point where the answer was "I would ask someone".
The first time you do this, expect it to go badly. That is the value. The second time, which is a year later, it will go noticeably better, and you will have found out whether the phone numbers still work.
One thing to check this week
Call your insurance broker and ask what your policy requires of you after an incident: how fast you must notify, whether you must use their panel, and what you must preserve. Then put the answer on page four. More cover is lost to process failures in the first day than to anything else.
