Ransomware Attack: A 12-Step Response Plan for Small Teams
It usually starts small. Someone can't open a spreadsheet. A folder of invoices has been renamed with a strange extension, and a text file called READ_ME is sitting next to it. By the time the note appears, the clock is already running: files are encrypting, your backups may be reachable, and everyone in the room is about to make decisions under pressure.
Small teams feel this hardest. There's no security operations centre, no on-call analyst, and often one person who "knows the computers." What you need in that moment isn't a threat briefing — it's a checklist anyone can run.
Before you declare an emergency, confirm what you're looking at. Real ransomware leaves a note with a payment method and a deadline, and encrypted files will not open in any program. If a single file is corrupted and nothing else is affected, you may be looking at a disk failure instead — still urgent, but a different problem.
Containment means cutting the connection, not the power. Unplug the Ethernet cable, disable Wi-Fi, and shut down shared folders. Leaving a machine powered on but disconnected can preserve useful evidence in its memory; yanking the plug destroys it. That said, if you cannot isolate a machine quickly and it is actively encrypting a network share, powering it off is better than watching the damage spread. Speed matters more than elegance.
Do not delete anything. Don't run a "cleanup" tool, don't reinstall Windows on the server, don't clear the ransom note. Photograph screens, note the file extension the attackers used, and write down the exact time you noticed. You will be asked for all of it later.
Skipping step three is the mistake that turns a bad week into a closed business. Everything else is recoverable.
Attackers know that backups are your way out, so they hunt for them. A backup drive that stays plugged into the server, or a NAS share with the same admin password as everything else, is not a backup — it's a second copy of the disaster. Keep at least one recent copy offline or on a network segment the infected machines cannot reach.
During an incident, resist the urge to restore immediately. First check whether your most recent backup actually opens; restore a test folder to a clean machine and confirm the files are readable and recent enough to be useful. Then rebuild the affected systems from scratch and restore data onto them afterward. Restoring onto a machine that still contains the malware just re-infects the data, and reconnecting a backup drive to a dirty network can destroy your last good copy.
If personal or customer data was exposed — not just locked — you may have obligations to notify regulators, affected individuals, or both. Timelines are often measured in days, not months, and they vary by country and by industry. Your cyber insurance policy may also require you to report the incident within a set window and to use their approved vendors.
Get a lawyer involved early rather than after you've sent an email to customers. The order usually works like this: insurer and counsel first, then regulator and law enforcement notifications as advised, then customer communication. Reporting the crime to your national cybercrime unit is generally expected even where it isn't mandatory, and it sometimes gives investigators something to work with.
This is general guidance, not legal advice. Breach notification rules depend on your jurisdiction and sector — confirm your specific duties with a qualified professional.
Assume your email is compromised. If the attacker had access to mail, they can read your messages and impersonate you. Set up an out-of-band channel — phone calls, a group chat, a shared spreadsheet on a clean device — and use it for everything until you know the network is clean.
Internally, tell staff what's happening, what they should stop doing (opening files, connecting laptops to the office network, emailing documents), and when the next update will come. A fixed update time, even if the update is "no change," prevents twenty people asking the same question all day.
Externally, put one person in charge of all statements. That person should stick to confirmed facts: which services are down, whether customer data was affected, what you're doing, and when you'll next update. Avoid guessing at the cause, promising a recovery date you can't hit, or speculating about who is behind it. Keep a written log of what you told whom and when — you may need it for notification paperwork, and it's easy to lose track by day three.
Wipe and reimage. Cleaning an infected machine and hoping for the best rarely works, because attackers frequently leave behind additional access — a scheduled task, a new admin account, a remote access tool. Rebuild from known-good images, change every password from a clean device, rotate the keys your software uses to talk to services, and turn on multi-factor authentication everywhere it's supported.
Then look at how they got in. For small organisations, the usual doors are exposed remote desktop, a reused password, a phishing attachment, or an unpatched piece of internet-facing software. You don't need to fix everything at once. Close the door they used first, then work down the list.
Your contact list cannot live only inside the systems that just got encrypted. Put one page on paper, in a drawer someone can find at 7 a.m.: your insurer's claim number, the lawyer's direct line, your IT contact, your bank, and your two largest customers. Add the first three steps of the list above.
Then run the cheapest drill available: pick a quiet Tuesday, unplug a test laptop from the network, and time how long it takes for the right person to be reached and to say "isolate everything." If that takes forty minutes and three phone calls, you've just learned something worth knowing — while it was still free.
Photo: Pexels / Pixabay
Previous Post
Password Managers vs. Browser Password Saving: Which Is Safer for Beginners?
Next Post
What Is Zero Trust? A Plain-English Explainer for Non-IT Staff
