Ransomware Response Checklist for a Small Business

What to do in the first hour, why you call your insurer before your IT person, and the two mistakes that turn a recoverable incident into an expensive one.

By the founder — infrastructure engineer, 15 years (bio) · Updated 2026-08-11

Almost everything written about small-business ransomware is prevention advice published by companies selling prevention. That’s not useless, but it’s the wrong document to be holding at 9 a.m. on the morning it happens.

This is the other document: what to do, in what order, when the files are already encrypted and nobody in the building is an incident responder.

No scare statistics here, and no product recommendations. Two reasons: the decisions below aren’t improved by knowing how many businesses were hit last year, and a page that frightens you and then sells you something is exactly the genre this site exists to avoid.

Print this or save it offline. A response checklist that lives only on the network you’ve just lost access to isn’t a checklist.

The first fifteen minutes

1. Disconnect the affected machines from the network. Don’t power them off.

Unplug the ethernet cable, turn off Wi-Fi, disconnect any VPN. The goal is to stop it reaching anything else.

Powering off feels decisive, and it’s usually the wrong move. A running machine holds volatile state that a responder may be able to use, and in some cases that state has mattered for recovery. Shutting down destroys it. If a machine is visibly still encrypting and pulling the network cable hasn’t stopped it, containment wins — but disconnect first and think second.

2. Disconnect your sync clients specifically.

Google Drive, OneDrive, Dropbox. Sync is the amplifier: it will faithfully upload the encrypted versions and push them to every other device and every colleague. Pause or sign out of the desktop client on every affected machine before you do anything else. This is the difference between one laptop and your whole company’s shared files, and it’s the step people miss because they’re focused on the machine in front of them.

3. Don’t run anything.

No antivirus scans, no cleanup tools, no decryptors found through a search engine, no deleting the ransom note, no renaming files to see if it helps. All of it destroys evidence you may need, some of it makes recovery harder, and at least one category of “free decryptor” is itself malware.

4. Photograph the ransom note with your phone.

The note usually identifies the variant, and the variant determines whether recovery tools exist. A photo also survives you losing access to the machine.

5. Write down the time.

When it was noticed, by whom, what they were doing, which machine. You will be asked, and you will not remember accurately by tomorrow.

Then call your insurer — before your IT person

This is the step that gets reversed most often, and reversing it can cost you the claim.

If you carry cyber insurance, the policy very likely requires you to notify them promptly and to use their approved incident responders. Bringing in your own IT contractor first, or starting remediation yourself, can reduce or void coverage on some policies — not because the work was bad, but because you didn’t follow the process you agreed to.

Call the number on the policy. If you don’t know whether you have cyber cover, check now rather than during an incident — our cyber-insurance readiness guide covers what to have ready in advance.

If you have no cyber policy, this step becomes: engage a competent incident responder before you attempt recovery yourself. The instinct to fix it quietly is the expensive one.

Don’t decide about payment on your own

You may not need to decide at all — that’s the responder’s and the insurer’s conversation, and if you have a clean offline backup it may never arise.

What’s worth knowing before the question lands: paying carries legal exposure beyond the money. Payments can go to sanctioned entities, and in the US that raises sanctions-compliance questions independent of whether paying was a sensible business decision. There’s also no guarantee of a working key, and no guarantee the copied data isn’t kept regardless.

This is a question for counsel, your insurer, and a responder — together, not the owner alone at 11 p.m. This page is not legal advice and nothing here should be read as telling you whether to pay.

Establish what actually happened

Before you restore anything, you need three answers:

What was reached? Which machines, which shared drives, which cloud accounts. Ransomware that got a set of credentials may have reached more than the device it ran on.

Was data copied, not just encrypted? Most modern ransomware exfiltrates before it encrypts, precisely so that having backups isn’t enough. This matters because it changes the incident from an availability problem into a possible disclosure one — a different set of obligations entirely.

How did it get in? If you restore without knowing, you may restore straight back into the same open door.

Restoring, in the right order

Contain, verify clean, then restore. Restoring into an environment that still has the attacker’s access, or their persistence, gets you encrypted a second time — and the second time, your backup is a day older.

Which copy you restore from matters:

• Sync version history may work if you caught it fast and the retention window covers it. Check whether bulk restore is genuinely available, because restoring forty thousand files individually is not a recovery plan.
• Cloud endpoint backup is the normal path for laptops.
• Your offline copy — the external drive from the 3-2-1 setup — is the one that cannot have been touched by a compromised credential. This is the copy people skip because it’s manual, and the copy that saves them when everything account-based is compromised.

Then rotate credentials: every password in the affected accounts, every API token, and the sessions themselves. A password change without a session revocation leaves live sessions authenticated — the same ordering problem covered in the stolen-laptop guide.

The notification question

If client or personal data may have been copied, you may have obligations — under state law, under your contracts, or both.

Two things that are consistently underestimated: obligations depend on where the affected individuals live, not where your business is; and client contracts frequently carry shorter notification deadlines than any statute. Small firms sign security and notification clauses without reading them closely, then discover them mid-incident.

Read the contracts for the clients whose data was involved, and get counsel. Don’t reason from a checklist — including this one.

What decides how bad this is

Every item on this list was determined before the incident:

An offline backup copy. Account-based backups can be reached by an attacker with your credentials. A drive in a drawer cannot.

A restore you have actually tested. The morning of an incident is a terrible time to discover the archive has been silently skipping a folder. Test twice a year and write down the date.

Passwords in a manager, not the browser. Browser-stored credentials in an unlocked profile hand over every account at once, which is how one laptop becomes every system.

MFA on your email and your admin accounts. Email is the recovery channel for everything else. If it falls, the rest follows.

Knowing whether you have cyber cover, and its notification deadline. Before, not during.

This checklist, offline. On paper, or on a phone.

The uncomfortable summary

If you have a tested, offline backup and cyber cover you understand, ransomware is a bad week: contain, verify, restore, rotate, notify if required.

If you have neither, it’s an existential event decided by people you’ve never met, on a timeline you don’t control.

The work that moves you from the second position to the first is unglamorous, costs between $10 and $45 a month for a five-person team, and takes an afternoon. It is entirely uninteresting right up until the morning it’s the only thing that matters.

This guide describes general incident-response practice and is not legal advice. Breach-notification obligations, and the legality of any payment, depend on your jurisdiction, your contracts, and the facts of the incident — consult a lawyer and your insurer. This page contains no affiliate links and recommends no products.