How to Build a Breach Response Plan for a Small Firm

A breach response plan for a small firm needs four names, a dozen phone numbers, five phases, and fewer than ten pages. That's the entire specification. Not a binder, not a framework adoption project. A short document that tells a scared group of people what to do in what order, written by calm people on an ordinary afternoon. Firms skip it because it sounds like enterprise theater, and then they improvise the most consequential week in the firm's history.

The firm that paid twice

Improvisation has a case study. An accounting firm got hit with $300,000 ransomware twice. Same firm, second attack. Because after the first incident, once the panic faded and the files came back, the firm changed essentially nothing. No plan written, no controls tightened, no lessons captured while they were fresh and expensive. The weaknesses that let attackers in the first time sat exactly where they'd been left, and the second crew, or possibly the first one making a return visit, found the door still unlocked.

That points at the real function of a response plan. It does more than script the bad day. Its final phase forces the question nobody wants to answer during cleanup: what let this happen, and what changes before Friday? The fixes that come out of that question are rarely exotic. Most of them appear on any competent IT checklist for a growing firm, which is precisely what makes paying twice so hard to read about. The second $300,000 bought what a checklist afternoon would have.

Four names

**The decision-maker.** Usually a managing partner or the firm administrator. Approves communications, makes the calls that can't be delegated, keeps everyone else from freelancing. Doesn't need to be technical. Needs to be calm and reachable.

**The technical lead.** Your IT person or your managed service provider, with an emergency number that gets answered at night. They handle containment, investigation, and rebuilding.

**The communicator.** One voice for staff updates, client notifications, and anything public. This person holds the pre-drafted templates so nothing gets written from scratch under adrenaline.

**The lawyer.** Breach counsel identified before the breach, not shopped for during one. They own the notification-law questions and the privilege issues.

Write down personal cell numbers and personal email addresses for all four, because the firm's email may be the crime scene.

Three severity levels

Define what counts, so nobody debates it at midnight.

A security event is something suspicious with no confirmed compromise: a phishing email reported and deleted, a blocked login attempt. Investigate, note it, move on.

A security incident is a real compromise with limited scope and no client data involved: malware caught and contained on one workstation.

A breach is client data accessed, stolen, or encrypted. That's the full plan, every name, every phone number.

Five phases

Confirm, contain, investigate, fix, tell. In that order.

Confirm means separating false alarms from real compromise before mobilizing everyone. Contain means isolating machines, disabling accounts, and preserving evidence rather than deleting it. Our hour-by-hour walkthrough of the first 24 hours after a breach covers these two phases in the detail they deserve.

Investigate means finding the entry point, mapping what was reachable, and confirming the backups survived. Fix means closing the hole, resetting credentials broadly, and rebuilding compromised machines instead of trusting a cleanup.

Tell is the phase people get wrong. The insurer first, inside the policy's notification window, because carriers deny claims over late notice and their requirements are stricter than most firms realize. Then clients and regulators per the law, with counsel steering. If you're fuzzy on which notification rules even apply to your firm, that's one of the classic compliance gaps, and it's far cheaper to close now than to litigate later.

The paper part

Print the contact sheet. Store it somewhere that isn't your file server, because the plan that lives only on the encrypted server is a very dark joke. Keep a copy with your IT provider, one in a drawer, one in encrypted cloud storage a partner can reach from a phone.

Keeping it alive

A plan ages like milk. Fifteen minutes a quarter to check names and numbers. Once a year, a tabletop exercise: gather the four names in a conference room and walk a scenario out loud. It's a Tuesday in March, the file server is encrypted, the phones still work. Go. The first run-through is always humbling, and every hole it finds is one the real event won't.

And test the backups, because the plan quietly assumes they restore. Assumptions are where plans die.

Mistakes that make plans useless

Being generic. "Contact IT" isn't a step; a name and a number is a step. Covering only the technical half while ignoring who tells clients what, and when. Assuming your systems will be available to display the plan. And never practicing, which turns the document into decoration.

Write it this week

One afternoon. Assign the four names, build the contact sheet, write the five phases in your own words, draft two communication templates, book the tabletop. Done is the standard, not perfect.

If you'd rather pressure-test the result against people who do this professionally, our free cybersecurity trial is a low-stakes way to find the holes before an attacker does. And the full context for where a response plan sits among your other defenses is in our cybersecurity guide for firms. The firms that survive breaches aren't the ones with the biggest budgets. They're the ones that knew what to do first.