When a cyber attack hits your business, the first ten minutes are the most expensive ones you’ll ever have.
Not because the attackers are doing the most damage — but because your team is doing nothing. Staring at screens. Calling each other. Waiting for someone to tell them what to do.
That’s not a technology failure. It’s a planning failure.
The businesses that survive aren’t the ones with the best technology. They’re the ones that detected the problem fastest — and had a plan for exactly what to do next.
One of our clients ran their Microsoft 365 environment for three years without a single failed backup alert. When we ran a proactive review, we found their backup had been silently failing for 47 days. No alert. No warning. Zero data loss — only because we caught it in time. That’s what undetected looks like: 47 days of compounding exposure with no signal. An incident response plan is what makes detection possible, and a tested one is what makes survival likely.
An incident response plan (IRP) tells your team exactly what to do when something goes wrong — before anyone has to think clearly under pressure. For small businesses, a written IRP is the difference between a disruption that costs you a few hours and a breach that costs you six figures, a regulatory fine, and your reputation.
This guide walks you through what an incident response plan is, why every small business needs one, and how to build a practical version you’ll actually use.
What Is an Incident Response Plan?
An incident response plan is a documented set of procedures that tells your team how to detect, contain, investigate, and recover from a cybersecurity event.
It covers:
- Who does what when an incident is suspected or confirmed
- How to contain the threat before it spreads
- Who to notify — internally, and legally if data was compromised
- How to preserve evidence in case of law enforcement or insurance claims
- How to recover systems and data in the right order
- How to document what happened so you can prevent it next time
A good IRP doesn’t have to be 50 pages. For a 10–50 person business, a clear, tested 5–10 page document is worth more than an untested enterprise playbook sitting on a shelf.
After 20 years of managed IT, the pattern is consistent: the businesses that survive a breach are rarely the ones with the most sophisticated tools. They’re the ones that detected the problem fastest and had a written plan to act.
Why Small Businesses Need an Incident Response Plan Right Now
The common assumption is that only large companies need formal incident response. Attackers have corrected that assumption — forcefully.
43% of cyber attacks target small businesses. Most attackers aren’t looking for a sophisticated target; they’re looking for an easy one. A business without an IRP is an easy one.
Here’s what a missing plan actually costs:
| Impact | Without a Plan | With a Plan |
|---|---|---|
| Breach containment time | Days to weeks | Hours |
| Recovery time | Weeks to months | Days |
| Data loss | Significant | Minimal |
| Legal exposure | High | Managed |
| Cyber insurance payout | Reduced or denied | Supported |
| Regulatory penalty risk | Elevated | Reduced |
Your cyber insurance may require it. Most modern cyber insurance policies require documented evidence of incident response procedures, MFA, and regular backups as a condition of coverage — or at minimum, to receive full payout. Showing up to a claim without any documented process is how businesses get partial denials.
The 47-day silent backup failure we caught for a client? That client had cyber insurance. They had backups — technically. What they didn’t have was a monitoring process to confirm the backups were actually working. That’s the gap between “covered” and “actually covered.”
CMMC and HIPAA require it. If you’re a DoD contractor pursuing CMMC Level 2 certification, or a healthcare business under HIPAA, a written incident response plan isn’t optional. It’s an audit requirement.
The 6 Phases of an Incident Response Plan
NIST’s Computer Security Incident Handling Guide (SP 800-61) defines incident response in phases. Here’s a practical adaptation for small business:
Phase 1: Preparation
Preparation happens before any incident occurs. It’s the work that makes the rest of the plan executable.
Key preparation activities:
- Identify your critical assets (data, systems, applications) and rank them by business impact
- Document your network and systems (asset inventory, software list, access roles)
- Assign incident response roles — who is your incident commander? Your IT contact? Your legal/compliance contact?
- Establish a communication tree — who calls whom, and how?
- Define your “incident triggers” — what events require escalation vs. routine IT handling?
- Ensure logging and monitoring is in place (you can’t respond to what you can’t see)
- Test your backups — recovery is only possible if backups actually work
Most small businesses skip preparation because it feels like overhead. It isn’t. Preparation is where 80% of incident response value is created.
After 20 years of proactive IT management, we can tell you exactly what “no preparation” looks like: a client who didn’t know their backup had failed for 47 days. A client who called us after a breach because there was no documented escalation path. A client who lost six figures to ransomware because nobody had defined what “critical” meant for their business. Preparation isn’t overhead. It’s the entire point.
Phase 2: Detection and Identification
You can’t respond to an incident you haven’t detected. The faster you detect, the less damage you take.
Common detection sources:
- Endpoint detection and response (EDR) alerts (e.g., Huntress flagging suspicious behavior)
- User reports (“I got a weird email,” “my files look scrambled,” “I can’t log in”)
- RMM monitoring alerts from your IT provider (NinjaOne flagging CPU spikes, failed logins)
- Email security filtering catching a phishing attempt before it lands
- Firewall or network monitoring alerts
Once a potential incident is flagged, your team needs to answer three questions:
- What happened? (What systems, what data, what user accounts are involved?)
- Is this still active? (Is the attacker still in the environment?)
- How serious is it? (Is this a user error, a phishing attempt, active ransomware, or a confirmed breach?)
Severity classification prevents overreaction (shutting down everything for a spam email) and underreaction (ignoring an early warning sign of ransomware).
Phase 3: Containment
Containment stops the spread. Speed matters here — ransomware can encrypt thousands of files per minute, and attackers often move laterally across networks before deploying their final payload.
Short-term containment:
- Isolate affected systems from the network (pull the cable or disable the NIC — do NOT shut down the machine if forensics matter)
- Disable compromised user accounts
- Block suspicious IP addresses or domains at the firewall
- Suspend remote access for affected users
Longer-term containment:
- Rebuild compromised systems from clean images (not restored from potentially compromised backups)
- Reset credentials across affected accounts — and any accounts that shared passwords
- Patch the vulnerability that was exploited before reconnecting to the network
Critical: Do not wipe evidence. If law enforcement involvement or insurance claims are possible, preserve forensic copies of affected systems before reimaging.
Phase 4: Eradication
Eradication removes the threat entirely. Containment stops the bleeding; eradication closes the wound.
Eradication activities:
- Remove all malware, backdoors, and attacker-installed tools
- Identify and patch the root cause (unpatched software, weak credentials, misconfigured access)
- Verify that no persistence mechanisms remain (scheduled tasks, startup entries, rogue admin accounts)
- Scan all systems — not just the affected ones — for indicators of compromise
This is where endpoint detection and response tools pay for themselves. A good EDR like Huntress can identify attacker artifacts across your environment automatically, rather than requiring manual forensic review of every machine.
Phase 5: Recovery
Recovery returns operations to normal — carefully.
Recovery sequence:
- Restore from clean, verified backups (following your 3-2-1 backup strategy)
- Bring systems back online in priority order — revenue-critical systems first
- Monitor recovered systems intensively for 24–72 hours for signs of reinfection
- Validate that all affected data is restored and accurate
- Reconnect users with fresh credentials
Don’t rush recovery. Bringing systems back online before eradication is complete is how businesses get hit twice.
Phase 6: Post-Incident Review
The post-incident review (sometimes called a “lessons learned” or “after-action review”) is where the IRP pays long-term dividends.
Within 1–2 weeks of the incident:
- Document a full timeline of events
- Identify what the detection and response got right — and wrong
- Update the IRP with specific changes based on what you learned
- Brief leadership on business impact (cost, downtime, data affected)
- File your cyber insurance claim if applicable
- Review regulatory notification obligations (HIPAA, state breach notification laws)
Businesses that skip the post-incident review are the ones that get hit the same way twice.
One of our clients — an Ampy-era engagement — had no idea their backup had silently failed for 47 days until we ran a proactive review. Zero alerts. Zero warnings. The only reason there was no data loss was timing: we looked before something critical happened. That’s the post-incident review principle applied proactively, not after a crisis: if you don’t look for the gaps, you won’t find them until they’re expensive.
Who to Notify — and When
Breach notification is one of the most stressful parts of incident response because the rules are real and the timelines are tight.
Internal notifications (immediate):
- Leadership / ownership
- Legal counsel (if you have it)
- Your IT provider or MSP
- HR (if employee accounts or data were affected)
Regulatory notifications (check your timelines):
| Regulation | Notification Timeline |
|---|---|
| HIPAA | 60 days after discovery (business associates: 60 days to covered entity) |
| GDPR | 72 hours to supervisory authority |
| State breach laws (Indiana, California, most states) | 30–45 days to affected individuals, varies by state |
| CMMC (DoD contractors) | Per your contract — often 72 hours |
| Cyber insurance | Notify insurer immediately — delays can affect claims |
Client/partner notifications: If client data was exposed, you’ll almost certainly have contractual and legal obligations to notify them. Your MSA should define this — if it doesn’t, that’s a gap to fix before an incident occurs.
Law enforcement: FBI’s IC3 (ic3.gov) for cybercrime reporting. This is optional for most businesses but important if significant financial fraud or theft occurred.
5 Common Incident Response Mistakes Small Businesses Make
1. Waiting to document until after the incident
The time to build an IRP is not when your files are encrypted. Once an incident is active, documentation, communication, and decision-making all degrade under stress. Build the plan when things are calm.
2. Wiping systems before preserving evidence
The instinct to “just nuke it and start over” is understandable — but if you have a cyber insurance claim or law enforcement involvement, that evidence is required. Image the system first, then rebuild.
3. Only notifying internally
Breach notification laws exist, and they have deadlines. Missing a 60-day HIPAA window or a 45-day state notification requirement turns a bad situation into a regulatory one.
4. Recovering to the same vulnerable state
Restoring from backup is not the same as fixing the root cause. If you restore without patching the vulnerability or closing the access vector, you’re reopening the door.
5. Never testing the plan
An untested IRP is a document, not a capability. Schedule a tabletop exercise at least once a year — walk your team through a hypothetical breach scenario and identify the gaps before they’re real.
The Role of Your IT Provider in Incident Response
A capable managed IT provider changes your incident response capacity dramatically.
Here’s what SDTEK brings to the table:
Huntress EDR — 24/7 threat detection across your endpoints. Huntress analysts review alerts that automated tools miss, and flag suspicious behavior before it becomes a full compromise.
NinjaOne RMM — Remote access to affected systems within minutes. When an incident is called, your SDTEK team can isolate machines, pull logs, and begin triage without waiting for an on-site visit.
Documented runbooks — SDTEK maintains documented response procedures for common incident types (ransomware, phishing account takeover, credential stuffing), so the first hour isn’t spent building a plan from scratch.
Post-incident reporting — After containment and recovery, SDTEK provides a documented incident summary you can use for insurance claims, regulatory compliance, and internal review.
If you’re evaluating an MSP, ask them directly: “What’s your incident response process? What tools do you use? Who contacts us and how fast?”
If they don’t have a clear answer, that’s an answer.
Building Your Incident Response Plan: A Quick-Start Checklist
If you don’t have a written IRP yet, start here:
5 Questions to Ask Your IT Provider About Incident Response
- Do you have a documented incident response process — and can I see it?
- How quickly can you respond if I call at 2 AM on a Saturday?
- What EDR/monitoring tools do you use to detect threats before I call?
- Have you handled ransomware or data breach incidents before? What was the outcome?
- Will you help me with breach notification, insurance claims, and regulatory documentation after an incident?
Frequently Asked Questions
Q: Does a small business really need a formal incident response plan?
A: Yes — and the smaller you are, the more a plan matters. Large enterprises have dedicated security teams to improvise under pressure. Small businesses typically don’t. A written plan is how you give your team a fighting chance when something goes wrong. It also reduces cyber insurance friction, supports HIPAA and CMMC compliance, and shortens recovery time significantly.
Q: What’s the difference between an incident response plan and a business continuity plan?
A: An incident response plan focuses specifically on detecting, containing, and recovering from a cybersecurity event. A business continuity plan (BCP) is broader — it covers how the business keeps operating through any disruption (natural disaster, power outage, key employee loss, or cyber attack). Your IRP is typically one input into a larger BCP. If you only have capacity for one, start with the IRP for cyber-specific threats, then build the BCP around it.
Q: How long does it take to build an incident response plan?
A: A working first version can be completed in a single focused half-day session with your IT provider and key stakeholders. It doesn’t have to be exhaustive to be useful. A practical 5–10 page IRP you’ll actually follow is better than a 50-page document no one reads. Plan for 2–4 hours of effort, then schedule an annual review.
Q: What’s the first thing you should do when you suspect a breach?
A: Don’t panic, and don’t touch anything until you’ve called your IT provider. The instinct to “fix it yourself” — deleting suspicious files, closing programs, shutting down machines — can destroy forensic evidence and make the situation harder to remediate. Isolate the affected machine from the network (unplug the ethernet cable), preserve everything else, and call your IT provider immediately.
Q: How does cyber insurance relate to an incident response plan?
A: Your cyber insurance policy will almost certainly ask whether you have a documented incident response plan during underwriting — and may reduce your premium or expand your coverage if you do. After a breach, your insurer will ask for documentation of your response timeline, containment steps, and notification actions. A well-followed IRP provides exactly the paper trail that supports a strong claim. Insurers are increasingly denying or reducing claims where businesses had no documented process.
Q: Can my MSP help build our incident response plan?
A: Yes — and a good MSP should proactively offer this as part of a managed security relationship. SDTEK helps clients document their IRP, maintain it annually, and conduct tabletop exercises. We also provide response support when incidents occur: triage, containment, forensic logging, and post-incident reporting. If your current IT provider doesn’t bring this up, ask about it.
SDTEK has been helping Fort Wayne and San Diego businesses build smarter IT infrastructure since 2007 — 20 years of owning IT risk alongside our clients. If your business doesn’t have a written incident response plan, we’ll help you build one — and make sure your team knows how to use it. Contact us or call for a free consultation.
