# Ransomware Response: The First 24 Hours > A defensive checklist for the first day of a ransomware incident: what to isolate, what to preserve, who to call, and the mistakes that make recovery harder. - Published: 2026-08-05T00:00:00.000Z - Tags: Ransomware, Incident Response - Author: RuntimeRebel Editorial - Canonical: https://runtimerebel.com/guides/ransomware-response-first-24-hours The first day of a ransomware incident decides how the next month goes. The goal of this guide is narrow: the defensive moves that consistently help, in rough order, and the early mistakes that consistently make things worse. It is not a substitute for a rehearsed incident-response plan or professional IR support — it is what to hold onto if the incident arrives before the plan does. ## Contain, but do not destroy Disconnect affected machines from the network — pull the cable, disable the adapter, or isolate at the switch. Suspend, rather than power off, virtual machines where you can. What you should **not** do is wipe, rebuild, or power-cycle machines in a rush. Memory holds encryption keys, running processes and attacker tooling that forensics can sometimes use — some ransomware families have had flaws that made partial recovery possible, but only when evidence survived. Contain first; clean up later, deliberately. ## Preserve evidence while it exists Capture what the attacker touched before logs roll over: EDR alerts, authentication logs, VPN and firewall logs, and a copy of the ransom note and any sample of the encrypting binary. Note timestamps of the first known malicious activity. This evidence drives three things later — scoping, insurance, and the legal reporting you may owe. ## Protect the backups you still have Assume the attacker looked for your backups before detonating. Verify that offline or immutable copies exist and **disconnect backup infrastructure from the compromised domain** before touching anything else with it. The most expensive version of this incident is the one where recovery media is encrypted on day two. ## Establish scope before negotiating anything Identify patient zero if you can, but prioritise the blast radius: which segments, which identity tiers, which data stores. Modern operators almost always **exfiltrate data before encrypting**, so treat the incident as a data breach until proven otherwise — that assumption changes your legal obligations and your communications plan. ## Make the calls Within the first day, engage: your incident-response retainer or an external IR firm; your cyber-insurance carrier (many require notice before you spend money or negotiate); legal counsel; and law enforcement. Regulated industries and jurisdictions carry breach-notification clocks that may already be running. ## Decisions to make slowly Whether to pay is a business and legal decision, not a technical one — some payments are unlawful depending on who the operator is, payment does not guarantee recovery, and it reliably marks you as a payer. Do not communicate with the operator except through counsel or experienced negotiators. And do not announce recovery timelines publicly on day one; you do not yet know the scope. ## Prepare for this before it happens The checklist above is far cheaper rehearsed: offline backups tested by restoring them, an IR contact list that exists on paper, and network segmentation that makes "isolate the segment" a real option. Our [ransomware coverage](/blog/tag/ransomware) tracks who is being hit and how, and the [threat dashboard](/threats) shows the current activity level. --- Curated evergreen guide, produced with AI assistance and maintained by the site (https://runtimerebel.com/editorial). Quote with attribution and a link to the canonical URL: https://runtimerebel.com/guides/ransomware-response-first-24-hours