How to Build an Incident Response Plan When You Don't Have a Security Team

Here's an uncomfortable truth: most small businesses don't have an incident response plan. And the ones that do usually have a dusty PDF sitting in a shared drive that nobody has read since it was written three years ago. When something actually goes wrong, people panic, make things up as they go, and hope for the best.

That's not a plan. That's chaos with extra steps.

If you're a small business without a dedicated security team, this post is your starting point. We're going to walk through a practical, usable IR plan that real people can actually follow when things go sideways. No SOC required.

Why You Need a Plan Before You Need a Plan

The middle of a security incident is the worst possible time to figure out what to do. Stress is high. Information is incomplete. Every minute matters. And without a plan, your team will waste critical time asking questions that should have been answered months ago: Who do we call? Should we shut down the server? Do we have to tell customers?

A basic incident response plan answers those questions in advance so you can focus on fixing the problem instead of debating process.

June is also a natural time for a mid-year risk review. If you haven't revisited your security posture since January, now's the time. Building or updating your IR plan is a great place to start.

"The goal of an incident response plan isn't to predict every attack. It's to eliminate confusion so your team can act quickly when one happens."

The Five Phases of Incident Response

The NIST framework breaks incident response into phases that work just as well for a 15-person company as they do for a Fortune 500. Here's how to adapt each one when you don't have a security operations center watching dashboards around the clock.

Phase 1: Detection - Knowing Something Is Wrong

You can't respond to an incident you don't know about. For small teams, detection usually comes from one of these sources:

• An employee notices something weird (slow systems, locked accounts, strange emails)
• A customer reports a problem (fraudulent charges, phishing emails from your domain)
• Your antivirus or endpoint protection tool flags something
• Your email provider or cloud platform sends a security alert
• A vendor or partner notifies you of a compromise on their end

The key here is making sure every employee knows how to report something suspicious. Create a simple reporting channel: a dedicated email address, a Slack channel, or even a phone number. The easier it is to report, the faster you'll catch problems.

Phase 2: Containment - Stop the Bleeding

Once you've confirmed that something bad is happening, the priority is stopping it from getting worse. This doesn't mean fixing the problem yet. It means limiting the damage.

For small businesses, containment usually looks like this:

• Disconnect affected machines from the network. Unplug the ethernet cable or disable Wi-Fi. Don't power them off yet since you may need forensic evidence.
• Disable compromised accounts. If credentials were stolen, reset passwords and revoke active sessions immediately.
• Block known malicious IPs or domains at your firewall or DNS level if you can identify them.
• Isolate affected systems from the rest of your network to prevent lateral movement.

Write down everything you do and when you do it. This log will be critical later for understanding the full scope and for any legal or insurance reporting.

Phase 3: Eradication - Remove the Threat

Containment stops the bleeding. Eradication removes the cause. This is where you figure out how the attacker got in and make sure that door is closed.

• Run full malware scans on all affected systems
• Patch any vulnerabilities that were exploited
• Remove any backdoors, unauthorized accounts, or persistence mechanisms
• Check for signs of the attacker on other systems they might have reached
• Update firewall rules and access controls as needed

If you're out of your depth here, this is the right time to bring in outside help. A managed security provider or incident response consultant can help you make sure the threat is actually gone, not just hiding.

Phase 4: Recovery - Getting Back to Normal

Recovery is about restoring systems and operations with confidence that the threat has been eliminated.

• Restore systems from clean backups (you do have backups, right?)
• Rebuild compromised machines from scratch if there's any doubt
• Monitor restored systems closely for signs of reinfection
• Gradually reconnect systems to the network, starting with the most critical ones
• Verify that business operations are functioning normally

Don't rush this phase. The worst outcome is declaring an incident resolved only to discover the attacker still has access a week later.

Phase 5: Post-Incident Review - Learning from What Happened

This is the phase that most small businesses skip, and it's arguably the most important one. Within a week of resolving the incident, gather everyone involved and answer these questions:

1. What happened, and when did we first detect it?
2. How did the attacker get in?
3. How long were they in our environment before we noticed?
4. What worked well in our response?
5. What slowed us down or caused confusion?
6. What changes do we need to make to prevent this from happening again?

Document everything. Update your IR plan based on what you learned. This is how you get better over time.

Customer Notification: What to Say and When to Say It

If customer data was exposed, you'll need to notify affected individuals. Many states have specific breach notification laws with defined timelines, often 30 to 60 days. Here's a communication template you can adapt:

"We are writing to inform you of a security incident that may have affected your personal information. On [date], we discovered unauthorized access to [specific systems]. The information that may have been exposed includes [types of data]. We took immediate steps to contain the incident, including [actions taken]. We are offering [credit monitoring/identity protection services] at no cost. If you have questions, please contact us at [phone/email]."

Key principles for customer notification:

• Be honest and specific. Vague statements erode trust faster than the breach itself.
• Explain what you're doing about it. People want to know you're taking action.
• Tell them what they should do. Change passwords, monitor accounts, freeze credit - give clear steps.
• Provide a way to reach you. A dedicated email or phone line for breach-related questions shows you're taking it seriously.

When to Call Law Enforcement: A Decision Tree

Not every incident requires law enforcement involvement, but some absolutely do. Here's how to think about it:

You should contact law enforcement if:

• Customer financial data (credit cards, bank accounts) was stolen
• Protected health information (PHI) was exposed
• You're dealing with ransomware, especially if a payment is demanded
• There's evidence of an insider threat or employee misconduct
• Social Security numbers or government-issued IDs were compromised
• The attack appears to be part of a larger campaign targeting multiple businesses

Where to report:

• FBI Internet Crime Complaint Center (IC3) at ic3.gov - for all cyber crimes, especially business email compromise and ransomware
• CISA (Cybersecurity and Infrastructure Security Agency) at cisa.gov/report - for significant cyber incidents, critical infrastructure attacks, or if you need technical assistance
• Your state attorney general's office - most states require breach notification through the AG's office, and many have online reporting portals
• Local FBI field office - for in-person reporting of significant financial losses or ongoing threats

Reporting to law enforcement doesn't mean you lose control of the situation. These agencies can provide resources, connect you with recovery assistance, and help identify whether your incident is part of a broader threat.

You can likely handle it internally if:

• A single employee clicked a phishing link but no credentials were entered
• Malware was detected and removed before any data was exfiltrated
• An unauthorized login attempt was blocked by MFA
• A vulnerability was discovered and patched before exploitation

When in doubt, report. There's no downside to notifying law enforcement, and they may have information about the threat actor that helps your investigation.

Building Your IR Plan: The Essentials

Your incident response plan doesn't need to be 50 pages. For a small business, a clear and concise document covering these elements is enough:

1. Roles and responsibilities. Who leads the response? Who communicates with customers? Who contacts law enforcement? Assign names, not just titles.
2. Contact list. Phone numbers and emails for your response team, your IT provider, your insurance company, your legal counsel, and relevant law enforcement agencies.
3. Detection and reporting procedures. How employees report suspicious activity, and what happens when a report comes in.
4. Containment playbooks. Step-by-step guides for common scenarios like ransomware, compromised email, and data exfiltration.
5. Communication templates. Pre-drafted messages for customers, employees, media, and regulators.
6. Recovery procedures. How to restore from backups, rebuild systems, and verify clean operations.
7. Post-incident review process. When to hold the review, who attends, and how lessons get turned into plan updates.

Print copies. Seriously. If your network is compromised, that beautifully formatted Google Doc might not be accessible when you need it most. Keep printed copies in a known, physical location.

Test It Before You Need It

An untested plan is barely better than no plan at all. At least once a year, run a tabletop exercise. Gather your team around a table, present a hypothetical scenario, and walk through the plan step by step.

Good scenarios to practice:

• An employee reports ransomware on their workstation at 4:45 PM on a Friday
• A customer calls to say they received a phishing email from your CEO's email address
• Your cloud provider notifies you of unauthorized access to your storage bucket
• A former employee's credentials are found on a dark web marketplace

These exercises consistently reveal gaps that look obvious in hindsight but would have caused real confusion during an actual incident.

You don't need a dedicated SOC or a six-figure security budget to respond effectively to a cyber incident. You need a plan, the right contacts, and a team that knows what to do when the alarm goes off. Build that plan now, while things are calm, and you'll be in far better shape when the day comes that you actually need it.