How to Build an Incident Response Plan for Your Small Business

At 10:47 on a Tuesday morning, your bookkeeper clicks a link in what looked like a DocuSign request, and by 10:52 something is clearly wrong with her machine. Here is the question that decides how the next month goes: does she know, right now, exactly who to call and what to say? An incident response plan is the document that makes the answer yes. It is the written playbook that tells your business who does what, in what order, when something bad happens to your systems, and the difference between having one and improvising is usually the difference between a contained Tuesday and a quarter spent in recovery.

This guide explains what belongs in an incident response plan built for a small or mid-sized business, walks through the lifecycle every good plan follows, and hands you a fill-in template you can adapt this week, along with the testing habit that keeps it from becoming shelf decoration.

What an Incident Response Plan Is, and What Counts as an Incident

An incident response plan is a short written document that defines how your business detects, reports, contains, and recovers from security incidents, and who is responsible for each step. An incident is any event that threatens the confidentiality, integrity, or availability of your systems or data: a clicked phishing link, a lost laptop, credentials showing up where they should not, ransomware, a vendor emailing that their breach included your records. Not every incident is a catastrophe, and the plan's first job is exactly that sorting, deciding in calm daylight what counts as minor, serious, and severe, so nobody has to invent the scale at midnight.

Why a Written Incident Response Plan Beats a Smart Team

Every argument against writing the plan sounds reasonable until the incident. Your IT people are sharp, everyone knows to call the owner, and the business is small enough to coordinate by group text. Then the real thing arrives and the sharp people are on vacation, the owner's phone is off, and the group text becomes a place where well-meaning employees suggest turning everything off and on. A written plan wins for one structural reason: it moves decisions from the worst possible moment to the best one. Who has authority to disconnect systems, whether you contact customers, when the cyber insurer gets called, all of it decided in advance, on purpose, with nobody's adrenaline involved. Insurers and compliance frameworks increasingly expect the document to exist, but the operational case would justify it alone.

Incident response versus disaster recovery

The two plans are cousins, not twins, and businesses that merge them regret it. Incident response handles the security event itself: detection, containment, evidence, notification. Your disaster recovery plan handles restoring operations — systems, data, workspaces — whatever the cause: fire, flood, or the ransomware your incident response just contained. They hand off to each other: response decides the bleeding has stopped, recovery rebuilds. Keep them as separate documents with a named handoff point, and each stays short enough to use.

The Lifecycle Behind Every Good Plan

The incident response lifecycle popularized by NIST gives the plan its skeleton, four phases that repeat with every incident.

Preparation

Everything you do before anything happens: the plan itself, the contact tree, logging turned on so there is something to analyze later, backups that restore, and people who know that reporting a suspicious click fast is praised, never punished. Preparation is also where detection capability gets decided, whether alerts from your environment reach a human at 2 a.m., which for most small businesses is the practical argument for managed detection and response rather than an unwatched inbox of warnings.

Detection and analysis

The incident begins officially when someone or something notices, an employee report, an alert from your threat detection stack, a customer asking why your email looks strange. Analysis answers three questions fast: what happened, what does it touch, and how bad is it on the severity scale the plan defined. The discipline here is writing things down from the first minute, times, machines, actions taken, because that log becomes the incident's memory when insurers, lawyers, or regulators ask later.

Containment, eradication, and recovery

Containment stops the spread: isolate the machine from the network, disable the compromised account, block the sender, without destroying evidence, which is why the plan says disconnect rather than power off. Eradication removes the cause, the malware, the attacker's access, the vulnerable service. Recovery returns systems to service carefully, watching for reinfection. For specific severe scenarios the general plan points to scenario playbooks, and the first playbook every small business should attach is the one for ransomware incident response, where the first twenty-four hours have their own choreography.

Post-incident review

Within two weeks of closing any serious incident, the people involved spend one honest hour on four questions: what happened, what worked, what failed, and what changes, in controls, in the plan, in training. The review is where incidents stop repeating, and skipping it is how businesses get breached the same way twice.

The SMB Incident Response Plan Template

What follows is the working skeleton, eight sections, each described so you can fill it in for your own business. Written honestly, the whole document runs five to eight pages.

One structural choice before the sections: keep the core plan generic and attach scenario playbooks as appendices, one page each for the incidents most likely to hit your business. The starter set for most SMBs is four: ransomware, payment and wire fraud, a lost or stolen device, and a compromised email account. The core plan answers who and how; each playbook adds the handful of scenario-specific steps, so responders are never reading philosophy at midnight.

1. Purpose and scope

Two paragraphs: what this plan covers, security incidents affecting company systems, data, and accounts, and who it applies to, which is everyone, including contractors and leadership.

2. Roles and the contact tree

Name an incident commander, the person with authority to make containment decisions including taking systems offline, and a deputy for when they are unreachable. List the internal tree with after-hours numbers, then the external calls in order: your IT provider's emergency line, your cyber insurance hotline with the policy number written beside it, legal counsel, and a forensics contact if your insurer designates one. Every name gets a backup; every number gets tested. Print the tree on a wallet card and on the breakroom wall, because the incident that takes email down also takes the plan's PDF with it.

3. Severity levels

Three tiers with examples and wake-up rules. Minor: single suspicious email reported, no click, handled in business hours. Serious: confirmed malware on one machine, a compromised account, a lost device, incident commander notified same day. Severe: ransomware, active attacker, confirmed data exposure, systems down, everyone on the tree is called now, whatever the hour.

4. Reporting: how incidents enter the plan

One channel every employee knows, a phone number and an email alias, plus the sentence that changes outcomes: reporting fast is always right, even when you caused it, and no one is punished for a prompt report. Speed of reporting is the single variable your training most controls, which is where teaching people to recognize and report what they see pays off daily.

5. First-response actions

The standing instructions for the first minutes, written for a nervous person to follow: disconnect the affected machine from the network but leave it powered on, do not delete anything, do not log into other systems from it, write down what you saw and when, and call the reporting line. For compromised accounts: reset the password from a different, known-good device and turn on every session revocation the platform offers.

6. Communication rules

Who speaks, and who does not. Internally: the incident commander sends updates on a set rhythm so rumor does not fill the silence. Externally: nothing, no customer emails, no social posts, no statements, until the commander and counsel approve wording, because early guesses become quoted facts. If the incident may involve personal or regulated data, counsel joins before any external sentence is written.

7. Notification triggers

The section that keeps legal clocks from starting silently. If protected health information may be involved, the timelines and duties in the notification rules under HIPAA apply, and our summary of the notification obligations under HIPAA is the reading before the bad day. State laws, including California's, carry their own notification requirements for personal information, so the plan's rule is procedural rather than legal: any incident touching personal or regulated data goes to counsel the same day, and the deadlines get determined by a professional, not by memory.

8. Evidence, recovery, and closure

Preserve before you rebuild: images or copies of affected systems where feasible, logs exported, the incident journal complete. Recovery restores from known-good backups with fresh credentials, and the incident closes only after the post-incident review is on the calendar.

Testing: The Drill That Finds the Gaps

An untested plan is a rumor. The minimum viable test costs ninety minutes a year: gather the people named in the plan, read out a scenario — the bookkeeper's Tuesday click works fine — and walk the document step by step, asking at each point who acts and whether the information they need is actually in the plan. Every walkthrough we have ever run finds the same species of gap: a number that changed, a role held by someone who left, a step that assumes a system nobody can reach when the network is down. Add one unannounced micro-drill, call the after-hours tree at 9 p.m. once a year and see who answers, and you will learn more about your readiness than any audit. Businesses across the Thousand Oaks area run this exercise with us each fall, and the second year is always calmer than the first, which is the entire point.

Keeping the Plan Alive

The plan needs an owner, a named person who updates contacts quarterly, folds in lessons after every incident and drill, and re-issues the document annually even when nothing changed, so nobody trusts a stale copy. Store it where an incident cannot eat it: printed copies with the commander and deputy, and an offline digital copy, because the plan that lives only on the server the ransomware just encrypted is a joke the industry never stops retelling.

An incident response plan is the cheapest insurance your business will ever write for itself: a few pages, an afternoon of decisions, and a yearly walkthrough, purchased entirely in calm hours. If you would like the template filled in with real names and tested against a live scenario, book an incident readiness session with GlobeVM and we will run the first drill with you.