Incident playbooks
One playbook for one kind of incident
The plan names who decides. The playbook is the sequence for one incident type. We write it with the person who would perform the step. We work around your normal operations, and we'll need access to the right areas and the right people while we do.
Plan versus playbook
Companies often have one document that tries to be both. The roles are on page two, and the steps for every imaginable incident are in an appendix nobody can use at midnight. We split them. The incident response plan stays short: who decides, who is called, where the timeline goes. Each playbook is one incident type and the actions that belong to it.
A playbook that says “follow the process” is not a playbook. The process is what people cannot find when they are tired. The playbook says which system to open, which access to revoke, who else must hear about it, and what to write down before moving on.
We write these with the person who would perform the step. A sequence that looks correct to a consultant and wrong to the operator will be ignored. That is why access to the right people is part of the engagement, not a courtesy.
One playbook per type
We start with the incidents you can already describe. A lost laptop. A vendor account that still works after the contract ended. A payment system that no one person owns. A customer-data export that left the company. If you cannot name one, the first conversation is how to pick one, not how to draft five.
Ransomware is its own playbook, tied to the ransomware readiness assessment: revoke access, find the last restore that worked, and stop before anyone discusses payment without the person who is allowed to decide.
A breach playbook is tied to breach readiness. It says who gathers the facts and who is allowed to speak. It does not say whether the law requires a notice. That sentence belongs to counsel.
Each playbook ends when the incident is contained enough for the normal week to resume, or when the plan says to call an outside firm. The playbook includes that handoff. It does not pretend we will be on the keyboard.
What a step has to say
Every step names a person or a role that maps to a current person, the action, the system, and the evidence that the step happened. “Check the logs” fails that test. “The on-call engineer opens this system, exports the last hour, and puts the file in the timeline” passes it, if that engineer exists and that system is real.
Steps that require access the on-call person does not have are written as a call to the person who does, not as an instruction the on-call person will fail. Shared admin passwords are written as a finding, not as a step.
We try the playbook against a recent incident if you have one, or against the tabletop record if you do not. A step that the room could not perform is rewritten or removed. Leaving a step you hope will work is how playbooks become fiction.
What this is not
We do not deliver a library of forty playbooks. A company that cannot run three will not run forty. The scope says which incident types are in, and you can decline it.
We do not install a new ticketing tool to hold the playbook unless the place you already write things down cannot hold a timeline. The record should live where the week already looks.
The playbooks stay with you. We'll need access to the right areas and people. When we leave, the people who would be called should be able to find the sequence without calling us. We work around your normal operations, and we'll need access to the right areas and the right people while we do.
Questions
How is a playbook different from an incident response plan?
The plan names the roles and the decisions. A playbook is the sequence for one kind of incident: a lost laptop, a vendor account, a payment system, or a customer-data export. The person on call should be able to follow it without inventing the steps.
Who writes the playbook?
We write it with the people who would perform the steps. We'll need access to the system the playbook covers and to those people. A playbook written without them describes a week they do not run.
Contact
Task us with one incident type.
If you have a draft playbook, say so. We will start from it. We work around your normal operations, and we'll need access to the right areas and the right people while we do.