It’s a little after 2 AM. A staff member who logged in from home to catch up on notes calls you in a panic: every file on the shared drive has a weird new extension, and there’s a text file on the desktop demanding payment in cryptocurrency. Or the version that doesn’t wake you up at all: you find out three days later that a patient’s records were emailed to the wrong address, or that a laptop went missing from someone’s car over the weekend.
Whatever the shape of it, you are now in the worst possible moment to be figuring out what to do. And most small businesses and healthcare practices are figuring it out for the first time, live, with the clock running, because they never wrote anything down. There was always something more urgent than planning for a bad day that felt like it happened to other people.
This post is about the document that changes that moment: an incident response plan. Not the eighty-page kind a hospital system keeps in a compliance vault, but a one-page version a three-person practice can actually use at 2 AM. We’ll cover what an IR plan is and isn’t, why small practices skip it and why that’s a costly mistake, what improvising actually costs, and a six-step skeleton you can fill in this week. There’s a fill-in-the-blank template near the end you can print and tape inside a cabinet door.
What an incident response plan is (and isn’t)¶
An incident response plan is a short, written set of instructions for what your practice does when something goes wrong with your data or systems. It answers the questions nobody can think clearly about in the middle of a crisis: who do we call first, what do we shut off, who decides, and who are we legally required to tell. That’s it. At its core it’s a decision-making shortcut you write while you’re calm so you don’t have to invent one while you’re scared.
It helps to be clear about what it is not. It is not a firewall, an antivirus subscription, or any other tool that tries to prevent an incident. Prevention and response are different jobs; you need both, and having good prevention does not excuse skipping response, because prevention eventually fails for everyone. It is also not the same as a data backup, though backups are a critical ingredient of the recovery step. And it is not a technical manual full of command-line instructions. A good small-practice IR plan is readable by the least technical person on your staff, because that may well be the person holding it at 2 AM.
One caveat before we go further: this article is general education, not legal advice. Your exact notification obligations depend on your practice, your data, and your state, so treat what follows as a working map, not a substitute for counsel when a real incident hits.
Why small practices skip it, and why that’s a mistake¶
The reasons are understandable, and worth naming honestly, because most of them contain a hidden bad assumption.
The first is that incident response feels like big-company stuff. IR plans, “playbooks,” tabletop exercises: it all sounds like the vocabulary of a corporation with a security team and a legal department. A four-person dental office doesn’t have any of that, so the whole topic reads as not-for-us. But attackers don’t check your headcount before they encrypt your files. Automated ransomware and phishing campaigns hit small practices constantly, precisely because small practices are the ones least prepared to respond.
The second is the quiet belief that it won’t happen here. Nothing has gone wrong so far, business is busy, and the mind naturally treats an event it has never experienced as unlikely. The trouble is that “it hasn’t happened yet” is not a safeguard, and the practices that get hit are almost never the ones who saw it coming.
The third is simpler: it’s not urgent until it is. Writing an IR plan produces nothing you can see. It doesn’t bring in a patient or file a claim, so it stays at the bottom of the list behind everything that does. That’s exactly why the work only ever gets done under duress, which is the worst time to do it. The whole value of a plan is that it exists before you need it. Written during the incident, it isn’t a plan, it’s a scramble.
The real cost of improvising¶
Improvising a response isn’t just slower. It routinely makes the underlying incident worse, and the specific ways it does are predictable.
People pay too fast. Faced with a ransomware note and a countdown, the panicked instinct is to pay and make it stop. But paying is a decision with legal, insurance, and practical consequences (there’s no guarantee you get your data back, and in some cases payment itself carries regulatory exposure). It is not a call to make at 2 AM without your insurance carrier and possibly counsel in the loop, and a plan is what forces that pause.
People destroy the evidence. The intuitive reaction to a compromised machine is to wipe it and reinstall so you can get back to work. Doing that can erase the very forensic information that tells you what was taken, which is the information your breach-notification obligations and your insurer both depend on. Contain the system, yes; wipe it, not yet.
People miss deadlines. Breach notification runs on clocks. Under HIPAA, affected individuals generally must be notified without unreasonable delay and no later than 60 days after discovery, and notification to the Department of Health and Human Services is required as well, with the timing depending on how many people were affected. There may be state deadlines on top of that, sometimes shorter. A practice discovering all of this for the first time, after the clock has already started, tends to discover it late.
And people freeze. Without pre-assigned roles, everyone assumes someone else is handling it, or three people call three different vendors, or the one person who knows the systems is on vacation and unreachable and nobody else has the passwords. The cost of improvising is measured in the hours lost to that confusion, and in a crisis, hours are the expensive currency.
The six steps of a one-page plan¶
A workable plan for a small practice fits into six steps. You don’t need more, and more usually means it won’t get used.
1. Detect and report — who to call first. The plan names the one person who gets contacted the moment anyone notices something wrong, day or night, and how to reach them. It also tells every staff member what “something wrong” looks like (a ransom note, a strange login alert, a lost device, an email sent to the wrong person) and makes clear that reporting fast is always the right call, even for a false alarm. The goal is to shrink the gap between “something’s off” and “the right person knows.”
2. Contain — isolate the affected systems. Before anything else, stop the spread. In plain terms: disconnect the affected computer from the network by unplugging the network cable or turning off Wi-Fi, and leave it powered on if you can (powering off can destroy useful evidence). Don’t log into the affected accounts. The instinct to keep working through it is the instinct to fight.
3. Assess — what data and systems are involved. Figure out the scope: which machines, which accounts, and critically, what data was on them. Did the affected system hold patient records? How many people? This is the step that determines everything downstream, because your notification obligations depend entirely on what was actually exposed. Write down what you find as you find it.
4. Notify — your legal and regulatory obligations. This is where the plan earns its keep, because it lists the calls most people don’t know to make. Your cyber-insurance carrier, usually first, because many policies require prompt notice and will bring in a response team. Legal counsel. Under HIPAA, affected individuals (generally within 60 days of discovery) and HHS. Possibly law enforcement, and possibly state regulators. The plan doesn’t make you a compliance expert; it just makes sure nobody gets forgotten while the clock runs.
5. Recover — restore and reset. Once the incident is contained and understood, get back to work safely: restore data from a known-good backup (the one you’ve tested, not the one you hope works), reset every credential that could have been exposed, and don’t reconnect a system until you’re confident it’s clean. This is the step where untested backups turn a bad week into a catastrophe.
6. Review — capture the lessons. After it’s over, spend an hour on what happened and what you’d change. What let the incident in, what slowed the response, what was missing from the plan. Then fix those things and update the one page. A plan that gets better after every near-miss is the whole point.
The thread running through all six steps: pre-assign the roles, and keep a printed contact list. During a real incident your email may be down, your systems may be locked, and the contact info you need may be trapped inside the very account you can’t get into. Paper doesn’t get encrypted.
A plausible 2 AM at a small practice¶
Two versions of the same night, at the same imaginary three-provider counseling clinic.
Without a plan: the after-hours ransom note appears, and the staff member who found it panics and calls the office manager, who doesn’t answer. She tries the owner, who is asleep, then texts the IT contractor, whose number she thinks she has but it turns out to be an old one. By the time someone reaches the right people at 6 AM, three more machines on the network have been encrypted overnight because nobody disconnected anything. In the daylight scramble, someone reinstalls one of the machines to “get the front desk working,” erasing the evidence. Nobody thinks to call the cyber-insurance carrier for two days, missing the prompt-notice window in the policy. And it’s week three, buried in cleanup, before anyone realizes the exposed records trigger a HIPAA notification obligation whose clock started the night of the incident.
With a plan: the same staff member finds the note, pulls the taped-up one-pager off the inside of the supply cabinet, and follows step one: call the designated lead, whose after-hours number is right there. Step two, contain: she unplugs the machine’s network cable, leaves it running, touches nothing else. By the time the lead calls back fifteen minutes later, the spread is stopped. First call in the morning is the insurance carrier, per the plan, and their response team takes over the forensics before anyone wipes anything. The assessment shows which records were on the machine, the notification clock is understood from day one, and counsel is looped in that same day.
Same attacker, same night, same clinic. The only difference is one page of paper and the ten minutes it took to write it, months earlier.
The common ways practices get it wrong¶
Even practices that mean well tend to fail in the same handful of ways. Recognizing them is most of the fix.
- The plan lives only in one person’s head. If your whole incident response strategy is “we’ll call Dave, Dave knows the systems,” then your plan is on vacation whenever Dave is, and gone entirely the day Dave leaves. It has to be written and shared.
- The contact list is trapped in the locked system. The vendor numbers, the insurance policy, the after-hours cell numbers: if they live only in the email account or the drive that’s now encrypted or inaccessible, you can’t reach them precisely when you need them. Keep a printed copy somewhere physical.
- Backups were never actually tested. A backup you’ve never restored from is a hope, not a safeguard. Plenty of practices discover mid-incident that the backup has been silently failing for months, or that no one knows how to restore it.
- No pre-assigned roles. Without a named lead and clear jobs, everyone waits for someone else, or several people act at cross purposes. Confusion costs hours, and hours are what an attacker uses.
- The notification clock gets missed. Not knowing that HIPAA generally requires individual notification within 60 days of discovery, and that other clocks may be shorter, is how a manageable incident becomes a regulatory one.
- The plan was written once and never revisited. Systems change, staff change, vendors change. A plan naming a contractor you fired two years ago and a backup system you no longer use will fail you as surely as no plan at all.
What to actually do¶
You don’t need a consultant or a big budget to have a real plan. You need an afternoon and a willingness to answer some uncomfortable questions honestly.
Start by writing down the six steps for your specific practice, in plain language, on a single page. For each step, fill in the real names, real phone numbers, and real systems. Who is the designated lead. What’s the after-hours number. Which cabinet holds the good backup drive. This is the whole exercise, and it surfaces the gaps immediately: you’ll notice mid-page that you don’t actually know your insurance carrier’s claim number, or that nobody’s tested the backup.
Then assign the roles out loud, so the lead knows they’re the lead and the staff knows who to call. Make sure at least two people can reach the critical contacts, so the plan doesn’t hinge on one person’s phone.
Print it, and put the copies somewhere physical: taped inside a cabinet, in a binder at the front desk, a copy at the lead’s home. Assume during a real incident that your screens are dark and your email is locked, and make sure the plan survives that assumption.
Test the backup before you need it. Actually restore a file from it. If it fails, you’ve just learned the single most valuable thing on this list, on a calm day instead of a terrible one.
Finally, revisit the page a couple of times a year and after any real scare or major change. Ten minutes to update a phone number now saves you an hour of chaos later.
The one-page incident response plan template¶
Here’s the centerpiece: a fill-in-the-blank skeleton you can copy, complete, and print. Keep it to one page on purpose. If it’s longer than that, it won’t get used when it matters.
INCIDENT RESPONSE PLAN — [PRACTICE NAME]
Last updated: __________ Keep a PRINTED copy.
IF YOU SEE SOMETHING WRONG (ransom note, strange login, lost device,
email to wrong person): report it FAST, even if you're not sure.
── 1. DETECT & REPORT — call this person FIRST ──────────────────────
Incident Lead: ______________________ Cell (24/7): ____________
Backup Lead: ______________________ Cell (24/7): ____________
── 2. CONTAIN — stop the spread (do this immediately) ───────────────
[ ] Unplug the affected device's network cable / turn off its Wi-Fi
[ ] Leave the device POWERED ON (do not wipe, do not reinstall)
[ ] Do NOT log into the affected accounts
[ ] Note the time you noticed it: ____________
── 3. ASSESS — figure out the scope (write it down) ─────────────────
Which systems/accounts affected: _______________________________
Did it involve patient data / PHI? YES / NO / UNSURE
Roughly how many individuals: __________________________________
── 4. NOTIFY — make these calls (in this order) ─────────────────────
[ ] Cyber-insurance carrier: __________ Policy #: ____________
[ ] Legal counsel: ___________________ Phone: _______________
[ ] IT / security vendor: ____________ Phone: _______________
[ ] HIPAA breach notification: individuals within 60 days of
discovery; HHS per its rules. Confirm timelines with counsel.
[ ] Law enforcement (if advised): ______________________________
── 5. RECOVER — restore safely (only after 1–4) ─────────────────────
[ ] Restore from the TESTED backup — location: ________________
[ ] Reset all potentially exposed passwords
[ ] Do not reconnect a system until confirmed clean
── 6. REVIEW — within a week of resolution ──────────────────────────
[ ] What let it in? ____________________________________________
[ ] What slowed us down? _______________________________________
[ ] Update this page and re-print it.
KEY CONTACTS (also printed because email may be DOWN):
Insurance ______ Counsel ______ IT ______ EHR support ______
Fill every blank. The ones you can’t fill are your homework: a blank next to “tested backup location” or “insurance policy number” is telling you exactly where your plan would fail tonight.
Where to start if this feels like a lot¶
If you take one thing from this post, let it be that the plan has to exist before the bad night, because it is nearly impossible to write a good one during it. The version that saves you is short, printed, and boring, and it costs an afternoon to make.
Writing an incident response policy is also one of the compliance documents small practices most often lack entirely, right alongside the risk assessment. We include an Incident Response Policy as part of the compliance document stack we build for small practices, written in plain language and sized for a small team, not a hospital. If you’d rather just take the template above and fill it in yourself, please do; that’s a genuinely good use of an afternoon and you don’t need us for it.
And if you’re not sure where your practice stands, or you have a plan somewhere and want an honest read on whether it would actually hold up at 2 AM, email support@breachsecurity.io and tell us what you do and how many people are on staff. We’ll tell you what you actually need, even when the honest answer is “less than you feared.”