How to Build an Incident Response Plan
A step-by-step framework for building an incident response plan that actually works.
An incident response plan is a short written playbook that defines who does what when a security incident hits: how you detect and declare an incident, who contains it, who gets called and in what order, how you recover, and what you learn afterward. A workable plan for a small company fits on five to ten pages, uses the six-phase framework below, and is rehearsed at least once a year — a plan nobody has read is just a document.
The value of the plan is not the paper. It is the decisions you make in advance — while calm — that you would otherwise have to make at 3 a.m. under pressure: who has authority to take systems offline, whether counsel gets called before or after the insurer, and what your default posture is on ransom payment. If you want a concrete picture of the crisis this plan exists for, read what happens during a ransomware attack first.
Plan versus runbook: get the layering right
The most common structural mistake is writing one giant document that tries to be both policy and procedure. Separate them:
- The plan is the umbrella: what counts as an incident, severity levels, who is in charge, how escalation and communication work, and the phases every response follows. It changes rarely.
- Runbooks are tactical step-by-step procedures for specific scenarios — ransomware, business email compromise, a lost laptop, a compromised cloud account. They are attached to the plan, written per threat, and revised as your environment changes.
This layering keeps the plan maintainable. When your email platform changes, you update the business email compromise runbook — not the entire plan. Start with runbooks for your two or three most likely scenarios; a ransomware runbook and a business email compromise runbook cover the incidents small companies actually face most often.
The six-phase response framework
The framework below — preparation, detection, containment, eradication, recovery, lessons learned — is the standard structure behind most published incident response methodologies, including the NIST incident handling guide. Your plan should have a short section for each phase.
Preparation
Everything you do before an incident: the plan itself, the call tree, logging and monitoring in place, tested backups, an asset inventory, offline copies of credentials and install media, and tabletop exercises. Preparation is the only phase you fully control, and it determines how every other phase goes. Most of this overlaps with the fundamentals in our cybersecurity checklist for a 50-person company.
Detection and analysis
How incidents surface — EDR alerts, user reports, a vendor notification, a ransom note — and who triages them. Define a declaration threshold: who has authority to say "this is an incident" and activate the plan. Ambiguity here is expensive; teams lose hours debating whether something is "real" while an attacker moves laterally. When in doubt, declare. Standing down costs little; standing up late costs a lot.
Containment
Stopping the bleeding without destroying evidence: isolating affected systems from the network, disabling compromised accounts, blocking malicious infrastructure at the firewall or DNS layer. Pre-authorize containment in the plan — the on-call responder should not need to wake a VP to take an infected segment offline. Decide in advance whether your default is "isolate the device" or "isolate the site."
Eradication
Removing the attacker's access completely: reimaging compromised systems rather than cleaning them, resetting credentials the attacker could have touched — including service accounts and API keys — closing the entry vector, and verifying persistence mechanisms are gone. Half-measures here are how organizations get reinfected two weeks after "recovery."
Recovery
Restoring business operations in priority order from verified-clean backups or rebuilds, with validation before systems return to production. Your plan should name the restore order — identity and core infrastructure first, then revenue-critical applications, then everything else — and who signs off that each system is clean. Recovery speed is set by your backup design; endpoint backup versus server backup covers the architecture decisions that matter.
Lessons learned
Within two weeks of closing an incident, hold a blameless review: what happened, what worked, what failed, and what changes — technical, procedural, or staffing — would have made the response faster or cheaper. Assign every improvement an owner and a deadline. This phase is what turns an expensive incident into a stronger program; skipping it guarantees you pay tuition twice.
Roles and the escalation matrix
Small teams can't staff a formal security operations center, but they can name roles in advance. One person can hold several roles — what matters is that every role has a name and a backup next to it. The matrix below is a defensible starting point for a company of 25 to 150 people.
Example roles and escalation matrix
| Role | Typical owner | Authority during an incident |
|---|---|---|
| Incident commander | IT manager or operations lead | Runs the response; coordinates all parties; owns the incident log |
| Technical lead | Senior sysadmin or MSP engineer | Executes containment and eradication; pre-authorized to isolate systems |
| Executive sponsor | CEO, owner or CFO | Approves business-impacting decisions: shutdowns, ransom posture, public statements |
| Communications lead | Office manager or HR lead | Drafts staff and customer communications; fields inbound questions |
| External parties | Counsel, cyber insurer, forensics firm | Called per the call tree; counsel directs privilege, insurer approves covered actions |
Communication: who calls whom, and in what order
Communication failures do more damage in most incidents than technical ones. The plan should include a one-page call tree with current contact details — including after-hours numbers — kept both digitally and on paper, since the incident may take your email and file shares with it. A workable sequence:
- Internal first: the discoverer notifies the incident commander, who activates the plan and briefs the executive sponsor.
- Legal counsel early: counsel assesses notification obligations and can direct the investigation under privilege — which affects how findings are documented. Many insurers require you to use approved breach counsel.
- Your cyber insurer early too: most policies require prompt notification and pre-approval before you hire forensics or engage an attacker. Call them before the negotiator, not after.
- Your MSP or MDR provider: loop them in per your contract's incident clause; know in advance what response work is included and what is billed separately.
- Affected customers and regulators: only with counsel's guidance — timelines and wording are legally constrained, and premature or inaccurate statements create their own liability.
Write two communication templates in advance and store them with the plan: an internal all-staff message ("we are experiencing an IT disruption; here is what to do and not do") and a customer-facing holding statement. Drafting either from scratch mid-incident wastes hours you do not have.
One operational rule worth writing into the plan: assume the attacker can read company email and chat. Stand up an out-of-band channel — a personal-device Signal group or a separate tenant — for response coordination, and document it before you need it.
Tabletop exercises: rehearse before it counts
A tabletop exercise is a guided discussion, not a technical test: the team sits down for two to three hours and walks through a fictional scenario — "it's 6 p.m. on a Friday and the file server is encrypted" — making each decision out loud as if it were real. Someone facilitates, someone takes notes, and nobody is allowed to say "we would just handle it."
Run one at least annually, plus after major changes to your team, environment, or plan. Rotate scenarios across your runbooks. The findings are almost always the same categories: a contact number that's out of date, a decision nobody has authority to make, a backup nobody has test-restored, an insurer clause nobody had read. Each finding becomes an assigned action item — that list is the real deliverable.
If you've never run one, start with the ransomware scenario. Our walkthrough of what happens during a ransomware attack gives you a realistic phase-by-phase script to facilitate against.
"An incident response plan is a set of decisions made in advance. The document is just where you wrote them down."
Key takeaway: the plan's value is decided in the writing and rehearsing, not in the reading during a crisis.
The one-page version a small company can actually maintain
If a full plan feels like too much to keep current, start with a single page that fits in a laminated sheet next to the phone system. It cannot cover everything, but it covers the first hour — which is where small companies win or lose an incident. Include exactly this:
- Declaration rule: who can declare an incident, and the instruction to declare when in doubt.
- Call tree: incident commander, executive sponsor, MSP, counsel, insurer — names and after-hours numbers.
- First-hour actions: isolate affected systems, disable compromised accounts, preserve evidence, communicate out-of-band.
- Pre-agreed authorities: who may take systems offline, who speaks to customers, and the leadership posture on ransom payment.
- Location of the full plan and runbooks: including the offline copy.
Review the page quarterly — a five-minute agenda item in an operations meeting — and update numbers and names as people change roles. A stale call tree is the single most common plan failure, and the easiest to prevent. For the preventive controls that reduce how often you'll need any of this, see our 50-person company security checklist, and baseline your posture with the security score calculator.
Frequently asked questions
How long should an incident response plan be for a small company?
Short enough to be used. For a company under 100 people, a five-to-ten page plan covering the six phases, a call tree, and decision authority is usually right, with detailed runbooks kept as separate attachments. A one-page summary version for leadership and after-hours responders is a worthwhile addition.
What is the difference between an incident response plan and a runbook?
The plan is the umbrella document: it defines what counts as an incident, who is in charge, how escalation and communication work, and what the phases of response are. A runbook is a tactical, step-by-step procedure for one specific scenario — ransomware, business email compromise, a lost laptop. The plan stays stable; runbooks are written and revised per threat.
How often should we run a tabletop exercise?
At least annually, and after any major change to your environment, team, or plan. A tabletop exercise is a two-to-three hour guided discussion of a fictional incident with the people who would actually respond. Frequency matters less than honesty: the exercise only works if you let it expose gaps and then assign owners to close them.
Do we need an incident response plan if we have an MSP or MDR provider?
Yes. A provider can execute containment and forensics, but they cannot decide whether to pay a ransom, notify customers, or halt operations — those decisions belong to your leadership. The plan defines how your organization and your provider work together, who has authority for what, and how communication flows. Without it, you lose the first hours of an incident to confusion about roles.
Need a plan your team will actually use?
SmashByte Security helps growing companies build right-sized incident response plans, write scenario runbooks, and facilitate tabletop exercises that surface gaps before an attacker does.
Request Security Assessment
