Incident Response Planning: The 6-Step Playbook for SMBs

It’s 6:47 AM on a Tuesday. You get a call from your office manager. Nobody can open their files. Every computer is showing a red screen with a bitcoin address and a countdown timer. Your phone starts blowing up. Employees are texting, clients are emailing, and you have no idea what to do first.

That’s what a ransomware attack feels like without an incident response plan. Now let me tell you what it feels like with one: you pull up the plan, you call the first number on the list, the containment steps start immediately, and everyone knows their role. Still stressful. But controlled.

An incident response plan (IRP) is a documented playbook that tells your organization exactly what to do when a security incident happens. Not if. When. And if you have cyber insurance, your policy almost certainly requires you to have one.

Here are the six steps.

Step 1: Prepare

This is everything you do before an incident happens. It’s the most important step because it determines how the other five go.

Build Your Response Team

Even at a 30-person company, you need defined roles. Not a full-time security team, just people who know their responsibilities:

• Incident Commander: Usually the business owner or operations leader. Makes the big decisions during an incident (do we shut down operations, do we notify clients, do we pay the ransom).
• IT Lead: Your internal IT person or your managed IT provider. They run the technical response.
• Communications Lead: Handles internal and external communications. Employees, clients, vendors, media if it comes to that.
• Legal Contact: Your attorney, ideally one with data breach experience. You’ll need them for regulatory obligations.
• Insurance Contact: Your cyber insurance carrier’s breach hotline number. This needs to be called early, not after you’ve already made decisions they should have been involved in.

Document Your Critical Systems

Make a list of every system your business needs to operate, ranked by priority. When you’re deciding what to restore first, this list eliminates arguments and guesswork. Your list should include:

• System name and function
• Where it’s hosted (on-premises, cloud, vendor)
• Who’s responsible for it
• Recovery time objective (how long can you be without it)
• Dependencies (what else breaks if this system is down)

Have the Right Tools in Place

Your ability to respond depends on what tools are already deployed. If you don’t have EDR (Endpoint Detection and Response) on your machines when an incident starts, you can’t magically deploy it in the middle of a crisis. Preparation means having:

• EDR on all endpoints and servers
• Tested, immutable backups
• Network monitoring and logging enabled
• An offline copy of your incident response plan (if your network is down, a plan stored only on your file server is useless)

Run Tabletop Exercises

Once a year, gather your response team and walk through a scenario. “It’s Tuesday morning and ransomware has encrypted all our file shares. What do we do?” Talk through each step. Find out where the plan breaks down. Fix those gaps. A tabletop exercise costs you two hours. Figuring out your plan doesn’t work during an actual incident costs you everything.

Step 2: Identify

You can’t respond to what you don’t know about. Identification is the process of detecting that an incident is happening, determining what type of incident it is, and assessing the scope.

Detection Sources

Incidents get detected through multiple channels:

• EDR/security alerts: Your endpoint protection flags suspicious behavior
• Employee reports: Someone notices something weird, like unexpected password reset prompts or files they can’t open
• Vendor notifications: Your IT provider, your bank, or a business partner tells you something looks off
• External notification: Law enforcement or a security researcher contacts you (this happens more than you’d think)

Initial Assessment Questions

When you think you have an incident, you need to quickly answer:

• What type of incident is it? Ransomware, data theft, business email compromise, unauthorized access?
• How widespread is it? One machine, one department, the entire network?
• Is it still active? Is the attack ongoing or has the damage already been done?
• What data is potentially affected? Client data, employee records, financial information, intellectual property?

The answers to these questions determine how aggressive your containment needs to be. A single phishing email on one workstation is a different response than active ransomware spreading across your network.

Step 3: Contain

Containment is about stopping the bleeding. You’re not fixing anything yet. You’re making sure it doesn’t get worse.

There are two types of containment:

Short-Term Containment (First Hour)

This is the “stop the bleeding” phase. Actions include:

• Isolate affected machines from the network. Don’t power them off (you’ll lose forensic data). Disconnect the network cable or disable the Wi-Fi. If you have EDR, use it to isolate the endpoint remotely.
• Disable compromised accounts. If credentials were stolen, disable those accounts immediately. All of them, including service accounts.
• Block attacker access. If you can identify how they got in (a specific IP, a compromised VPN account, a malicious email rule), block it now.
• Preserve evidence. Do not wipe machines, do not reinstall, do not delete logs. Your forensic investigators and your insurance company will need this data.

Long-Term Containment

Once the immediate bleeding has stopped, you set up temporary measures to keep operating while you work the problem:

• Stand up clean systems from known-good backups for critical business functions
• Implement additional monitoring on unaffected systems
• Change all passwords, starting with administrative and privileged accounts
• Apply any patches that address the vulnerability the attacker exploited

The First Hour Checklist

Tape this to the wall next to your server room. Seriously.

1. Call your IT provider/incident commander
2. Call your cyber insurance breach hotline
3. Isolate affected systems (network disconnect, NOT power off)
4. Disable compromised user accounts
5. Preserve all logs and evidence
6. Do NOT communicate externally until legal is consulted
7. Document everything with timestamps

That sixth point is important. Do not send an email to clients saying “we’ve been hacked” before your attorney reviews it. What you say in the first hours of an incident can have legal and regulatory consequences.

Step 4: Eradicate

Now that the incident is contained, you find and remove the root cause. This is where you figure out exactly how the attacker got in and make sure that door is closed.

Eradication typically involves:

• Identifying the attack vector. Was it a phishing email? An unpatched vulnerability? A compromised vendor? Stolen credentials from a previous breach?
• Removing malware and attacker tools. Every backdoor, every persistent access mechanism, every piece of malicious software.
• Patching the vulnerability that was exploited.
• Scanning all systems to make sure the attacker didn’t leave anything else behind.

This is where forensic investigation happens. A skilled investigator will trace the attacker’s path through your environment, identify everything they touched, and determine what data they may have accessed or stolen.

Do not skip this step. We’ve seen businesses rush to recovery without proper eradication, only to have the attacker come back in through the same door a week later.

Step 5: Recover

Recovery is getting back to normal operations, and every hour matters. We’ve broken down what downtime actually costs a mid-size business, and the numbers are sobering. This is where your preparation in Step 1 pays off, specifically your system priority list and your backups.

Recovery Priorities

Bring systems back in order of business criticality:

1. Core infrastructure: Active Directory, DNS, networking
2. Communication: Email, phones, messaging
3. Revenue-critical applications: ERP, billing, client-facing systems
4. Everything else: Brought back systematically with verification

Recovery Best Practices

• Rebuild from clean images or known-good backups. Do not try to “clean” a compromised machine. Wipe it and rebuild.
• Verify before reconnecting. Every system that comes back online should be scanned and verified clean before it touches the production network.
• Monitor intensively. For the first 30 days after recovery, increase monitoring. Watch for any signs the attacker maintained access.
• Reset all credentials. Every password, every API key, every service account. Assume everything was compromised.
• Communicate with stakeholders. Your employees need to know what happened and what’s different. Your clients may need to be notified depending on the type of data involved and your regulatory obligations.

Step 6: Learn

This is the step everyone skips, and it’s the step that prevents the next incident from being just as bad.

Within two weeks of recovery, hold a post-incident review. No blame. Just facts and improvements.

Review Questions

• How did the attacker get in, and why did our defenses miss it?
• How quickly did we detect the incident? Can we detect faster?
• Did the incident response plan work? What broke?
• Were roles and responsibilities clear?
• What tools or capabilities were we missing?
• What would we do differently?

Update Everything

Based on the review, update:

• Your incident response plan
• Your security controls and policies
• Your employee training (address the specific attack vector)
• Your backup and recovery procedures
• Your cybersecurity services and monitoring

Document the lessons learned and share them with the team. The incident already happened. The only way to get value from it is to make sure it doesn’t happen the same way twice.

You Need This Plan Before You Need It

The worst time to write an incident response plan is during an incident. The best time is right now.

You don’t need a 50-page document. You need a clear, practical playbook that your team can follow under pressure. Contact list, role assignments, containment steps, communication templates, recovery priorities. Keep it to 10 pages or less and make sure it’s accessible even when your network is down (print it out, put it in a shared cloud drive outside your corporate environment, or both).

If you’re not sure where to start, or if you have a plan that hasn’t been updated since it was written, we can help. Our managed IT services include incident response planning, tabletop exercises, and the security infrastructure that makes the plan work when you need it.

Reach out for a security assessment and we’ll help you build a plan that actually holds up when it matters.