Home / Guides & Insights / Ransomware: first 24 hours
The first 24 hours after a ransomware attack: an engineer's playbook
What to do, hour by hour, when the screens go dark — from someone who has taken the 2 a.m. call. What you do (and don't do) in the first day decides most of the outcome.
In the first 24 hours after ransomware hits: disconnect affected machines from the network but do not power them off, don't wipe anything, don't touch the ransom note beyond photographing it — then activate your response: isolate, assess scope, preserve evidence, notify insurer and counsel, and restore from clean backups only after the entry point is closed. Paying is a last resort with legal strings attached, not a shortcut.
The phone rang at two in the morning. A rehabilitation centre for disabled children — every workstation locked, check-in dead, treatment logging dead, monitoring dead. In that building an outage isn't an inconvenience; it's a safety problem. We had them fully back in two hours, and the reason wasn't heroics. It was that the right things happened in the right order. This is that order, written down for the day you need it.
Before the timeline: three things that decide everything
Honesty first: the outcome of your first 24 hours is mostly decided before hour zero. Three things separate a two-hour story from a two-week one — backups that an attacker can't reach or encrypt (offline or immutable copies, restore-tested, not just scheduled), some form of endpoint detection that shows you where the attacker went, and a one-page plan with phone numbers that don't live on the machines that are now encrypted. If you have none of these, read this anyway — the order still matters — then fix that today.
Hour by hour
Cut the network, not the power
Disconnect affected machines from the network — pull cables, kill Wi-Fi, disable the VLAN. But do not power machines off: memory holds evidence (and sometimes encryption keys) that dies with a shutdown. Don't wipe, don't reinstall, don't reboot "to see if it helps." Photograph the ransom note on screen with your phone. If spread is active and you can't tell how far, isolating at the switch or firewall beats chasing individual boxes.
Move to a clean channel and call for help
Assume email and chat are compromised — coordinate by phone or personal devices. Wake up whoever runs IT (internal or external). Call your cyber insurer's hotline before making recovery decisions: most policies require it, and acting first can jeopardize coverage. If you have an incident response retainer, this is what it's for. Appoint one person to lead and one to take notes with timestamps — those notes become your legal and insurance record.
Map what's hit — and check the backups first
Two questions dominate everything: are the backups intact, and how did they get in? Verify backups from a known-clean machine — modern crews hunt backup servers first. Inventory what's encrypted vs. untouched. Identify the likely entry point (phishing, exposed remote access, unpatched edge device — it's usually one of those three). Check for signs of data theft, not just encryption: most 2026 ransomware is double extortion, and stolen data changes your legal obligations.
Close the door before you rebuild the house
Restoring while the attacker still has access is the classic mid-incident mistake — you'll be re-encrypted, and this time they'll be angrier. Reset credentials from a clean system (all admin accounts, VPN, remote access, service accounts), close the entry point, and check for persistence: new accounts, scheduled tasks, remote-access tools you didn't install. Only then does restoration start, onto clean or rebuilt systems, most-critical services first.
Bring it back in order of pain, and meet your obligations
Restore by business priority, not alphabetically — the rehab centre needed patient check-in and monitoring first, accounting could wait a week. Verify each restored system is clean and functioning before users touch it. In parallel, handle obligations: counsel advises on breach-notification duties (they vary by state and data type), your insurer gets a status, and if data was stolen, law enforcement (FBI/IC3 in the US) should be in the loop. Then write down the timeline while it's fresh — future-you, your insurer, and possibly a regulator will all want it.
Should you pay the ransom?
Our position, having sat with businesses facing this question: paying is a last resort, not a strategy. Decryptors delivered after payment are slow and buggy when they work at all; payment doesn't un-steal exfiltrated data; and it marks you as a payer. There's also a hard legal edge many owners don't know: payments to sanctioned entities can violate US OFAC rules — which is why this decision runs through counsel and your insurer, never through a wallet address at 4 a.m. The companies that don't face the question are the ones whose backups survived. That's the whole argument for ransomware-resistant backup design, made better than we can make it here.
What the two-hour recovery actually required
People hear "fully restored in two hours" and assume wizardry. The real list is boring: backups that existed off the compromised network and had been restore-tested, so we knew they'd come back; a clear picture of which systems mattered most, so nobody debated priorities at 3 a.m.; and a phone number that reached an engineer with authority to act immediately. None of that can be created during the incident. All of it can be created this week — that's the actual lesson of the story, and it's the checklist in our 20-point security baseline.
The mistakes that make it worse
- Powering everything off. Kills forensic evidence and sometimes recovery options. Disconnect, don't shut down.
- Restoring before eradicating. Re-encryption within days is the standard price of this shortcut.
- Negotiating solo. Talking to the attacker without counsel/insurer involvement can void coverage and create legal exposure.
- Quiet cleanup. Skipping legally required breach notifications converts an IT incident into a regulatory one.
- No notes. Every hour undocumented is an hour you'll reconstruct badly for the insurance claim.
- Declaring victory at "it boots." Without confirming the entry point is closed and persistence removed, you're on the attacker's schedule, not yours.
Day two through week four: what happens after the adrenaline
The 24-hour playbook gets you operational. The following weeks decide whether it happens again. Days 2–7 are the hardening sprint: every finding from the incident becomes a ticket — the exposed remote access gets MFA or dies, the flat network gets segmented, EDR lands on everything that lacked it, and credentials that even might have been observed get rotated. This is also when the insurer's paperwork starts in earnest: proof of loss, forensic summaries, invoices for response costs. The timestamped notes from hour one are what make this week merely tedious instead of contentious.
Weeks 2–4 are for the two conversations companies skip at their peril. First, customers and partners: if their data was involved, counsel has already driven notifications — but even when it wasn't, controlled honesty with key accounts beats the rumor mill; we've watched transparency win renewals that silence would have lost. Second, the post-incident review: one meeting, blameless by rule, producing three lists — what worked, what failed, what changes by when, with owners. Write it down and calendar the follow-ups. An incident you paid for in downtime and didn't convert into hardening is the most expensive kind of tuition there is.
Prepare tonight: the 45-minute version
If this article found you before the bad day, three actions tonight change your worst-case more than anything else you'll do this quarter. One: check your backups' reachability — from a domain-admin account, can you browse to and delete backup files? If yes, so can ransomware; fix that this week (offline copy or immutability). Two: write the phone tree on actual paper — IT lead, insurer hotline, emergency responder, counsel — and put copies where encrypted screens can't eat them. Three: pick your incident commander now, plus a deputy for vacations. Total time: about 45 minutes. The full version is our 20-point baseline, but these three are the difference between a two-hour story and a two-week one.
Frequently asked questions
Should I turn off my computer during a ransomware attack?
Disconnect it from the network immediately, but leave it powered on. Memory contains evidence and occasionally material that helps recovery; both are destroyed by shutdown. The goal is isolation, not power-off.
Does cyber insurance cover ransomware?
Most cyber policies cover response costs, recovery, and sometimes payments — but coverage typically depends on the security controls you attested to (MFA, backups, EDR) and on notifying the insurer before taking major actions. Read your policy before an incident, and see our guide to insurer requirements.
How do ransomware attacks usually start?
Overwhelmingly through one of three doors: phishing that steals credentials, internet-exposed remote access (RDP/VPN) without MFA, and unpatched edge devices like firewalls and VPN appliances. Closing those three doors removes most of the risk — which is why they top every checklist we write.
Do we have to report a ransomware attack to anyone?
Often yes, and the list is longer than people expect: state breach-notification laws if personal data was involved, sector regulators (HIPAA for health data), your insurer as a policy condition, sometimes law enforcement for the claim, and contractual notice duties to customers. Which apply depends on your data and state — exactly why counsel joins in hour two, not day five.
How long does recovery actually take?
With clean, tested, offline backups and a clear plan: hours to a few days. Without them: commonly weeks, sometimes never fully. The spread is that wide, and it's decided almost entirely before the attack.
Emergency: get help now Incident response, before you need it
This playbook is general guidance aligned with NIST SP 800-61r3 practice, not legal advice. Notification duties and payment legality depend on your jurisdiction, data, and policy — involve counsel early.