The First Hour After a Ransomware Attack: A Response Checklist

Ransomware doesn't announce itself politely. It shows up as a locked screen, a note in a text file where your documents used to be, or a help desk ticket that says "my files look weird" fifteen minutes before three more come in. What you do in the next hour matters more than almost any decision you'll make about the incident afterward.

Minute 0–5: Isolate, don't investigate

The instinct to understand what's happening is strong. Resist it. The first move is physical and network isolation, disconnect the affected machine from the network (unplug the cable, disable Wi-Fi), and do the same for any machine showing similar symptoms. Do not power the machine off yet; a live memory image can matter later for forensics. Isolation stops lateral spread, which is the difference between one infected laptop and an encrypted file server.

Minute 5–15: Activate the incident response plan, not an improvised one

If you have a documented incident response plan, this is the moment it earns its cost. Pull it up and follow it. If you don't have one, this is the moment you're improvising under pressure, which is precisely how bad decisions get made. Either way, get your MSP or security team on the phone immediately, not by email, not by ticket.

The goal of the first hour isn't to fix the problem. It's to stop it from getting bigger while the right people get involved.

Minute 15–30: Identify the blast radius

With the initial machines isolated, the next task is scoping: which systems, shares, and backups does the affected account or machine have access to? Ransomware that lands on one workstation but has domain admin credentials cached is a very different emergency than one contained to a single user's local files. This is where 24/7 SOC monitoring and EDR tooling pay for themselves, automated containment can isolate affected endpoints in seconds, before a human even reads the alert.

Minute 30–45: Preserve evidence and notify the right people

Do not wipe or reimage anything yet. Screenshots of ransom notes, logs from your EDR platform, and a timeline of when symptoms first appeared are all necessary for both recovery and, if applicable, regulatory reporting. Depending on your industry, this is also the point where legal counsel and, if patient, financial, or otherwise regulated data may be involved, your compliance officer need to be looped in.

Minute 45–60: Confirm what backups actually exist and whether they're clean

This is the moment every disaster recovery test you have or haven't done gets tested for real. Confirm your most recent clean backup point, and, critically, confirm that the backup itself wasn't encrypted or compromised (ransomware increasingly targets backup systems specifically). If your backups are offline, air-gapped, or immutable, this is a much shorter conversation than if they're sitting on the same network the attacker just walked through.

What not to do

• Don't pay before consulting your incident response team and legal counsel. Payment doesn't guarantee recovery, and in some jurisdictions may carry legal exposure.
• Don't reboot or reimage affected machines before evidence is preserved, you may destroy the ability to determine how the attacker got in.
• Don't assume it's over once encryption stops. Attackers who achieved encryption often had access for days or weeks beforehand, and may have exfiltrated data before the visible attack even started.

The best response is the one you rehearsed before you needed it

Every step above assumes a plan already exists, documented, tested, and known by the people who'll execute it under pressure. Businesses without that plan don't get a slower version of this response; they get a different, much worse hour, spent figuring out who to call while the infection spreads.