Basic Incident Response Plan for SMBs: A Simple Guide

Every small business owner needs a basic incident response plan (SMB) — yet most don’t have one, and that gap is exactly what cybercriminals are counting on. Studies consistently show that 60% of small businesses close within six months of a major cyberattack. That’s not a scare tactic. That’s the cost of being unprepared.

Small businesses are no longer flying under the radar. Attackers actively target SMBs because they tend to have weaker defenses than large enterprises but still hold valuable customer data, payment information, and business records. Ransomware, phishing, and account takeovers have all spiked dramatically in recent years — and small teams are bearing the brunt.

The good news: you don’t need a dedicated security operations center or a six-figure budget to respond effectively. What you need is a clear, documented plan your team can actually follow when things go sideways. This guide walks you through every phase of a basic incident response plan built specifically for small teams — from building your response crew to recovering clean systems and learning from what happened.

What Is a Basic Incident Response Plan?

A basic incident response plan (IRP) is a documented, step-by-step framework that tells your team exactly what to do when a cybersecurity incident hits. Think of it as a fire drill for your business data — everyone knows their role, knows where to go, and knows what not to touch.

Enterprise companies build sprawling IRPs with dedicated security teams and expensive tooling. SMBs don’t need that. What works for a 500-person company is overkill — and often unusable — for a team of 10. A simplified IRP focuses on clarity, speed, and coordination rather than complexity.

A solid basic incident response plan follows six core phases, inspired by the NIST Cybersecurity Framework:

1. Preparation — Build your team, tools, and playbooks before anything goes wrong
2. Detection — Identify that an incident is actually occurring
3. Containment — Stop the spread without destroying evidence
4. Eradication — Remove the threat completely
5. Recovery — Restore clean systems and resume operations
6. Post-Incident Review — Learn what happened and improve your defenses

The goal isn’t a perfect response. It’s a fast, coordinated one. A plan that’s 80% right and actually executed beats a flawless plan that sits in a drawer every single time.

Preparation: Building Your Incident Response Team and Toolkit

Preparation is where SMBs gain the most advantage. Every hour you invest before an incident can cut hours — or days — off your response when one hits. This phase is about getting the right people, tools, and documents in place so you’re not making decisions under fire.

Assign Your Incident Response Team Roles

Your Incident Response Team (IRT) doesn’t need to be large. It needs to be clear. Assign these roles to real people before any incident occurs:

• Incident Commander (IC): The decision-maker. This person declares incidents, coordinates the team, and keeps the response moving. Often the business owner or IT manager.
• Technical Lead: Handles the hands-on work — isolating systems, analyzing logs, removing malware. Could be your IT staff or your managed service provider (MSP).
• Communications Lead: Manages internal updates, customer notifications, and any public statements. Keeps everyone informed without creating panic.
• Legal/Compliance Liaison: Guides breach notification decisions, reviews any external communications, and coordinates with cyber insurance.

In a small business, one person might wear two hats. That’s fine — just make sure those hats are clearly labeled before the fire starts.

Build Your Asset Inventory and Contact Matrix

You can’t protect what you can’t see. Document your critical systems — servers, workstations, cloud accounts, point-of-sale systems — and rank them by business impact. If your payment system goes down, what breaks first?

Alongside that, build a contact matrix: a single document listing emergency contacts for your MSP, cyber insurance provider, key vendors, the FBI’s Internet Crime Complaint Center (IC3), and any legal counsel. This lives offline — printed and stored somewhere accessible even if your network is down.

Set Up Your Foundational Security Tools

You don’t need enterprise security software. You do need these basics:

• Endpoint protection on every device (antivirus/EDR)
• Multi-factor authentication (MFA) on all accounts, especially email and cloud services
• Immutable backups stored offline or in a separate environment that ransomware can’t reach
• Basic logging and alerts — even simple SIEM tools or your cloud provider’s built-in monitoring can flag unusual logins or traffic spikes

Train Your Team and Run Tabletop Exercises

Train every employee to recognize phishing emails and report suspicious activity immediately. A single clicked link can trigger a full-scale breach. Run quarterly tabletop exercises — simplified walk-throughs of a simulated incident — so your team knows their roles before an actual event. These don’t need to be elaborate. An hour of “what would we do if ransomware hit right now?” builds more readiness than any policy document alone.

Detection and Severity Classification

Detection means recognizing that something is actually wrong — not assuming every alert is a false alarm, and not panicking over every anomaly. The goal is fast, accurate identification so you can act before damage spreads.

Common Detection Triggers

Train your team to watch for and immediately report these warning signs:

• Unusual login attempts or logins from unexpected locations
• Unexpected MFA prompts (someone may be trying to access an account)
• Outbound network traffic spikes at odd hours
• Files suddenly encrypted or renamed with strange extensions
• Employee reports of locked accounts or inaccessible systems

Any of these triggers should kick off your formal detection process — not wait-and-see.

Severity Levels: SEV-1 Through SEV-4

Not every alert is a crisis. Classifying severity helps you allocate the right response without burning out your team on false positives. A straightforward SMB severity model looks like this:

• SEV-1 (Critical): Active ransomware, data exfiltration, system-wide outage. All-hands response, status updates every 30 minutes, IC takes command immediately.
• SEV-2 (High): Confirmed account compromise, phishing campaign with clicks, isolated malware. Rapid response within hours, hourly updates.
• SEV-3 (Medium): Suspicious activity under investigation, single affected endpoint. Response within the business day, periodic updates.
• SEV-4 (Low): False positives, minor anomalies with no confirmed threat. Logged and reviewed weekly.

Declaring an Incident

When detection confirms a real event, formally declare an incident. This isn’t bureaucratic — it’s the trigger that activates your IRT. Use a phone tree, your ticketing system, or a group message in your communications platform. Assign the IC immediately. Document the time, the trigger, and the initial severity classification. Everything that follows should be logged in real time.

Containment, Eradication, and Recovery

These three phases are the operational core of your basic incident response plan for SMB scenarios. Speed matters here, but so does precision — moving too fast can destroy evidence or make the situation worse.

Containment: Stop the Spread

Containment means cutting off the attacker’s ability to move further through your systems without wiping out the evidence you’ll need later. Act immediately:

• Isolate affected endpoints — disconnect from the network, but don’t power them off
• Disable compromised user accounts
• Revoke active sessions and reset credentials for affected systems
• Preserve evidence: take snapshots, export logs, and document everything you see

Don’t wait for certainty before isolating. If a system looks compromised, treat it as compromised. You can reconnect it later; you can’t undo data exfiltration.

Eradication: Remove the Threat

Eradication means the threat is completely gone — not just quiet. This includes removing malware, closing the attack vector that was exploited, and patching any vulnerabilities identified during the incident. Your technical lead handles this phase, ideally with support from your MSP. Don’t skip this step and jump to recovery. Restoring systems while the attacker still has access just means getting hit again.

Recovery: Restore Clean, Then Reconnect

The principle here is simple: restore clean, then reconnect. Rebuild or restore systems from verified clean backups. Validate integrity before bringing anything back online. Test critical functions before resuming normal operations.

Pre-built playbooks for your top SMB threat scenarios — ransomware, phishing, account takeover — dramatically speed up this phase. You’re following a tested checklist, not improvising under pressure. If you don’t have playbooks yet, building them is your highest-priority preparation task. You can find a starting framework through resources like CISA’s Ransomware Guide.

Communication, Notification, and Legal Obligations

How you communicate during an incident matters as much as how you contain it. Silence breeds rumors internally and liability externally. Overcommunicating the wrong thing can make a bad situation worse. Prepare your communication strategy before you ever need it.

Internal and External Communication Templates

Draft templates in advance for three scenarios: notifying employees, notifying customers, and communicating with vendors or partners. These don’t need to be long — a clear, calm message explaining what happened, what you’re doing, and what affected parties should do is all you need. Your communications lead manages these during an active incident so the IC can stay focused on the response itself.

Know Your Regulatory Notification Deadlines

Depending on your industry and location, you may have legal obligations to notify regulators, customers, or both — and on a specific timeline. Key requirements to know:

• HIPAA: Notify affected individuals within 60 days of discovering a breach of protected health information
• State breach notification laws: Most U.S. states have their own timelines, ranging from 30 to 90 days — check your state’s specific law
• PCI DSS: If cardholder data is involved, notify your payment card brands and acquiring bank immediately

Involve Legal Counsel Early

Loop in your legal/compliance liaison from the moment you declare a SEV-1 or SEV-2 incident. Legal counsel helps you understand what you’re required to disclose, guides the language of any public statements, and protects you from inadvertently creating additional liability. This isn’t optional if your business handles sensitive customer data.

Also confirm with your cyber insurance provider what documentation they require and what notification procedures you’re obligated to follow under your policy. Many policies require you to notify the insurer within a specific window — missing that window can jeopardize your coverage. Check your cyber insurance policy requirements before an incident occurs.

Post-Incident Review and Continuous Improvement

A basic incident response plan for SMBs doesn’t end when systems are back online. The post-incident review is where the real long-term value gets created — turning a painful experience into a stronger defense.

Hold a Blameless Postmortem

Within five business days of resolving the incident, gather your IRT for a structured review. The word “blameless” is intentional: the goal is to understand what happened systemically, not to assign fault. Ask:

• What was the root cause?
• How did we detect it, and how could we have detected it faster?
• What did we do well? What slowed us down?
• What needs to change in our plan, tools, or training?

Track Your Key Metrics

Two numbers tell you most of what you need to know about response effectiveness. Mean Time to Detect (MTTD) measures how long it took from the start of the incident to the moment your team identified it. Mean Time to Respond (MTTR) measures how long from detection to containment. Track these after every incident and set targets to improve them over time.

Update Your Runbooks and Schedule Follow-Up Testing

Assign remediation tasks to specific owners with hard deadlines — not “someone will handle it eventually.” Update your runbooks and playbooks based on what you learned. Then schedule a follow-up tabletop exercise within 60 days to test the updated procedures. The cycle of plan, test, incident, learn, and improve is what builds genuine resilience over time. For more on building a resilient security posture, see our guide on small business cybersecurity basics.

Common Mistakes SMBs Make With Incident Response Plans

Even businesses that build a plan often undermine it with predictable, fixable mistakes. Here’s what to watch out for:

• Creating a plan but never testing it. A plan that’s never been run is just a document. Fix: run quarterly tabletop exercises — even a one-hour walkthrough makes a measurable difference.
• No offline backup of the IRP itself. If ransomware encrypts your network, a plan stored only on your servers is useless. Fix: print physical copies and store them securely, or keep an air-gapped digital copy.
• Undefined roles during a live incident. When everyone’s looking at each other waiting for someone to lead, attackers have more time to operate. Fix: assign and rehearse IC and team roles before any incident occurs — not during one.
• Skipping cyber insurance alignment. Many SMBs assume their policy covers everything, then discover mid-incident that they missed a required step. Fix: review your policy annually and confirm your IRP aligns with coverage requirements and notification procedures.