Ransomware Incident Response: A Playbook for Small Teams
Date Published
Most ransomware guidance is written for enterprise security operations centers with dedicated incident response teams. Small IT teams usually don’t have that luxury — someone gets a call that files won’t open, and within minutes they’re the entire response team. This playbook is built for that reality: what to do in the first hour, the first day, and the weeks after.
The first hour: contain, don’t panic
Disconnect the affected machine from the network immediately — pull the ethernet cable or disable Wi-Fi rather than shutting it down, since a live memory image can help identify the ransomware strain later. Then check whether the infection has spread: look at other machines on the same network segment for similar symptoms. Do not pay, do not negotiate, and do not attempt to restore from backup yet — you need to understand the scope of the compromise first, or you risk reinfecting a clean restore.
Identify what you’re dealing with
Ransom notes usually name the strain, or you can match the file extension appended to encrypted files against a ransomware identification tool. This matters because some older or poorly-implemented strains have known decryption tools published by security researchers — checking before you consider any other option costs nothing and occasionally saves the entire recovery.
Restoring from backup safely
Before restoring anything, confirm your backups are actually clean — ransomware frequently sits dormant for days or weeks before triggering encryption, so a backup from yesterday may already be compromised. Restore to an isolated, freshly-imaged environment first, scan it thoroughly, and only reconnect it to the production network once you’re confident it’s clean. This is also the moment to reset every credential the affected machine had access to, not just the obvious ones.
After the fire is out
Once systems are stable, figure out the entry point — phishing email, exposed RDP port, or an unpatched vulnerability are the three most common — and close it, or the same attacker (or the next one) will be back. Depending on what data was on the affected systems, you may have breach notification obligations; check them early rather than as an afterthought. Finally, write down what happened while it’s fresh: the timeline, what worked, and what didn’t. That document is worth more than any tool for the next incident.