Ransomware Response Plan for SMBs: A Practical Execution Template

When It Hits, You Have Minutes — Not Days

It's 7:14am. A user calls the helpdesk. Files on the shared drive have strange extensions. The backup server isn't responding. There's a text file on three desktops called READ_ME_NOW.txt.

You already know what it is.

What happens in the next 30 minutes determines whether this incident costs $50,000 to remediate or $500,000. Whether you recover from clean backups or negotiate with a threat actor. Whether your customers find out from you — or from a data breach notification service that scraped a dark web forum.

Most small and medium-sized businesses do not have an incident response retainer. They do not have a 24/7 SOC. They have an IT lead, a handful of staff, and the decisions that need to be made right now.

This is the ransomware response plan for SMBs that your IT lead can execute without a security team standing behind them — a practical, prioritized, step-by-step workflow built for the moment when preparation ends and execution begins.

Print it. Laminate it. Put it in a drawer next to the server room. Because the worst time to find your response plan is after the encryption has started.

Before You Read the Plan: The Two Things That Determine Everything

Every ransomware outcome — contained and recovered, or catastrophic and costly — traces back to two variables that were set long before the attack arrived.

Variable 1: The state of your backups. Backups that are isolated from the network, tested regularly, and recent enough to be useful are the difference between a ransomware incident and a ransomware recovery. Backups that are connected to the network (and therefore encrypted alongside production data), untested (and therefore potentially incomplete or corrupt), or outdated (and therefore missing months of critical data) convert a containable incident into an existential one.

Variable 2: Whether your team knows the plan before they need it. A response plan that is read for the first time during an active incident is not a response plan. It's a document. The team that has walked through the scenario in a tabletop exercise — who does what, who calls whom, who has the authority to take systems offline — executes under pressure. The team that hasn't does not.

If you're reading this during an active incident: go directly to Phase 1. If you're reading this to prepare: finish the document, then run a tabletop exercise against it.

The Ransomware Response Workflow: Phase by Phase

PHASE 1: DETECT AND DECLARE (Minutes 0–15)

Objective: Confirm you are dealing with ransomware, not another issue, and declare the incident to start the coordinated response clock.

Step 1.1 — Confirm the Indicators

Do not assume. Verify. Ransomware indicators that confirm you have an active incident:

• [ ] Files with unfamiliar extensions (.locked, .encrypted, .crypt, or random character strings) that were not present previously
• [ ] Ransom note files in multiple directories (README.txt, DECRYPT_FILES.html, HOW_TO_RECOVER.txt or similar)
• [ ] Users unable to open files that were accessible minutes ago
• [ ] Backup systems returning errors or showing encrypted files
• [ ] Security software alerts on shadow copy deletion (vssadmin delete shadows) or backup service termination
• [ ] Unusual network traffic — encrypted outbound connections to unfamiliar external IPs

If three or more of the above are present: declare the incident now. Do not spend time confirming further. Every minute of delay is a minute of additional encryption.

Step 1.2 — Declare the Incident and Activate the Response Team

Who to call immediately (have these numbers written down — not in a system that may be compromised):

Fill these in before you need them. A blank table is not a communication plan.

The incident commander's first action: send a single communication to all parties above — via phone call or out-of-band messaging (Signal, WhatsApp, personal cell) if business email may be compromised. Content: "We are experiencing a ransomware incident. Do not use company systems. Stand by for updates."

Step 1.3 — Stop New Users From Logging In

Before containment actions, prevent additional accounts from being compromised:

• [ ] Disable new login capability at the directory level if possible (Active Directory → disable non-essential accounts temporarily)
• [ ] Notify all staff via out-of-band channel (personal cell, WhatsApp group): "Do not log into any company systems until further notice"
• [ ] If VPN is active: disable VPN access to prevent remote workers from connecting to the infected environment

PHASE 2: CONTAIN — STOP THE SPREAD (Minutes 15–45)

Objective: Isolate infected systems to prevent encryption from spreading to additional endpoints, servers, and — critically — backups.

This is the highest-leverage window of the entire response. Ransomware propagates through network shares, mapped drives, and connected systems. Every minute a compromised system remains on the network is a minute the encryption can reach another target.

Step 2.1 — IMMEDIATELY Isolate Backup Systems

This is the single most critical action in the entire response plan.

Ransomware operators target backups deliberately and specifically. Modern ransomware strains include modules that identify and encrypt backup systems before targeting production data — because encrypted backups eliminate the primary recovery path and maximize leverage for ransom payment.

Backup isolation checklist — execute this before any other containment action:

• [ ] Physically disconnect backup appliances from the network — unplug the network cable, not just disable the interface in software (software configurations can be reversed by the malware)
• [ ] Disable cloud backup sync — log into the cloud backup console from an unaffected device using stored credentials, and pause or disable the sync job immediately (an active sync may be pushing encrypted files to the cloud, overwriting clean backups)
• [ ] Document the last known clean backup timestamp before touching anything — this is the recovery point you'll be working from
• [ ] Verify backup integrity from a clean, isolated device — confirm that the backup files you expect to use for recovery are not already encrypted
• [ ] Disconnect tape or removable media backups from any system that may be compromised

If your backups are already encrypted: Do not delete them. Some encrypted backups can be recovered if a decryption key is later obtained. Preserve them while pursuing other recovery options.

Step 2.2 — Network Isolation: Segment and Sever

Once backups are isolated, contain the active infection:

Physical containment (fastest and most reliable):

• [ ] Identify the systems showing encryption activity (file extension changes, ransom notes, high disk I/O)
• [ ] Physically disconnect infected systems from the network — unplug network cables for wired connections
• [ ] For wireless devices: disable the wireless access point serving the infected network segment, or physically power down wireless devices
• [ ] Do NOT power off infected systems yet — memory forensics (which may be needed later to identify the ransomware variant and any decryption possibilities) requires the system to remain on

Firewall and network-level containment:

• [ ] Block all outbound traffic from infected network segments at the perimeter firewall — ransomware beacons home and may exfiltrate data through this connection
• [ ] Block east-west traffic between network segments — prevent the infection from moving from workstation VLANs to server VLANs
• [ ] If managed switches are available: place infected ports in an isolated VLAN that has no routing to production systems or backup infrastructure

What to leave online:

• Management interfaces on network equipment (need these to execute containment)
• Unaffected systems confirmed clean — but watch them closely
• Out-of-band communication systems

Step 2.3 — Identify the Scope of Infection

While physical containment is being executed, a second team member (if available) should be mapping the scope:

• [ ] Review file server logs for mass file rename events — this shows which shares have been hit and when encryption started
• [ ] Check which systems have ransom notes present
• [ ] Review Active Directory authentication logs for the period before the incident was reported — looking for unusual account activity, lateral movement, or privilege escalation that may indicate how the attacker moved through the environment
• [ ] Document every system confirmed or suspected as infected — this list drives the recovery sequence

Do not assume the infection is limited to the systems where ransom notes are visible. Ransomware often deploys on multiple systems simultaneously and may be dormant on some systems while actively encrypting on others.

PHASE 3: COMMUNICATE — PARALLEL TO CONTAINMENT (Minutes 30–60)

Objective: Notify the right people at the right time with the right information — without creating panic, spreading misinformation, or triggering regulatory obligations prematurely.

Communication failures during ransomware incidents are almost as costly as the technical failures. Customers who find out from a third party, regulators who receive inaccurate early disclosures, and staff who don't know what to do or say create secondary damage that outlasts the technical recovery.

Step 3.1 — Internal Communication Protocol

What to say (and what not to say) to staff:

DO send (via out-of-band channel — not company email or Slack if those may be compromised):

"We are experiencing a technical security incident. Please do not use any company systems, including email, file shares, or business applications, until further notice. Do not discuss this incident externally — including on social media. More information will follow. If customers or partners contact you about system availability, tell them we are experiencing a technical issue and direct them to [designated contact name/number]."

DO NOT:

• Use the word "ransomware" in mass staff communications in the first hour — the situation is still being assessed and inaccurate information spreads faster than corrections
• Send any communication through potentially compromised company systems
• Leave staff without guidance — silence breeds speculation that leaks externally

Step 3.2 — Cyber Insurance — Call Now, Not Later

This call needs to happen within the first hour. Not after containment. Not after you know the full scope. Now.

Cyber insurance policies typically include:

• Access to an approved incident response firm at negotiated rates (often significantly lower than retail IR rates)
• Legal counsel with breach notification expertise
• Ransomware negotiation specialists if payment is ultimately considered
• Public relations support for external communications
• Coverage for ransom payments in some policies (subject to conditions)

The insurer's approved vendor panel exists specifically for this moment. Using an unapproved IR firm before contacting your insurer can complicate or invalidate coverage. Call your broker or the insurer's 24/7 incident hotline before engaging any external security firm.

Information to have ready for the insurer:

• Policy number
• Nature of the incident (ransomware — describe the indicators you've confirmed)
• Approximate number of systems affected
• Whether data exfiltration is suspected (look for the ransom note — many modern ransomware groups indicate whether data was stolen as leverage)
• Whether backups are intact

Step 3.3 — Legal Counsel — Regulatory Notification Clock Assessment

The moment a ransomware incident is confirmed, the regulatory notification clock question becomes active:

Questions legal counsel needs to answer immediately:

• Does this incident potentially involve personal data that would trigger GDPR (72-hour), CCPA, or state breach notification obligations?
• Does the business serve regulated industries (healthcare, financial services) that have specific notification requirements?
• Does the ransom note or evidence indicate that data was exfiltrated (not just encrypted) — which changes the notification obligation analysis significantly?

The general principle: Notification obligations are triggered by awareness of a potential breach, not by confirmed determination that a breach occurred. Legal counsel's job in the first hour is to assess whether the known facts trigger notification obligations — not to wait for full forensic confirmation.

Do not make any public statement, customer notification, or regulatory filing without legal counsel review.

Step 3.4 — External Communication Holding Statement

Prepare this before you need it. When customers or partners contact you about service unavailability, your frontline staff needs a consistent response:

"We are currently experiencing a technical issue affecting some of our systems. Our team is working to resolve it as quickly as possible. We will provide an update by [time]. If you have urgent needs, please contact [name] at [contact]."

This statement:

• Acknowledges the issue without disclosing the nature of the incident
• Sets an expectation for follow-up communication
• Provides an escalation path for urgent needs
• Does not use the word "ransomware," "breach," or "attack" — all of which have specific legal implications

PHASE 4: ASSESS — KNOW WHAT YOU'RE DEALING WITH (Hours 1–4)

Objective: Identify the ransomware variant, determine whether data was exfiltrated, assess the recovery path, and make the decisions that will define the recovery timeline.

Step 4.1 — Identify the Ransomware Variant

The ransom note typically identifies the ransomware group and provides contact information for negotiation. Before any contact with the threat actor:

• [ ] Photograph or screenshot the ransom note from an uninfected device — preserve evidence before any remediation activity
• [ ] Submit a sample of the encrypted files and the ransom note to ID Ransomware (https://id-ransomware.malwarehunterteam.com/) — a free service that identifies ransomware variants and indicates whether a decryption tool is available
• [ ] Check the No More Ransom Project (https://www.nomoreransom.org/) — a collaboration between law enforcement and security vendors that provides free decryption tools for some ransomware variants

If a free decryption tool is available: Engage your IR team or security partner to use it safely in the recovery process. Do not attempt DIY decryption on production systems without guidance.

If no free decryption tool is available: Recovery will require restoring from clean backups (preferred) or engaging with the threat actor (last resort, complex, and not guaranteed to produce working decryption).

Step 4.2 — Determine Whether Data Was Exfiltrated

Modern ransomware attacks increasingly involve double extortion — the attacker exfiltrates data before encrypting it, then threatens to publish the data publicly if the ransom is not paid. This changes the incident's legal and regulatory profile significantly.

Indicators of data exfiltration:

• The ransom note explicitly states that data was stolen (many groups publish this claim to increase leverage)
• Network logs show large outbound data transfers in the hours or days before encryption was detected
• Threat actor's leak site (often referenced in the ransom note) shows preliminary "proof" of stolen data

If exfiltration is suspected or confirmed: Notify legal counsel immediately — this triggers a different set of notification obligations and changes the response calculus significantly.

Step 4.3 — Assess the Recovery Path

Based on what you now know, the recovery path falls into one of three scenarios:

Scenario A — Clean backups intact, variant identified, no exfiltration confirmed: Best case. Recovery from backups is the path. Timeline: hours to days depending on environment size and backup restoration speed. Skip to Phase 5.

Scenario B — Clean backups partially intact or of uncertain integrity, no free decryption available: Partial recovery from backups for the systems where backups are clean. For systems where backups are compromised or unavailable, evaluate: rebuild from scratch, attempt ransom negotiation, or accept data loss. Involve legal counsel and cyber insurer in this decision.

Scenario C — Backups encrypted or unavailable, no free decryption available, exfiltration suspected: Most complex scenario. Options are limited: ransom negotiation (through insurer-approved channels, not independently), rebuild from scratch accepting data loss, or a combination. Engage external IR firm and legal counsel immediately. Do not contact the threat actor independently.

PHASE 5: RECOVER — RESTORE CLEAN, NOT JUST FAST (Hours 4–72+)

Objective: Restore systems from verified clean backups, eliminate the attacker's persistence before reconnecting systems to the network, and return to operation without reintroducing the compromised environment.

Step 5.1 — Identify the Attacker's Entry Point Before Restoring

This step is skipped more often than any other — and it's the step most responsible for reinfection.

If you restore systems to the network without identifying and closing the initial access vector, the attacker can reenter through the same path and re-deploy ransomware against your freshly restored environment. Documented cases of organizations getting reinfected within 24 hours of paying a ransom or completing a recovery are almost always the result of failing this step.

Entry point investigation checklist:

• [ ] Review email gateway logs for the 2–7 days before the incident — phishing is the most common initial access vector for SMB ransomware
• [ ] Review VPN and remote access logs — compromised credentials or unpatched VPN vulnerabilities are common entry points
• [ ] Review Active Directory logs for new account creation, privilege escalation, or unusual group membership changes in the days before the incident
• [ ] Check for unpatched public-facing vulnerabilities (RDP, VPN appliances, web applications) — scan with a vulnerability scanner from an isolated clean system
• [ ] Review the backup systems for the presence of ransomware binaries — attackers often stage malware on backup infrastructure before detonation

Do not reconnect any restored system to the production network until the entry point is identified and closed.

Step 5.2 — Establish a Clean Recovery Environment

Before restoring from backups:

• [ ] Provision clean systems (fresh OS builds or confirmed clean images) for critical functions
• [ ] Restore from the most recent clean backup — not the most recent backup (which may have encrypted files)
• [ ] Verify the integrity of restored data before reconnecting to the network
• [ ] Change all passwords for all accounts — assume all credentials in the compromised environment are known to the attacker
• [ ] Reset service account credentials, API keys, and application passwords
• [ ] Rotate encryption keys and certificates where applicable

Step 5.3 — Restore in Priority Order

Not all systems have equal recovery priority. Restore in the order that gets the business operational:

1. Authentication infrastructure (Active Directory, identity providers) — everything else depends on authentication
2. Communication systems (email, if not already operational via cloud) — needed for customer and partner communication
3. Core business applications — the systems that generate revenue or serve customers
4. File servers — after core applications are stable
5. Endpoint workstations — once servers are confirmed clean and entry point is closed

Step 5.4 — Verify Before Reconnecting

Before each system is reconnected to the production network:

• [ ] Confirm OS integrity — compare system configuration against known-clean baseline
• [ ] Confirm no ransomware artifacts remain — run a full scan with updated definitions
• [ ] Confirm the entry point that allowed the original infection cannot be used for reentry
• [ ] Document the verification and who performed it — this evidence will be needed for the post-incident report

PHASE 6: REPORT AND LEARN (Days 3–14)

Objective: Fulfill notification obligations, document the incident for insurance and regulatory purposes, and implement the changes that prevent recurrence.

Step 6.1 — Notification Decisions

With legal counsel, determine and execute notification obligations:

Regulatory notifications that may apply:

• State data breach notification laws (timelines vary by state — most require notification within 30–90 days of determining a breach occurred)
• HIPAA Breach Notification Rule (60-day notification to HHS and affected individuals for covered entities)
• GDPR (72-hour notification to supervisory authority if EU personal data was involved)
• SEC material incident disclosure (4 business days for public companies)
• Sector-specific requirements (NYDFS 23 NYCRR 500, FFIEC for financial institutions)

Customer notification: If customer data was confirmed or suspected to be exfiltrated, customer notification is likely required. Work with legal counsel and PR support (from your cyber insurer's vendor panel) on the notification content and channel.

Step 6.2 — Post-Incident Documentation

For cyber insurance claims and regulatory responses, document:

• [ ] Timeline of the incident — when it was detected, by whom, and what indicators were present
• [ ] Chronological log of every response action taken and who took it
• [ ] List of systems affected and their recovery status
• [ ] Backup state at the time of incident and the recovery point achieved
• [ ] Estimated business impact — downtime hours, recovery costs, lost revenue
• [ ] Root cause determination — the initial access vector, how the attacker moved laterally, and how they deployed the ransomware

Step 6.3 — Post-Incident Security Improvements

The post-incident report's most important output is the improvement plan. The controls that were absent or inadequate when the ransomware arrived need to be implemented before the next attack.

The most common post-incident improvements for SMBs:

• [ ] Offline, tested backups — if the incident revealed backup gaps, close them before anything else
• [ ] Phishing-resistant MFA on all external-facing systems — email, VPN, remote access, cloud applications
• [ ] Network segmentation — workstations should not be able to directly reach backup systems
• [ ] Endpoint detection and response (EDR) — antivirus is not sufficient for modern ransomware; behavioral detection is required
• [ ] Privileged access controls — limit who can access backup systems and domain controllers
• [ ] Patch management — establish a documented cadence for critical patches, especially on internet-facing systems
• [ ] Incident response tabletop — run the team through this plan in a simulated exercise within 30 days of recovery

The SMB Ransomware Response Quick Reference Card

Cut this out. Put it in the server room. Give it to your IT lead.

RANSOMWARE RESPONSE — QUICK REFERENCE
CONFIRM: Files encrypted + ransom note visible + backups unavailable
→ Declare incident immediately
MINUTE 0-15: DECLARE
□ Call IT Lead (Incident Commander)
□ Call CEO / Business Owner
□ Notify all staff: "Do not use company systems"
□ Call Cyber Insurance broker NOW
MINUTE 15-45: CONTAIN
□ ISOLATE BACKUPS FIRST — unplug network cable
□ Pause cloud backup sync from clean device
□ Physically disconnect infected systems from network
□ Block outbound traffic at firewall
□ Do NOT power off infected systems
MINUTE 30-60: COMMUNICATE
□ Cyber insurance call (if not done)
□ Legal counsel — notification clock assessment
□ External holding statement ready for customer calls
□ Internal: consistent message, no social media
HOUR 1-4: ASSESS
□ Identify ransomware variant → id-ransomware.malwarehunterteam.com
□ Check for free decryption → nomoreransom.org
□ Confirm backup integrity
□ Determine if data was exfiltrated
HOUR 4+: RECOVER
□ Identify entry point BEFORE restoring
□ Close entry point BEFORE reconnecting
□ Change ALL passwords
□ Restore in priority order: Auth → Comms → Core Apps → Files → Endpoints
□ Verify clean before reconnecting each system
NUMBERS TO CALL (fill in before you need them):
IT Lead: _______________________
CEO: _______________________
Legal: _______________________
Cyber Insurance: _______________________
IR Firm: _______________________

RANSOMWARE RESPONSE — QUICK REFERENCE
CONFIRM: Files encrypted + ransom note visible + backups unavailable
→ Declare incident immediately
MINUTE 0-15: DECLARE
□ Call IT Lead (Incident Commander)
□ Call CEO / Business Owner
□ Notify all staff: "Do not use company systems"
□ Call Cyber Insurance broker NOW
MINUTE 15-45: CONTAIN
□ ISOLATE BACKUPS FIRST — unplug network cable
□ Pause cloud backup sync from clean device
□ Physically disconnect infected systems from network
□ Block outbound traffic at firewall
□ Do NOT power off infected systems
MINUTE 30-60: COMMUNICATE
□ Cyber insurance call (if not done)
□ Legal counsel — notification clock assessment
□ External holding statement ready for customer calls
□ Internal: consistent message, no social media
HOUR 1-4: ASSESS
□ Identify ransomware variant → id-ransomware.malwarehunterteam.com
□ Check for free decryption → nomoreransom.org
□ Confirm backup integrity
□ Determine if data was exfiltrated
HOUR 4+: RECOVER
□ Identify entry point BEFORE restoring
□ Close entry point BEFORE reconnecting
□ Change ALL passwords
□ Restore in priority order: Auth → Comms → Core Apps → Files → Endpoints
□ Verify clean before reconnecting each system
NUMBERS TO CALL (fill in before you need them):
IT Lead: _______________________
CEO: _______________________
Legal: _______________________
Cyber Insurance: _______________________
IR Firm: _______________________

Why Most SMBs Still Don't Have This Plan

The honest answer: it takes time that never feels urgent until 7:14am on a ransomware morning.

The organizations that execute well during ransomware incidents are not necessarily the ones with the largest security budgets or the most sophisticated tools. They're the ones that made one decision in advance: to treat the incident response plan as a standing operational document rather than a compliance artifact.

That decision involves practicing the plan — running the tabletop exercise, filling in the contact numbers, testing the backup restoration, walking the IT lead through the authority framework so they know what they can do without asking permission. None of this requires a security team. It requires time and organizational will.

The organizations that move to a predictive post-security model — where security controls are designed and tested before incidents occur rather than assembled in response to them — consistently experience lower ransomware impact, faster recovery, and better post-incident regulatory outcomes than organizations reacting to their first ransomware incident without preparation.

The plan above is the floor. Tested backups, phishing-resistant MFA, network segmentation, and endpoint behavioral detection are the controls that prevent this plan from being needed at all.

Build both.

Your Next Step

This plan gives your IT lead what to do when ransomware hits. What it cannot substitute for is the security architecture that reduces the probability of needing it — and the tested, documented response capability that ensures the plan works when it's executed under pressure for the first time.

Ready to assess your SMB's ransomware readiness — backup integrity, detection coverage, and response capability — before the 7:14am call arrives? A ransomware readiness assessment maps your current exposure against the specific controls that reduce ransomware impact and improve recovery outcomes. Let's talk.

This blog covers expert perspectives on ransomware response, SMB incident response planning, and cybersecurity resilience. Written for IT leads, business owners, and operations managers at small and medium-sized businesses who need practical, executable security guidance — not enterprise security theater.