An incident response playbook is the written procedure that states, step by step, what is done when a specific type of incident occurs: who acts, in what order, with what permissions, who is notified and when. It is not a strategy document. It is an operational guide that someone has to be able to open at 3 a.m., tired and under pressure, and execute without having to decide anything that had already been decided.
The difference between a company that contains an incident in twenty minutes and one that takes two days is almost never the tool. It is whether someone wrote this down beforehand.
I see it often in first meetings: the company has an EDR properly configured, it has alerts, it even has contracted monitoring. And when I ask what exactly happens when that alert goes off on a Saturday, the answer is a list of names and a WhatsApp group. That is not a playbook.
What exactly does a playbook contain?
A useful playbook is short and boring. If it runs forty pages, nobody is going to read it during an incident. These are the parts that cannot be missing:
- Trigger. What specific signal activates this playbook. Not “suspicious activity,” but something verifiable: mass file encryption on a server, a valid sign-in from a country where there are no operations, an email with an attachment that two users have already opened.
- Classification and severity. How to decide whether this is a critical incident or a nuisance, with written criteria. This part avoids the most expensive discussion of all: whether someone needs to be woken up or not.
- Roles. Who leads the incident, who executes on the systems, who talks to the business, who documents. A single decision owner per incident, always.
- Containment steps. The technical actions in order, with enough detail to execute them: what gets isolated, what gets disabled, which credentials are rotated and in what sequence.
- Prior authority. What the analyst is authorized to do without asking permission, and what requires human approval. It is the most frequently forgotten part and the one that costs the most time when it is missing.
- Evidence. What is preserved before touching anything, because some actions erase exactly what is needed later to understand what happened.
- Communication. Who is notified, when, through which channel and with what message. Including the alternate channel, for the scenario in which corporate email is precisely what has been compromised.
- Closure and lessons learned. What conditions must be met to declare the incident closed, and what is reviewed afterward.
The reference framework behind all of this is the NIST SP 800-61 Revision 3 guide, published in 2025, which reorganized incident response around the functions of the cybersecurity framework: identify, protect, detect, respond and recover. And if you need a starting point instead of a blank page, the public CISA playbooks are free and perfectly adaptable to a private company.
What does a real playbook look like?
An example explains it better than a definition. This is the opening of a playbook for ransomware, summarized, just as an on-call analyst would execute it:
Ransomware playbook · critical severity
Trigger: more than 50 files modified per minute on the same server, or detection of an encryption process by the EDR.
1. Isolate the device from the network from the console. Authorized without prior approval.
2. Do not shut down the device. Memory contains evidence that is lost on reboot.
3. Identify the account that ran the process and disable it. Rotate its credentials.
4. Check whether the most recent backup is accessible from that account. If it is, disconnect it.
5. Search for the same indicator across the rest of the fleet. The first device is almost never the only one.
6. Notify the client's IT lead and the incident leader. Alternate channel if email compromise is suspected.
Requires human approval: shutting down production services, paying anything, communicating externally.
Look at step 2. It is a single line, and it contradicts the instinct of anyone watching their server get encrypted. Without that line written beforehand, the team shuts down the server, the memory is lost and the investigation starts blind. A playbook is, to a large extent, a collection of decisions made with a cool head so that nobody has to make them in the heat of the moment.
Which playbooks get written first?
Nobody has a playbook for every possible scenario, and nobody needs one. Five cover the vast majority of what actually happens in a mid-size company:
| Playbook | Why this one | The decision it settles |
|---|---|---|
| Ransomware | The highest-impact one and the least tolerant of improvisation | Isolate without shutting down, and who can stop production |
| Compromised account | The most frequent, almost always through phishing | Close sessions and rotate credentials without waiting for the account owner |
| Mass malicious email | It reaches dozens of mailboxes at once | Deleting the message from every mailbox and alerting staff |
| Endpoint malware | The SOC's bread and butter | When cleaning is enough and when the device is reinstalled |
| Unauthorized data access | It is the one that triggers legal obligations | When to notify and whom, with the deadlines at hand |
The fifth deserves a separate comment. In Mexico, unauthorized access to personal data stops being just a technical problem and enters the territory of the obligation to notify. That playbook is written with the legal team at the table, not afterward.
How is it different from an incident response plan?
They are used as synonyms, and they are not. The plan is the framework document: it defines the committee, the severity levels, the general responsibilities and how a crisis is declared. It is what an auditor asks for. It usually has signatures and an annual validity period.
The playbook is the level below: one procedure per incident type, written to be executed. A plan without playbooks is a statement of intent. Playbooks without a plan work fairly well in practice, even if they do not pass an audit.
There is a third term that also gets mixed in, the runbook, which in infrastructure operations is the procedure for routine, scheduled tasks. The practical distinction: the runbook is executed because it is due, the playbook is executed because something happened.
Who decides what the provider can do without calling you?
This is the question that has to be settled before signing with any monitoring service, and the one that is almost never asked. A SOC can detect in minutes and then wait hours for authorization. Fast detection with a slow response produces the same damage as slow detection, except that it is on the record.
That is why the playbook includes an authority matrix. Actions the analyst executes immediately, in writing and agreed in advance: isolate a device, disable an account, block a domain, delete an email from every mailbox. Actions that always require a human on the client side: shutting down production systems, notifying customers or authorities, any decision with commercial or legal consequences.
When a prospect asks us exactly what we do when we detect something, the answer is not a list of technologies. It is this: the playbook agreed with them, with its authority matrix, its timelines and its contacts. A provider that answers that question with “we notify you immediately” is describing an alerting service, not a response service.
Why doesn't a playbook that nobody rehearses count?
An unrehearsed playbook is a hypothesis. You find out when you test it, and what surfaces is always the same: the owner's phone number is no longer that one, the person listed in step 4 changed roles in March, nobody is clear on who authorizes stopping billing, the backup that was going to be used is eight months old.
The exercise does not need to be expensive. The people involved get together for ninety minutes, a scenario is read aloud and each person says what they would do and with what access. It is called a tabletop exercise, and it usually yields more findings than an entire audit. Two a year, one for ransomware and one for a compromised account, already make an enormous difference.
After every real incident, the playbook is updated. That is the moment when the most is learned and the one most often wasted, because once everything is back to normal nobody wants to talk about it again.
Can they be automated?
Partly, and that is where SOAR comes in. Mechanical steps that require no judgment automate well: enriching an alert with threat intelligence, opening the ticket, checking whether the indicator appears on other devices, isolating the endpoint. That cuts minutes where minutes matter and lowers the mean time to respond.
What does not get automated is judgment. Deciding whether this server can be shut down in the middle of operations, whether the impact justifies activating the crisis committee, whether what we are seeing is a real attack or the outside consultant working on a Sunday. A well-written playbook clearly distinguishes between the two: what the machine executes and what a person decides.
Frequently asked questions
How many pages should a playbook have?
Who writes the playbooks, the provider or the company?
Does a playbook help with ISO 27001 compliance?
How often are they reviewed?
What happens if we have alerts but no playbook?
What is written beforehand is what gets executed afterward
No incident plays out exactly as the paper says. That is not an argument against the paper: the moment the alert goes off, the only thing that gets executed well is what had already been decided.
At ZetTateK, playbooks are part of our managed 24/7 SOC, and they are agreed with the client before the first sensor is connected, with their authority matrix and committed timelines. If you want to know which scenarios you should cover first in your operation, the free security assessment is the shortest path. The technical terms in this article are explained in our cybersecurity glossary.
An incident is not answered with tools. It is answered with decisions, and the good ones are made beforehand.
