An incident response plan is required under HIPAA, required under the FTC Safeguards Rule, asked about on every cyber insurance application, and requested in most client security questionnaires.
It is also genuinely useful, which is easy to forget given how often it is written to satisfy an auditor. The purpose is to remove decisions from the moment when people are stressed, tired and working with incomplete information.
A good plan for a small business is short. Twenty usable pages beat a hundred nobody opens.
Who does what
Name people, with deputies, because incidents happen while people are on holiday.
- Incident lead — coordinates the response and makes operational calls. Usually an owner or operations lead, not necessarily technical.
- Technical lead — your IT provider or internal IT. The person who actually investigates and contains.
- Legal — external counsel, ideally identified in advance rather than found during an incident.
- Communications — who speaks to clients, staff and, if needed, media. One voice.
- Executive sponsor — authority to approve spending and make business decisions without a meeting.
That last role is the one most often omitted and most often needed. Incidents stall waiting for someone who can authorise an emergency engagement, approve overtime, or decide to take a system offline. Name that person and name their deputy.
Severity levels and what triggers them
Define severity by impact, and state what each level activates:
- Critical — confirmed compromise of sensitive data, ransomware, or business-wide outage. Full team activated, insurer notified, counsel engaged.
- High — suspected compromise, single account takeover, malware on a system holding sensitive data. Technical lead plus incident lead, insurer notified if compromise is confirmed.
- Medium — isolated malware detection, suspicious activity requiring investigation, a phishing email that was clicked.
- Low — blocked attempts, reported phishing that nobody actioned.
The important detail is who declares severity and how anyone raises a concern out of hours. A plan that depends on someone recognising an incident correctly at 11pm should make escalation the safe default.
The contact list
The most-used page in any real incident, and the one most likely to be out of date.
- Internal team members with mobile numbers, not just email
- IT provider, including the out-of-hours emergency number specifically
- Cyber insurance carrier, policy number, and the claims notification number
- Legal counsel
- Key vendors — cloud platform support, payment processor, EHR or practice management vendor, with account numbers
- Regulatory contacts relevant to your obligations
- Law enforcement — local FBI field office for significant incidents
Keep a printed copy. In a ransomware incident your email, files and phone system may all be unavailable, and a contact list stored only in those systems is unreachable exactly when you need it.
Procedures worth writing down
Keep them to checklists rather than prose. The two that earn their place immediately:
Containment — isolate rather than power down, disable accounts and terminate sessions, preserve logs, start the timeline. Written plainly, because the instinct under pressure is to power everything off.
Notification decision — a short flowchart. What data was involved, whose, how many, which regimes apply, what the deadline is, who decides. This is the part that goes wrong under pressure, because deadlines run from discovery and nobody wants to start the clock.
Beyond those, brief procedures for the scenarios most likely to affect you: ransomware, business email compromise, lost or stolen device, and a compromised vendor.
Decisions to make now, not then
Some decisions are far better made calmly:
- Will you consider paying a ransom, and who decides? Even a provisional position prevents that debate happening during the crisis.
- At what point do you take systems offline, accepting the business impact?
- Who can authorise emergency spending, and up to what limit?
- What is your position on public disclosure beyond legal requirements?
- Who is the single spokesperson?
Testing without a full exercise
A plan nobody has tested is a document. Testing does not require a formal simulation:
- A tabletop discussion — ninety minutes, a scenario, walk through who does what. This alone surfaces most gaps.
- A contact list check — actually call the out-of-hours numbers. They are wrong more often than anyone expects.
- A restore test — the most valuable single exercise, because it tests the capability everything else depends on.
- A notification dry run — given a scenario, work out what you would be obliged to do and by when.
Annually is a reasonable cadence, and after any material change to the business. Document that you did it — insurers and auditors ask, and the record is part of what demonstrates the plan is real.
Keeping it current
Plans decay quietly. People leave, providers change, phone numbers change, systems get replaced. Review at least annually and whenever any of those happen.
The most common failure mode is not a bad plan — it is a good plan describing an organisation that no longer exists. A short plan that is accurate is worth considerably more than a thorough one that is two reorganisations out of date.