Incident response plan template for small businesses: what to write down before the bad morning

An incident response plan is a short, written playbook that tells your business exactly what to do in the first minutes and hours of a security incident: who decides, who acts, who communicates, and in what order. Its purpose is not to predict every attack — it is to replace improvisation with prepared decisions at the moment when stress is highest and time matters most.

Need a starting point? Jump to the fill-in template, then read on for how to make it work under pressure.

Why a small business needs one before it "needs" one

Three forces have turned the incident response plan from a best practice into a requirement. Insurers increasingly ask for one on cyber insurance applications, and some tie claim handling to whether you followed it. Enterprise customers ask for it in security questionnaires before they sign. And regulators in a growing number of states and sectors set breach-notification deadlines measured in days — deadlines you cannot meet if the first day is spent figuring out who is in charge.

The economics are just as direct: nearly every study of breach costs finds that response speed is one of the largest cost levers. Wires can be recalled in hours, not weeks. Attackers who are contained early do less damage. Customers forgive a fast, honest notification far more readily than a slow, confused one.

The incident response lifecycle, in plain language

Most credible plans follow the structure in NIST's incident response guidance, Special Publication 800-61. Stripped of jargon, it is four repeating stages:

What a usable plan actually contains

The plans that work under pressure are short — commonly under ten pages — and answer seven questions specifically for your business:

• Who declares an incident, and who leads it? One named incident lead with a deputy. Committees do not contain breaches.
• Who can make the expensive calls? Decide in advance who may take systems offline, suspend payments, engage lawyers, or approve after-hours spending — so nobody waits for a meeting at 2 a.m.
• How do we communicate if email is compromised? An out-of-band channel (phone tree, personal-device messaging group) agreed before it is needed, because the attacker may be reading the inbox you would normally coordinate in.
• Who gets called, in what order? A one-page contact tree: incident lead, IT/MSP, cyber insurer's breach hotline, legal counsel, bank fraud line, and key executives — with after-hours numbers. Call the insurer early; many policies require using their approved response vendors for costs to be covered.
• What do we preserve? A short evidence rule: don't wipe or rebuild affected machines before images and logs are captured, and start a timestamped log of actions taken. Recovery decisions made without evidence are guesses.
• Who talks to the outside world? One spokesperson, pre-agreed holding statements, and a rule that nobody else comments — including on personal social media.
• What are our notification obligations? A pre-built list, checked with counsel, of who must be told and how fast: regulators, affected individuals, customers under contract, and law enforcement — including reporting fraud to the FBI at ic3.gov.

Incident response plan template: fill in the blanks

Use this template as the skeleton of your plan. Copy it into a shared document, replace every bracketed field with a real name, number, or decision, and store a printed copy somewhere that does not depend on your network. A section you cannot fill in is a finding: write down who will close it and by when.

1. Plan basics

2. Roles and decision authority

3. Contact tree

Out-of-band channel if email or chat is compromised: [phone bridge number or messaging group on personal devices].

4. Severity levels

5. First-hour checklist

1. Incident lead declares the incident, sets severity, and opens a timestamped action log.
2. Move coordination to the out-of-band channel if email or chat may be compromised.
3. Contain: isolate affected devices from the network and disable affected accounts. Do not wipe or rebuild yet.
4. If money moved, call the bank fraud line now. Recall windows are measured in hours.
5. Call the insurer's breach hotline before engaging outside responders, so costs stay covered.
6. Preserve evidence: keep logs, take images or snapshots of affected systems, and save suspicious messages with headers.
7. Brief the executive sponsor and agree the next check-in time.

6. Notification obligations

7. Recovery and review

• Restore from: [backup system], last restore test on [date], restore order [critical systems in sequence].
• Return to normal when: [criteria, for example attacker access removed, credentials reset, monitoring confirms no reinfection].
• Post-incident review: within [10] business days, led by [name], with every fix assigned an owner and a date.
• Scenario playbooks attached: [business email compromise], [ransomware], [lost device], [compromised AI tool].

Add playbooks for the incidents you'll actually have

The base plan handles any incident; short scenario playbooks — a page each — handle the likely ones. For most small and mid-sized businesses, four cover the bulk of real events:

• Business email compromise. The most common money-loss event. The critical path is bank recall first, then mailbox lockdown and rule review — the sequence is covered in our BEC guide.
• Ransomware. Isolate fast, engage the insurer's response team, and know in advance your position on payment and who can make that call. Recovery rests entirely on whether backups were tested before the incident.
• Lost or stolen device. Remote wipe, credential resets, and an honest assessment of what data was reachable.
• Compromised or misbehaving AI tool. New for most plans, and increasingly necessary: revoke the tool's access, capture its activity logs, and treat its connected permissions as the blast radius. If AI agents can act in your systems, incident readiness for them is part of AI agent security, not an afterthought.

A plan you never rehearse is a document, not a capability

The difference between companies that respond well and companies that have a plan is practice. Twice a year, run a tabletop exercise: gather the people named in the plan, walk through one scenario ("accounting just paid a fraudulent invoice", "a laptop with customer data is gone"), and let people make the actual decisions. CISA publishes free tabletop exercise packages if you want structured scenarios. Every exercise ends the same way: a short list of things that didn't work — an outdated phone number, an unclear authority, a backup nobody has restored — fixed before a real attacker finds them for you.

Update the plan on a trigger, not a whim: after every exercise, after every real incident, and after material business changes — new systems, new leaders, new insurer, new AI tools with access to company data.

Who should own the plan

An incident response plan needs an owner with authority across IT, finance, legal, and communications — which is why it defaults to no one in companies without a security executive. If that is your situation, two honest paths exist: a cybersecurity risk assessment that establishes what is material and produces the plan as part of a prioritized roadmap, or fractional security leadership that owns readiness as a standing responsibility — including running the tabletops and holding the contact tree current. Either way, the goal is the same: when the bad morning comes, nobody in your company is opening the plan for the first time.