The moment you realize what's happening

It starts with something small. A strange file name. A desktop wallpaper that changed. An employee who can't open their files and calls it "a weird error." Then someone looks more carefully, and the word "ransomware" appears.

The next 30 minutes are the most consequential 30 minutes in your company's recent history.

This guide is written for the small business owner, the office manager, or the part-time IT person who is now dealing with an active ransomware incident after hours — without a dedicated security team, without a written incident response plan, and very likely without anyone immediately available who has done this before.

You can limit the damage. But you have to move fast and move correctly.

The one rule that overrides everything else: isolate first

Before you do anything else — before you call anyone, before you try to figure out what happened, before you check how bad it is — you need to cut the network.

Ransomware spreads laterally. The machine you're looking at right now may be showing symptoms, but the encryption is likely running on multiple machines simultaneously. Every minute it continues, more files are locked.

Isolation steps, in order:

1. Disconnect affected machines from the network. Pull the ethernet cable. Turn off Wi-Fi. Do this physically — don't rely on software. If you can't identify which machines are affected, disconnect all of them.

2. Turn off the network switches if you can. If you have managed switches with a web interface, you can disable ports remotely. If not, pull the power on unmanaged switches. Yes, this takes everything down. That's the right call.

3. Isolate network-attached storage (NAS) and backup devices immediately. These are primary targets. A ransomware strain that reaches your NAS and your backup device in the same pass can make recovery from backup impossible.

4. Do NOT turn off affected machines yet. This sounds counterintuitive. Turning off a machine mid-encryption can corrupt files in ways that make partial recovery harder. Leave affected machines powered on but network-isolated for now.

5. Do NOT pay the ransom yet. Not in the first 30 minutes. Not in the first hour. There are often better options, and paying immediately forecloses some of them. More on this below.

Identify the strain — it matters more than you think

Not all ransomware is equal. The strain determines:

  • Whether a free decryptor exists (no ransom needed)
  • How it spreads (network shares, RDP, phishing)
  • What its known infection vector is (so you can find patient zero)
  • Whether the threat actor follows through on their promises if paid

How to identify the strain:

  • Look at the ransom note file (usually left in encrypted folders — look for a .txt or .html file with a name like DECRYPT_FILES, README, or YOUR_FILES_HAVE_BEEN_ENCRYPTED)
  • Look at the new file extension on encrypted files (e.g., .locked, .encrypted, .payransom, .dharma, or a random alphanumeric string)
  • Check nomoreransom.org — it's free, maintained by law enforcement agencies and security companies, and contains decryptors for hundreds of strains. Upload a sample encrypted file and the ransom note; it will identify the strain and tell you if a free decryptor exists.
  • Alternatively, visit id-ransomware.malwarehunterteam.com for the same identification service.

If a free decryptor exists: this is the best possible outcome. Do not pay anything. Engage an engineer to assist with the recovery process.

If no decryptor exists: your options are backup restoration, manual file recovery (possible in some strains), or negotiation. An experienced security engineer can advise based on the specific strain.

What patient zero looks like

While isolation is happening, someone needs to start figuring out how this got in. The most common attack vectors for small businesses are:

1. Phishing email with malicious attachment

An employee opened an attachment they shouldn't have. The attachment contained a macro or script that downloaded and executed the ransomware. This is the most common vector.

Signs: The infection started on one specific workstation before spreading. Check which machine first showed symptoms.

2. Remote Desktop Protocol (RDP) exposed to the internet

If you have RDP enabled and accessible on port 3389 without a VPN, attackers can brute-force credentials and deploy ransomware manually. This is the second most common vector for small businesses.

Signs: Event Viewer logs showing many failed login attempts from external IP addresses before a successful login. Check for unusual administrator login times in the Security event log.

3. Vulnerable VPN or firewall

Older VPN appliances (especially older Fortinet, Pulse Secure, SonicWall, and Cisco ASA firmware versions) have known exploits that attackers use to gain initial access. These attacks are automated and can happen without any user action.

Signs: Firmware versions more than 12–18 months out of date on any internet-facing appliance.

4. Compromised credentials from prior breach

Credentials from an old breach (LinkedIn, Adobe, or any major breach in the past decade) get tested against your VPN, email, or remote access system. If the employee reuses passwords, entry is immediate.

Signs: Login from an unusual geographic location before the incident. Often these show up in Azure AD sign-in logs or your firewall logs as a successful authentication followed immediately by lateral movement.

The backup question: where everything hinges

Ransomware response fundamentally splits into two paths depending on one variable: the quality and recency of your backups.

Scenario A: You have clean, recent, offsite backups

This is the good path. Rebuild is painful but possible. Timeline: - Server rebuild or restore: 4–24 hours depending on complexity - Data restore from backup: depends on backup size and restore method - Verification and testing: 2–4 hours

Your goal becomes: stop the spread, document the attack for insurance/legal purposes, and execute the restore. An experienced engineer can run this in parallel.

Scenario B: Your backups were encrypted too

This happens more than it should. The ransomware found your backup destination — whether it was a mapped network drive, a NAS that was continuously connected, or a cloud sync folder — and encrypted those files too.

This is why offsite or offline backups are critical. Backups that are not network-accessible at the time of the attack cannot be encrypted. This means:

  • Tape or external drive that is physically disconnected after the backup job completes
  • Cloud backups that use immutable storage (cannot be overwritten or deleted, only appended)
  • Air-gapped backup that has no persistent network connection

If backups are compromised, your options narrow to: 1. Professional data recovery services (expensive, not always successful) 2. Shadow copy / VSS recovery (often deleted by modern ransomware, but worth checking) 3. Negotiation with the attacker 4. Rebuild from scratch and restore only what was backed up before the attack

Scenario C: You have no backups

This is, unfortunately, not rare. If this is your situation: a senior security engineer can sometimes recover partial data through memory forensics, volume shadow copies that weren't overwritten, and file system analysis. Don't assume complete loss until this has been assessed.

Should you pay the ransom?

This is the question everyone wants a simple answer to. The reality is more nuanced.

Arguments against paying:

  • Payment is not guaranteed to result in decryption — approximately 20–30% of businesses that pay do not receive a working decryptor
  • Payment funds further attacks and criminal infrastructure
  • Some ransom payments may violate OFAC sanctions if the threat actor is on the sanctions list
  • Paying does not guarantee the attacker won't publish exfiltrated data if double-extortion is involved

Arguments for considering payment:

  • If no decryptor exists, no clean backup exists, and data is irreplaceable
  • If the cost of rebuild from scratch substantially exceeds the ransom demand
  • If the attacker is a known "business-minded" group that has a track record of providing working decryptors

What to do before paying anything:

1. Verify whether a free decryptor exists (nomoreransom.org) 2. Verify that your cyber insurance covers ransomware payment (many policies require insurer approval before payment) 3. Identify which threat actor group is behind the attack — a security engineer or your insurer can often identify this from the ransom note and strain 4. Understand whether double-extortion is in play (has data been exfiltrated? Is there a threat to publish?)

The decision to pay should never be made in the first 30–60 minutes of an incident. Make it with legal counsel, your insurer, and a security professional.

Notifications you'll need to make

Ransomware is not just an IT problem. Depending on what was on the affected systems, you may have legal notification obligations:

  • Washington State data breach law (RCW 19.255.010): Notification required if personal information of Washington residents was acquired or reasonably believed to have been acquired by unauthorized parties. Notification within "the most expedient time possible and without unreasonable delay."
  • HIPAA (healthcare): 60 days from discovery for covered entities. Breach Risk Assessment required.
  • Payment card data (PCI DSS): Immediate notification to card brands and acquiring bank if cardholder data was in scope.
  • Cyber insurance: Most policies require notification within 24–72 hours of discovery. Check your policy tonight.

Document the time of discovery. Document every action taken. This documentation matters for insurance claims, legal notifications, and forensic investigations.

What the first call to an after-hours engineer should cover

When you call for help, have this information ready:

  • What did you see first and at what time?
  • Which machines appear to be affected?
  • Have you isolated from the network yet?
  • What is the file extension on encrypted files?
  • Do you have a ransom note and what does it say?
  • What does your backup situation look like?
  • Do you have cyber insurance?

A senior engineer can begin remote triage in parallel with your isolation steps. The first 90 minutes with proper assistance typically establishes: the strain, the likely attack vector, the backup situation, and a recovery path. Without that expertise, the same triage often takes 4–8 hours of stressful dead-ends.

After the incident: what needs to happen before going back online

Do not bring systems back online until you have addressed the attack vector. Bringing systems back online with the same vulnerability that enabled the attack simply invites a second, faster attack — attackers sometimes wait for this.

Before returning to production:

  • [ ] Identify and close the attack vector (patch the vulnerability, rotate the compromised credentials, disable the exploited service)
  • [ ] Audit all user accounts for unauthorized accounts or changed permissions
  • [ ] Check for persistence mechanisms (scheduled tasks, startup registry keys, new services)
  • [ ] Scan all machines with offline malware tools before reconnecting
  • [ ] Rotate all passwords, especially admin credentials and service accounts
  • [ ] Verify backups are clean before restoring from them
  • [ ] Brief all employees on the attack vector so the same phishing / credential behavior doesn't recur

Hardening your defenses for next time

Every ransomware incident reveals a gap. Here are the most impactful mitigations for small businesses:

  • Disable RDP if you don't need it. If you need remote access, use a VPN + RDP, never RDP directly exposed to the internet.
  • Enable multi-factor authentication on all remote access, Microsoft 365, and any admin accounts. This single control stops a majority of credential-based attacks.
  • Implement offline or immutable backups. Test the restore quarterly.
  • Patch firmware on internet-facing devices quarterly, or enable automatic updates.
  • Segment the network so that a compromised workstation cannot directly reach servers and NAS devices.
  • Disable macros in Office for users who don't need them.
  • Use application allowlisting on servers — only pre-approved executables can run.

None of these require enterprise-level budget. Most can be implemented by an experienced engineer in a single session.