Detected ransomware on your network? The first 24 hours decide whether you stay offline for a week or a month — and how much data you actually lose. Here's the structured playbook we use with our clients (and the basis for the IR plans we write for them).
First minutes
Files encrypted with a `.crypted` extension, ransom note on the desktop, files unreachable across network drives — these are classic signals. But sometimes it looks like ransomware and it's something else (e.g. a failed backup job). Before declaring an incident, quickly verify with the system owner that this isn't expected behaviour.
The note or file extension often pinpoints the variant (Lockbit, Akira, BlackCat, Phobos…). For some, free decryptors exist at nomoreransom.org. It costs 5 minutes and may save you a backup restore.
If you have one. Convene the crisis team (IT lead, executives, lawyer, comms, external IR partner). If you don't have an IRP, hire an external IR team now — improvised incident response ends badly more often than you'd expect.
First hours
Pull the ethernet cable, turn off Wi-Fi, isolate VLANs at the switch. Don't fully power them off — RAM holds forensic traces, decryption keys, indicators of successful data theft. If you can, leave the machines running in their current state.
Domain admin, service accounts, local admin passwords, VPN access, cloud consoles. The attacker has likely escalated already — leaving access in place means they're back soon. Do this from a clean (non-domain-joined) machine, ideally over pre-prepared out-of-band channels.
Logs from firewall, AD, EDR, email gateway, VPN — export everything before you delete or reinstall anything. Take a forensic snapshot of critical systems (memory dump + disk image). Photograph and store the ransom note. Without evidence you can't do forensics or claim insurance.
If the backup server is in the domain, the attacker may have already compromised it. Physically/logically separate it from the network before they delete or encrypt the backups. 60% of organisations lose their online-reachable backups during a ransomware attack.
First 24 hours
Entities under ZoKB / NIS2 must report cyber security incidents — typically within 24 hours of detection (early warning), full report within 72 hours. Submission via nukib.gov.cz. If you're not sure whether the obligation applies, ask a lawyer — fines for non-reporting run into millions.
If the attacker exfiltrated personal data (and with today's double-extortion campaigns you should assume so), you're obliged to notify the data protection authority within 72 hours under GDPR. Often you also have to inform the data subjects themselves.
Ransomware is a criminal offence (extortion, unauthorised access to a computer system). File a criminal report even if you don't expect investigation — without it you can't claim most insurance payouts and it complicates writing off the loss for accounting.
If you have cyber insurance, call them now. Most policies cover IR team costs, legal counsel, recovery, and sometimes business interruption. Insurer dealbreakers: late notification, destroyed evidence, no due diligence done.
Employees: clearly tell them what to do (disconnect devices, don't reset passwords from infected machines, where to report issues). Clients / vendors / regulators: coordinate via the lawyer — what you say in the first days defines the narrative for the entire incident. PR damage from poorly handled communication can cost more than the attack itself.
Both NÚKIB and ENISA clearly recommend not paying. Reasons: (1) There's no guarantee you'll get a working decryptor — success estimates hover around 60%. (2) Paying funds the next attacks and marks you as a willing target — 80% of paying companies are hit again within 12 months. (3) Paying ransomware groups under sanctions (e.g. Russian groups) is potentially criminal in the EU/US.
There are situations where paying is a real option (destroyed backups + threat to life + no other way to recover). That decision always discuss with a lawyer, IR team, and insurer — never in the first hours of panic.
Days to weeks
Find out how the attacker got in (entry vector), where they went, exactly when. Without that, recovery restores the attacker too — who returns in a few weeks. The IR team helps with this; don't try it yourself unless you have incident forensics experience.
Restoring onto the same network is a risk. Build a new segment, a new domain (or thoroughly cleaned), restore there, verify cleanliness with EDR and a malware scan, then connect users. This adds days to recovery — but it's the only way to make sure the attacker doesn't come back.
First what the company can't operate without (email, ERP, key business apps). Then the rest. Not everything has to be restored on day one — some systems can wait weeks without impact. A pre-prepared business impact assessment helps.
Domain passwords, API tokens, OAuth refresh tokens, certificates, SSH keys, cloud credentials. The attacker likely had access to many of these — leaving them valid leaves a backdoor open. Do this in a coordinated way so users understand why they need to sign back in to everything.
Weeks after recovery
A structured debrief with the entire crisis team: what worked, what didn't, where we wasted time, what information we lacked. The goal isn't to find someone to blame — it's to get the uncomfortable lessons on paper while they're fresh.
Ransomware getting into the network is always the result of a specific defence failure — an unpatched system, a compromised account without MFA, a reported phishing email nobody followed up on. Find that specific hole and close it as priority 1.
The plan you actually used now has obvious gaps. Rewrite it. And in 6 months run a tabletop exercise — to refresh the playbook and verify the changes hold up under pressure.