The Incident Response Plan Your Business Will Actually Use

A one-page incident response plan for small businesses: five pre-decided answers, a fill-in-the-blanks template, the two-hour annual tabletop, and why it must be printed.

By Scott McAuley · Aug 5, 2026 · 10 min read

Ask a business owner if they have an incident response plan and you'll usually get one of two answers: "we'd call our IT guy" — which is not a plan — or a gesture toward a binder that was written for an insurance application, filed, and never opened again. Both fail the same test: it's Monday, 7 a.m., nothing opens, and everyone is looking at you. Nobody speed-reads a binder at that moment. Nobody improvises well, either.

There's a third option, and it's the one we argued for in our [small business cybersecurity guide](/resources/small-business-cybersecurity-guide): a plan short enough to actually be used — one page, five pre-decided answers — backed by a two-hour annual exercise that keeps it true. This article expands that section into something you can build this week: what each of the five answers needs to contain, a fill-in-the-blanks template, the tabletop that stress-tests it, and how the plan meshes with your insurance policy and your industry's notification rules.

The premise behind the whole thing: an incident response plan is not a technical document. It's a set of *decisions* — made in advance, by calm people, so that stressed people don't have to make them badly at 7 a.m.

Answer 1: Who's in Charge — and Who's the Deputy

The first minutes of an incident are lost to a question nobody wrote down: *who has the authority to act?* Someone has to be able to order systems disconnected — including revenue-generating ones, during business hours — and authorize emergency spending without convening a meeting.

Name that person. Then name a deputy with the same authority, because incidents have a documented fondness for vacations, red-eye flights, and dead phone batteries. The incident lead does not need to be technical — they're not doing the forensics; they're making the calls the technical people need someone to make. In most small businesses it's the owner, a partner, or the operations lead.

Write both names, both cell numbers, and one sentence: "This person can disconnect anything and spend what's needed." The twenty minutes a team spends waiting for permission while ransomware spreads is the most expensive twenty minutes on the calendar.

Answer 2: Who Gets Called, in What Order

Under stress, people call whoever they think of first, in whatever order occurs to them. The plan replaces that with a written call order:

1. Your IT provider — the containment call. They start isolating systems and assessing scope while everything else happens in parallel.

2. Your cyber insurer's breach hotline — earlier than instinct suggests. This is the call businesses get wrong most often. Many policies require carrier notification *before* you authorize outside spending, and using non-approved vendors can jeopardize coverage. The hotline also brings cavalry: carriers maintain approved incident response firms and breach counsel who do this every week. Calling the insurer second, not fifth, is a policy-compliance issue with real money attached.

3. Counsel — often supplied through the policy. Before anyone communicates externally, legal eyes matter, because improvised breach communication creates liability that outlasts the incident.

4. The notification-clock owner. If you're in a regulated industry, someone must own the deadline math from hour one — HIPAA's breach clock for practices, the FTC Safeguards Rule's reporting window for covered financial firms, state notification statutes for everyone. Name the person who starts that clock and tracks it.

Write the actual phone numbers next to each line — the policy number and hotline live on this page too. Looking up your insurer's claims line while your email is down is a research project; reading it off the page is ten seconds.

Answer 3: What Gets Isolated — Contain, Don't Investigate

The instinct in the first hour is to figure out what happened. Wrong job. The first hour's job is to stop the spread: disconnect affected machines from the network — unplug cables, kill Wi-Fi — and widen the isolation if you're unsure where the edge is.

Two rules ride along with containment:

The plan's version of this answer is short: which systems the incident lead is pre-authorized to isolate (answer: any of them), the order of priority if it's spreading, and the two don'ts in bold.

Answer 4: How You Operate While Down

Houston businesses already know how to think about this — it's hurricane planning pointed at a different disaster. When a storm takes the power out, you don't invent emergency operations on the spot; you run the plan written in calm weather. A cyber incident deserves the same: a written emergency mode for running the business with no systems.

The questions to answer in advance, per team: How do we take orders or see patients on paper? How do we answer phones and triage calls if the system that routes them is down? What do we tell customers about timelines? What's genuinely impossible without systems, and what's merely slower? A medical practice's version includes paper intake and rescheduling protocols; a distributor's includes phone orders and handwritten pick tickets; a firm's includes reaching client files' offline copies.

This answer is also where the plan earns its keep financially. Downtime costs for small businesses run into the thousands of dollars per hour when you count idle payroll, stalled revenue, and recovery labor — we walk the math in [the real cost of IT downtime](/resources/real-cost-it-downtime-houston-small-businesses) — and a rehearsed emergency mode directly shortens the expensive part. The other half of shortening it is recovery itself: knowing your backup restore times *before* you need them, which is the recovery-time-objective work our [backup and disaster recovery](/services/backup-disaster-recovery) practice builds and tests with clients.

Answer 5: Who Says What — One Voice

During an incident, every employee becomes a potential spokesperson — to customers on the phone, to their social feeds, to the friend who asks why the office is closed. Uncoordinated statements create three problems: they spread inaccuracies that must be corrected later, they can create legal exposure ("they told me my data was fine"), and they hand rumor a head start.

The plan names one voice — usually the incident lead or owner — and gives everyone else one sentence to say: "We're aware of a technical issue, we're working on it, and [name] will have updates." External statements get counsel's eyes first, especially anything touching whose data was involved. Silence plus a named point of contact beats improvised reassurance every time.

The Fill-in-the-Blanks Template

Here's the whole plan as prompts. Answer these on one page and you're done:

In charge

The call order

Containment

Emergency mode

One voice

Logistics

Fill it in, and resist the urge to make it longer. Every detail you add is something that can go stale — and the one-page constraint is what keeps the plan readable at 7 a.m.

The Two-Hour Annual Tabletop

An untested plan is a theory. Once a year, put two hours on the calendar, gather the leadership team plus your IT provider, and walk one scenario out loud. Here's one to use:

Monday, 7 a.m. The office manager calls: nothing opens. Every workstation shows the same note demanding payment. Email is down. The phones work, but the system behind them doesn't. First patient — or customer, or delivery — arrives at 8.

Then walk the page, in order, asking the awkward questions: Who declares this an incident, and is the lead reachable right now — actually, call their cell? What's the insurer's hotline number, and does anyone know where the policy number is? Who physically disconnects the server, and do they know they're allowed to? What does the front desk say at 8:01? Who's tracking whether this starts a notification clock?

The tabletop's product is a punch list of what creaked: the number that changed, the deputy who never knew they were the deputy, the paper forms nobody printed. Fix the list, date the page, book next year's session. Two hours annually is the entire maintenance cost of a plan that works — and, as covered in [the cybersecurity guide's](/resources/small-business-cybersecurity-guide) broader baseline, rehearsed businesses recover in a fraction of the time of improvising ones.

The Insurance and Regulatory Thread

Two outside parties have opinions about your plan, and it pays to reflect both.

Your insurer. Carriers increasingly ask about incident response plans on applications, alongside MFA, EDR, and tested backups — and application answers are binding. More practically, the policy itself imposes duties the plan must encode: notify the carrier before engaging outside vendors, use approved response firms, document everything. A plan that contradicts your policy's requirements is a plan for a coverage dispute. Before renewal, read the claims-reporting section of your policy against your call order — the current carrier landscape is covered in our guide to [cyber insurance requirements for Houston businesses](/resources/cybersecurity-insurance-requirements-houston-businesses).

Your regulators. If you're in a regulated industry, notification duties are part of incident response, not an afterthought — which is why the notification-clock owner is named on the page. Medical practices carry HIPAA's breach-notification requirements; financial firms under the FTC Safeguards Rule have their own reporting window; every business faces state notification laws when personal data is involved. The plan doesn't need to contain the law — it needs to name the person who picks up the deadline math in hour one.

Print It

Last instruction, and the one that sounds paranoid until the day it doesn't: print the plan. The document's entire purpose is to function while your systems are down — and a plan stored on the encrypted file server, or in a cloud drive behind an account you're locked out of, fails at exactly that moment. Paper copies at the office, and one at home with each person named on the page. When something changes — provider, insurer, phone number — reprint and swap the copies; the tabletop's punch list is the natural trigger.

If you want a second set of eyes on the result — or you'd rather build it alongside the backup and recovery testing that makes the "how long until we're back" answer real — [contact us](/contact). We build and tabletop these plans with Houston businesses as standard practice, and we'll pressure-test yours against what attackers, insurers, and regulators will actually throw at it.

*Scott McAuley is the founder and CEO of Texas Management Group, and founder of Talos Automation and Talk Is Cheap — 25+ years running IT, communications, and automation for Texas businesses.*

Frequently Asked Questions

What should a small business incident response plan include?

Five pre-decided answers on one page: who's in charge (with a deputy and explicit authority to disconnect systems and spend money), who gets called and in what order, what gets isolated first and the forensic don'ts, how the business runs in emergency mode while systems are down, and who speaks for the company. Longer plans get written; short plans get used.

Who should we call first during a cyber incident?

Your IT provider to begin containment, then your cyber insurer's breach hotline immediately after — before authorizing other outside spending. Many policies require carrier notification first and mandate approved vendors, and the insurer brings the incident response firm and breach counsel with them. Counsel and your notification-clock owner round out the call order.

How often should we test our incident response plan?

Once a year, as a two-hour tabletop: leadership plus your IT provider walk one written scenario — "Monday 7 a.m., nothing opens" — from discovery through customer communication. The output is a punch list of stale numbers, unclear authority, and missing paper forms, fixed on a calm afternoon instead of during the real thing.

Does cyber insurance require an incident response plan?

Increasingly yes — it appears on applications alongside MFA, EDR, and tested backups, and application answers are binding. The policy also imposes duties the plan must reflect: carrier notification before spending, approved response vendors, documentation. A plan that contradicts the policy is a setup for a coverage dispute.

Why does the incident response plan need to be printed?

Because it's needed precisely when systems are unavailable. A plan on the file server ransomware just encrypted, or in a cloud account you can't reach, fails at its only job. Keep paper copies at the office and with every person named in the plan, and reprint whenever a name or number changes.