Every 39 seconds, a cyberattack targets a business somewhere in the world. And contrary to what many business owners assume, small and medium-sized businesses are not too small to be targets. They are, in fact, preferred targets. According to Verizon's Data Breach Investigations Report, 46% of all breaches affect businesses with fewer than 1,000 employees.
The difference between a minor security event and a catastrophic breach often comes down to one thing: how prepared you are to respond. An incident response plan is not just a document that sits in a binder collecting dust. It is the difference between containing a ransomware attack in hours versus watching it spread across your entire network over days.
This guide walks through everything an SMB needs to know about incident response, from understanding the fundamentals to building a plan, assembling a team, and learning from each incident to get stronger over time.
What Is Incident Response and Why SMBs Need a Plan
Incident response (IR) is the organized approach to detecting, containing, and recovering from cybersecurity events. It encompasses the people, processes, and technology that activate when something goes wrong, whether that is a phishing email that compromises an employee's credentials, ransomware encrypting your file server, or a data breach exposing customer records.
Many SMB leaders assume that incident response is something only large enterprises need. This assumption is dangerously wrong for several reasons.
SMBs face the same threats as large enterprises, but with fewer resources. Attackers use the same ransomware, the same phishing kits, and the same exploitation techniques against a 50-person company as they do against a Fortune 500. The difference is that the Fortune 500 has a security operations center staffed around the clock. Most SMBs do not.
The financial impact is proportionally higher. IBM's Cost of a Data Breach Report found that organizations with fewer than 500 employees had an average breach cost of $3.31 million. For a company with $10 million in annual revenue, that number can be existential. For a company with $500 million in revenue, it is a bad quarter.
Response time directly determines damage. Research consistently shows that organizations with incident response plans detect and contain breaches significantly faster. The longer an attacker maintains access to your network, the more data they exfiltrate, the more systems they compromise, and the more expensive the recovery becomes. IBM found that breaches contained in under 200 days cost an average of $1 million less than those that took longer.
Regulatory and contractual obligations increasingly require it. If your business handles healthcare data, payment card information, or personal data covered by state privacy laws, you likely have a legal obligation to maintain an incident response plan. Even outside of formal regulation, many enterprise customers now require their vendors to demonstrate incident response capabilities before signing contracts.
Having a plan does not guarantee a perfect outcome, but not having one virtually guarantees a worse one.
The NIST Incident Response Lifecycle
The National Institute of Standards and Technology (NIST) published Special Publication 800-61, the Computer Security Incident Handling Guide, which remains the gold standard for structuring incident response. The framework breaks response into four phases that cycle continuously.
Phase 1: Preparation
Preparation is where 80% of effective incident response happens. This phase covers everything you do before an incident occurs to ensure your team can respond effectively when it does.
Key preparation activities include:
- Documenting an incident response plan with clear roles, contact lists, and escalation procedures
- Establishing communication channels that work even if your primary systems are compromised (out-of-band communication)
- Deploying detection tools such as endpoint detection and response (EDR), security information and event management (SIEM), or managed detection and response (MDR) services
- Maintaining current network diagrams and asset inventories so responders know what they are protecting
- Ensuring backups are tested and isolated from your production network (so ransomware cannot encrypt them too)
- Training staff on recognizing security events and knowing who to call
- Establishing relationships with external resources such as IR consultants, legal counsel, and law enforcement contacts
The most common mistake in preparation is treating it as a one-time project. Threat landscapes change, staff turn over, and systems evolve. Preparation must be ongoing.
Phase 2: Detection and Analysis
This phase is about identifying that an incident is happening and understanding its scope and severity. It is often the most technically challenging phase because distinguishing genuine attacks from false alarms requires skill and context.
Detection typically comes from one of several sources:
- Automated alerts from security tools (EDR, SIEM, firewall logs, email gateway)
- User reports (an employee notices something unusual)
- External notification (a customer, partner, or law enforcement tells you that you have been compromised)
- Threat intelligence feeds (indicators of compromise matching your environment)
Once a potential incident is detected, the analysis phase involves answering critical questions: What systems are affected? What data is at risk? How did the attacker get in? Is the attack still ongoing? What is the business impact?
Severity classification matters here. Not every alert requires an all-hands response. A well-designed IR plan defines severity levels (often 1 through 4) with corresponding response procedures. A single phishing email that was caught by your email filter is very different from an active ransomware infection spreading across your network.
Phase 3: Containment, Eradication, and Recovery
Once you understand what you are dealing with, you need to stop the bleeding, remove the threat, and restore normal operations.
Containment aims to limit the damage. Short-term containment might involve isolating an infected workstation from the network or disabling a compromised user account. Long-term containment involves more sustainable measures while you work on eradication, such as implementing network segmentation or blocking specific IP addresses at the firewall.
A critical containment decision that many teams get wrong: do you shut down the affected system immediately or keep it running to gather evidence? The answer depends on the situation, and your IR plan should provide guidance for different scenarios.
Eradication removes the threat from your environment entirely. This might involve reimaging compromised systems, removing malware, patching the vulnerability that was exploited, resetting credentials, or revoking compromised certificates. Eradication must be thorough. If you remove ransomware from one system but the attacker still has a backdoor on another, you will be back where you started within days.
Recovery brings systems back to normal operations. This includes restoring from backups, rebuilding systems, verifying that restored systems are clean, and monitoring closely for signs that the attacker is attempting to re-enter. Recovery should be phased, bringing critical business systems online first and monitoring carefully before expanding.
Phase 4: Post-Incident Activity
This is the phase that most organizations skip, and it is arguably the most valuable. After the immediate crisis is resolved, a structured review captures what happened, what worked, what failed, and what needs to change.
The post-incident review (sometimes called a "lessons learned" meeting or retrospective) should happen within one to two weeks of incident closure, while memories are fresh. More on this in a dedicated section below.
Building an Incident Response Team
You do not need a large team to have effective incident response, but you do need clearly defined roles.
Core Roles
Incident Commander (IC): The single point of authority during an incident. The IC makes decisions about containment actions, coordinates the team, manages communication, and decides when to escalate. In an SMB, this is often the IT director or a senior technical leader.
Technical Lead: Handles the technical investigation, containment actions, and recovery. This person needs hands-on access to systems and the skills to analyze logs, isolate systems, and remove threats. In smaller organizations, the IC and technical lead may be the same person, though this is not ideal during complex incidents.
Communications Lead: Manages internal and external communications, including updates to leadership, notifications to affected customers, and coordination with legal counsel. In an SMB, this is often someone from the executive team or operations.
Scribe/Documenter: Records all actions taken, decisions made, and timeline events. This documentation is essential for post-incident review, legal proceedings, regulatory reporting, and insurance claims. During a chaotic incident, this role is easy to neglect but critically important.
When to Outsource
Most SMBs cannot afford to maintain a fully staffed incident response team internally, and they do not need to. The decision of what to handle in-house versus what to outsource should be based on a realistic assessment of your team's capabilities.
Keep in-house: Incident detection (you know your environment best), initial triage and severity classification, internal communications, business continuity decisions, and the incident commander role.
Consider outsourcing: Digital forensics (requires specialized tools and training), malware analysis, legal notification requirements, threat hunting, and 24/7 monitoring.
The key to effective outsourcing is establishing the relationship before you need it. If the first time you call an IR firm is during an active breach, you lose critical hours to contracts, onboarding, and environment familiarization.
Creating an Incident Response Plan
An incident response plan does not need to be a 200-page document. In fact, overly long plans tend to be ignored during actual incidents. Aim for a plan that is comprehensive but usable under pressure.
Essential Components
Purpose and scope: What types of incidents does the plan cover? What systems and data are in scope? What constitutes an "incident" versus a routine IT issue?
Roles and responsibilities: Who does what during an incident? Include names, titles, and contact information. Define an escalation path when primary contacts are unavailable.
Severity classification: Define 3-4 severity levels with clear criteria and corresponding response expectations. For example:
- Severity 1 (Critical): Active data exfiltration, ransomware spreading, or systems critical to business operations are down. All-hands response, executive notification within 1 hour.
- Severity 2 (High): Confirmed compromise of a single system or user account, potential data exposure. IR team activation, management notification within 4 hours.
- Severity 3 (Medium): Suspicious activity under investigation, phishing email with credentials entered but no confirmed compromise. Technical team investigation, notification if confirmed.
- Severity 4 (Low): Blocked attack attempts, policy violations, minor security events. Logged and reviewed during normal business hours.
Contact lists: Internal IR team, external IR retainer (if applicable), legal counsel, cyber insurance carrier, law enforcement, regulatory bodies, and key vendors. Keep this on paper or in a system that is accessible even if your network is down.
Communication plan: Templates for internal updates, customer notifications, and regulatory reports. Pre-approved language saves precious time during a crisis.
Incident-specific playbooks: Step-by-step procedures for your most likely scenarios (more on this below).
Evidence handling procedures: How to preserve logs, disk images, and network captures for potential legal or insurance use.
Regulatory requirements: Notification timelines and requirements specific to your industry and jurisdiction.
Common Incident Types SMBs Face
Understanding the threats you are most likely to encounter helps you prioritize your preparation efforts.
Ransomware
Ransomware remains the most financially damaging threat to SMBs. Attackers encrypt your files and demand payment for the decryption key, often with a deadline after which they threaten to publish stolen data (double extortion).
What makes ransomware particularly devastating for SMBs: many lack adequate backup strategies, so they face a choice between paying the ransom (with no guarantee of recovery) or losing their data entirely. Prevention is ideal, but your IR plan needs a clear playbook for when prevention fails.
Key response decisions include: Do you pay? (Generally, experts and law enforcement advise against it.) Are your backups intact and clean? Can you operate manually while systems are restored? Who needs to be notified?
Business Email Compromise (BEC)
BEC attacks do not require any malware. An attacker compromises or impersonates an executive's email account and sends fraudulent requests, typically wire transfers, invoice payments, or sensitive data. The FBI's Internet Crime Complaint Center consistently ranks BEC as the highest-loss cybercrime category, with billions in losses annually.
BEC response requires immediate coordination between IT (to secure the compromised account and investigate scope), finance (to attempt to recall fraudulent transfers), and legal counsel.
Data Breach
A data breach occurs when unauthorized parties access sensitive information, whether customer records, employee data, intellectual property, or financial information. Breaches can result from external attacks, insider actions, or simple misconfiguration (such as a cloud storage bucket left publicly accessible).
The response to a data breach is heavily influenced by regulatory requirements. Depending on what data was exposed and where your customers are located, you may have notification obligations under HIPAA, state privacy laws, GDPR, PCI-DSS, or other frameworks. Timelines for notification can be as short as 72 hours.
Insider Threats
Not all incidents come from external attackers. Insider threats include malicious employees (stealing data before leaving the company), negligent employees (accidentally emailing sensitive data to the wrong person), and compromised employees (whose credentials are being used by an external attacker).
Insider threat incidents are particularly sensitive because they involve HR, legal, and potentially law enforcement considerations that differ from external attack response.
Tabletop Exercises and Why They Matter
A tabletop exercise is a structured discussion-based simulation where your IR team walks through a hypothetical incident scenario. No systems are touched. No actual attacks are simulated. The team simply talks through what they would do, step by step.
Tabletop exercises are the single most effective way to improve incident response readiness, and they are surprisingly underutilized.
How a Tabletop Exercise Works
A facilitator presents a scenario in stages. For example:
- Stage 1: "It is 2:00 PM on a Friday. An employee in accounting reports that all files on the shared drive show a .locked extension and there is a text file demanding payment in Bitcoin. What do you do?"
- Stage 2: "You have isolated the accounting department's network segment. However, you are now receiving reports from two other departments that their files are also encrypted. The attacker appears to have domain admin credentials."
- Stage 3: "The attacker has contacted your CEO directly via email, threatening to publish customer financial data on a leak site within 48 hours unless payment is made."
At each stage, participants discuss their actions, decisions, and concerns. The facilitator introduces complications and asks probing questions.
What Tabletop Exercises Reveal
These exercises consistently uncover gaps that are invisible on paper:
- Contact list problems: Key phone numbers are wrong or people have left the company
- Authority gaps: Nobody knows who has the authority to take systems offline or approve emergency spending
- Communication breakdowns: The plan says to "notify legal counsel" but nobody knows who the firm is or has the phone number
- Technical blind spots: The team discovers they cannot isolate a network segment without taking down a critical system
- Backup assumptions: Everyone assumed backups were working, but nobody has tested a restore in months
Run tabletop exercises at least annually, and ideally quarterly. Vary the scenarios to cover different incident types. Include non-technical stakeholders such as executives, legal, HR, and communications.
Communication During an Incident
Poor communication during an incident amplifies the damage. Clear, structured communication reduces confusion and helps coordinate an effective response.
Internal Communication
Establish an out-of-band channel before you need one. If your corporate email or Slack is compromised, you need an alternative. Options include a pre-configured group text chain, a separate messaging platform, or even a conference bridge. The important thing is that everyone on the IR team knows how to access it.
Use structured status updates. During an incident, provide regular updates at defined intervals (such as every hour for a Severity 1 incident) even if there is nothing new to report. Updates should include: current situation summary, actions in progress, actions completed, next steps, and estimated time to next update.
Control information flow. Not everyone in the organization needs to know everything. Define who gets what level of detail. All-staff communications should focus on what employees need to do (or stop doing), not the technical details of the attack.
Customer and External Communication
Timing and tone matter enormously when communicating a breach to customers. General principles:
- Be honest. Vague or evasive statements destroy trust faster than the breach itself.
- Communicate what you know, acknowledge what you do not, and explain what you are doing to find out. Saying "we are still investigating the full scope" is better than saying nothing or making premature claims.
- Focus on what affected individuals should do. Offer concrete protective steps (change passwords, monitor accounts, etc.).
- Do not delay notification to manage the message. Customers and regulators react more negatively to late notification than to early notification with incomplete information.
Legal and Law Enforcement
Involve legal counsel early. Attorney-client privilege can protect incident investigation findings from disclosure in litigation. Your attorney can also help navigate notification requirements and regulatory obligations.
Reporting to law enforcement (typically the FBI for cyber incidents in the United States) is generally recommended and sometimes required. Law enforcement agencies can provide threat intelligence, connect you with decryption tools for known ransomware variants, and help identify attackers. Contrary to common concern, reporting an incident to law enforcement does not automatically result in public disclosure.
Post-Incident Review and Lessons Learned
The post-incident review is where organizations turn costly incidents into lasting improvements. Skip this step and you are likely to repeat the same mistakes.
Conducting the Review
Hold the review within 7 to 14 days of incident closure. Include all participants in the response, not just the technical team. The meeting should be blameless. The goal is to improve processes, not to assign fault.
Structure the discussion around these questions:
- What happened? Build a complete timeline from initial detection to resolution.
- What went well? Identify actions and decisions that were effective so they can be reinforced.
- What could be improved? Identify gaps, delays, and points of confusion without blaming individuals.
- What were the root causes? Go beyond the immediate vulnerability to understand systemic factors. Why was the vulnerability present? Why was it not detected sooner?
- What specific changes will we make? Turn findings into concrete action items with owners and deadlines. "Improve backup procedures" is not actionable. "IT director will implement daily backup verification testing by March 15" is.
Documenting the Findings
Produce a written incident report that includes the timeline, impact assessment, root cause analysis, and action items. This document serves multiple purposes: it informs future IR plan updates, supports insurance claims, demonstrates regulatory compliance, and provides institutional knowledge when team members change.
Track action items to completion. The most common failure mode in post-incident activity is generating a good list of improvements and then never implementing them.
Retainer vs. Break-Fix: How IR Engagement Models Work
When SMBs engage external incident response help, there are two basic models, and understanding the difference can save significant time and money during a crisis.
Break-Fix (Emergency Engagement)
In this model, you call an IR firm when an incident occurs with no prior relationship. The firm assesses your situation, negotiates terms, and begins work.
Advantages: No ongoing cost. You only pay when you need help.
Disadvantages: Responders are unfamiliar with your environment, which adds hours to the investigation. Contracting and procurement take time during a crisis. IR firms may be at capacity and unable to take your case, especially during widespread attacks (like the wave of MOVEit exploits in 2023, when IR firms turned away clients for weeks). Hourly rates for emergency engagements are typically 2-3x higher than retainer rates.
Retainer Model
In this model, you pay a monthly or annual fee to an IR firm. In exchange, you get guaranteed response times, pre-negotiated rates, and proactive preparation work (plan development, tabletop exercises, environment familiarization).
Advantages: Faster response because the firm already knows your environment. Guaranteed availability. Lower per-hour rates. Proactive preparation improves your overall security posture. Some retainers include a bank of pre-purchased hours that can be used flexibly.
Disadvantages: Ongoing cost regardless of whether you have an incident. Requires selecting and committing to a provider.
Which Model Fits?
The retainer model generally makes sense when the cost of slow response (lost revenue, regulatory fines, reputational damage) exceeds the annual retainer cost. For businesses with regulatory obligations, valuable data assets, or limited internal security expertise, a retainer is typically the better investment. For very small businesses with limited digital footprints and low-sensitivity data, a break-fix approach combined with a strong internal IR plan may be sufficient.
Regardless of which model you choose, the worst option is having no plan and no relationship with an IR provider. That combination maximizes both response time and cost.
Common IR Mistakes That Increase Damage
Learning from others' mistakes is cheaper than learning from your own. These are the errors that incident responders see repeatedly, and each one makes a bad situation worse.
1. Wiping Systems Before Collecting Evidence
The instinct to "just wipe it and start fresh" is understandable but can be catastrophic. Without forensic evidence, you cannot determine what data was accessed, how the attacker got in (meaning they may get in the same way again), or provide the documentation needed for insurance claims and regulatory reporting. Always image affected systems before wiping them.
2. Communicating Over Compromised Channels
If an attacker has access to your email system, discussing your response strategy over email tells them exactly what you are doing. Many organizations have been burned by discussing containment plans in emails that the attacker was actively monitoring. Use out-of-band communication from the start.
3. Neglecting to Reset All Compromised Credentials
After a breach involving credential theft, organizations often reset the obviously compromised accounts but miss service accounts, API keys, or secondary accounts. Attackers routinely harvest credentials broadly and use lesser-known accounts for persistence. A thorough credential reset across all potentially exposed accounts is essential.
4. Declaring Victory Too Early
The pressure to return to normal operations drives teams to declare an incident resolved before eradication is complete. Sophisticated attackers plant multiple backdoors and persistence mechanisms. If you find one method of access, assume there are more. Monitor closely for weeks after you believe the incident is resolved.
5. Not Preserving Chain of Custody
If there is any possibility that the incident will involve legal proceedings, insurance claims, or regulatory investigation, evidence handling matters. Logs, disk images, and network captures must be collected and stored in a way that maintains their integrity. Once evidence is contaminated or lost, it cannot be recovered.
6. Failing to Notify Cyber Insurance Early
Most cyber insurance policies have strict notification requirements, often within 24 to 72 hours of discovering an incident. Late notification can jeopardize your coverage. Additionally, many policies require you to use the insurer's approved IR firms, and engaging a non-approved firm may not be covered. Review your policy before you need it and include insurance notification in your IR plan.
7. Skipping the Post-Incident Review
When the crisis is over, the team is exhausted and eager to move on. Skipping the post-incident review means the organization learns nothing from the experience and remains vulnerable to the same failures. Make the review a mandatory part of incident closure.
8. Treating the IR Plan as a Static Document
An incident response plan that was written two years ago and never updated is only marginally better than no plan at all. Staff change, systems change, threats change, and regulatory requirements change. Review and update your plan at least annually, and after every significant incident.
9. Not Involving Legal Counsel Early Enough
Organizations sometimes delay involving attorneys until they realize the incident has legal implications. By that point, investigation findings may not be protected by privilege, and notification deadlines may have already passed. Involve legal counsel at the beginning of any incident that might involve data exposure, regulatory obligations, or third-party impact.
10. Assuming It Will Not Happen to You
The single most damaging mistake is the belief that your organization is too small, too obscure, or too uninteresting to be targeted. Automated attacks do not discriminate by company size. Phishing campaigns target email addresses indiscriminately. Ransomware operators scan for vulnerabilities across the entire internet. The question is not whether you will face a security incident, but when.
Getting Started
Building incident response capabilities is a process, not a project. If you are starting from scratch, here is a practical sequence:
- Identify your crown jewels. What data and systems would cause the most damage if compromised? This focuses your preparation efforts.
- Draft a basic IR plan. Start with roles, contact lists, severity levels, and escalation procedures. It does not need to be perfect. A basic plan is infinitely better than no plan.
- Develop playbooks for your top threats. For most SMBs, start with ransomware and business email compromise. Add more scenarios over time.
- Run a tabletop exercise. Walk through your ransomware playbook with your team. Document the gaps you find.
- Fix the gaps. Update the plan based on what the exercise revealed.
- Establish external relationships. Identify legal counsel with cyber expertise, evaluate IR retainer options, and review your cyber insurance policy.
- Train your staff. Everyone in the organization should know how to recognize and report a potential security incident.
- Repeat. Review the plan quarterly. Run exercises at least annually. Update contact lists whenever staff change.
The organizations that weather cyber incidents successfully are not the ones with the biggest budgets or the most advanced technology. They are the ones that prepared, practiced, and learned from every event. That capability is available to any business willing to invest the time.