Incident response is one of those topics that nearly every small business owner acknowledges as important and almost none address before an incident forces the issue. The pattern is consistent: a ransomware infection, a phishing compromise, an employee data exfiltration — and the first question from leadership is "what do we do now?" followed immediately by the realization that no one has a documented answer.
This is not a failure of intention. It is a failure of prioritization. Incident response planning feels like a future problem, right up until it is not.
What follows is a practical framework for small businesses to build incident response capability before they need it — without overengineering the effort or producing documentation that no one will use.
What Incident Response Actually Means at the SMB Scale
Large enterprises have security operations centers, dedicated incident response teams, and detailed playbooks for dozens of specific attack scenarios. Small businesses have none of that, and they do not need most of it.
What a small business does need is the ability to answer four questions quickly when something goes wrong:
- What happened and what systems are affected?
- Who needs to be notified and who is responsible for what?
- How do we contain the damage and stop it from getting worse?
- How do we restore normal operations and document what occurred?
An effective incident response plan for a small business is primarily a set of pre-made decisions — answers to questions that would otherwise be improvised under pressure, at the worst possible moment.
The Most Common SMB Incidents
Understanding the threat landscape helps with planning. The incidents small businesses actually experience, in rough order of frequency, are:
Phishing and business email compromise. An employee clicks a malicious link or attachment, or an attacker impersonates an executive to redirect a wire payment. BEC attacks cost small businesses more money than any other attack category.
Ransomware. Files are encrypted, operations halt, and a demand appears. Recovery without paying the ransom requires backups that work — a capability many organizations discover they lack only after an infection.
Credential compromise. An employee's login credentials (typically from a password reuse breach at another site) are used to access business systems — cloud storage, email, financial applications.
Insider incidents. A departing employee copies sensitive data. An accident exposes customer records. Insider incidents are frequently accidental but the response process is similar to malicious cases.
Vendor or supply chain compromise. A software vendor or managed service provider is breached, and the attacker uses that access to reach your systems.
What to Have in Place Before an Incident
1. A Contact Sheet
Before anything else, you need a document that lists who to call and what information they will need. This includes:
- Your internal decision-makers (owner/CEO, IT contact, finance/legal if applicable)
- Your cyber insurance carrier and the claims number — keep this printed and accessible offline
- Your outside legal counsel if you have one (especially for breach notification obligations)
- Your IT vendor or MSP
- A forensics/IR firm if you have one pre-engaged (your insurer may require or provide this)
- The FBI's Internet Crime Complaint Center (IC3) and your local FBI field office, for significant incidents
This contact sheet should exist in print, not only digitally. If your systems are down, you need to be able to reach people.
2. Defined Decision Authority
Who is authorized to take systems offline? Who decides whether to pay a ransom? Who approves public communications? Who is allowed to talk to law enforcement?
These decisions are difficult under pressure. Making them in advance — and documenting who has authority for each — prevents conflicting actions during an active incident and ensures that consequential choices are not made ad-hoc by whoever happens to be in the room.
3. A Simple Triage Process
When something suspicious is reported, the first two questions are: is this an actual incident, and how severe is it? A rough triage process that most SMBs can implement:
Low severity: Suspected phishing email that has not been clicked, unusual but non-malicious login, policy violation without apparent compromise. Handle internally, document, and monitor.
Medium severity: Confirmed malicious click with no apparent lateral movement, single account compromise, malware detected and contained. Activate IT response, notify leadership, document thoroughly.
High severity: Ransomware, confirmed data exfiltration, active attacker presence on the network, BEC resulting in financial loss. Activate full response plan, notify insurance carrier immediately, consider legal counsel involvement, preserve evidence.
The categories and thresholds can be adjusted to fit your organization. The goal is to have a shared vocabulary so that "severity" means the same thing to everyone.
4. A Containment Checklist
For each severity tier, having pre-defined containment steps prevents improvisation. For high-severity incidents, a starting checklist typically includes:
- Isolate affected systems from the network without powering them down (unless instructed otherwise by forensics)
- Revoke or reset credentials for compromised accounts
- Preserve logs — do not clear or overwrite system logs
- Document everything: what you did, when you did it, and what you observed
- Do not communicate through systems that may be compromised
This last point is frequently overlooked. If your email may be compromised, communicating about the incident over email potentially notifies the attacker of your response actions.
5. Working Backups
An incident response plan for ransomware that does not include tested backups is not a plan — it is a decision to pay or to lose data. Backup requirements for incident response purposes:
- Backups are stored offline or in an immutable cloud environment (not connected to the same infrastructure that could be encrypted)
- Backup restoration has been tested within the last 90 days, not just assumed to work
- Recovery time objectives are understood — how long will it take to restore critical systems from backup?
If you have not tested your backups recently, do that before anything else.
6. A Communication Template
When an incident occurs, you will need to communicate with employees, customers, and potentially regulators. Drafting communication templates in advance allows you to act quickly without improvising under pressure.
Basic templates to have ready:
- Internal employee notification (incident is being investigated, what employees should/should not do)
- Customer notification if data is involved (check your breach notification obligations by state — many jurisdictions require notification within 30-72 hours of discovery)
- Vendor/partner notification if your systems connect to theirs
Breach Notification Obligations
Most U.S. states have breach notification laws that require notifying affected individuals within a defined period after discovering a breach involving personal information. The specific requirements vary by state — covered data types, notification deadlines, content requirements, and whether regulators must be notified directly.
If you handle personal data for California residents, you are subject to CCPA. If you process health information, HIPAA applies. If you handle financial data, state-level financial privacy laws may apply.
Understanding your notification obligations before an incident means you are not scrambling to interpret statutes in the middle of managing a crisis. Legal counsel familiar with data breach response is worth engaging proactively if you handle significant volumes of personal data.
Testing Your Plan
A plan that has never been exercised is a plan that will fail under pressure. The minimum viable test for a small business is a tabletop exercise: gather the relevant people, walk through a hypothetical scenario, and talk through the responses.
A 90-minute tabletop covering a ransomware scenario will surface gaps that no amount of document review identifies — typically, disagreements about authority, missing contact information, and dependencies that were not documented.
Run the exercise annually at minimum, and after any significant change to systems, vendors, or personnel.
Where to Start
If you have no incident response plan today, the highest-value first step is not writing a lengthy policy document. It is producing the contact sheet and the decision authority list. Get those two things documented, printed, and accessible, and you have meaningfully reduced the worst outcomes from a high-severity incident.
A Digital Fortress Audit includes incident response readiness as part of its scope and delivers a prioritized remediation plan. If you want to understand your current posture before investing in building out a full program, that is the right starting point.
The cost of planning is measured in hours. The cost of improvising during an active incident is measured in much larger units.