What to Do After a Ransomware Attack: A Step-by-Step Response Guide

Quick Summary

• Isolate infected systems from the network immediately. Don’t power them off, that destroys evidence and encryption keys held only in memory.
• Don’t restore from backup until an investigation confirms which restore point is actually clean.
• Notify your cyber insurer before recovery work starts. Most policies require it and some mandate approved responders.
• Report the incident to the FBI, CISA, or the Secret Service. You only need to report once.
• Whether to pay the ransom is a legal and financial decision for counsel and your insurer, not a technical one for IT.
• A tested ransomware incident response plan and isolated, verified backups are what actually determine how fast and how expensive recovery is.

The instinct, when the ransom note appears, is to fix it fast: pull the systems down, wipe them, restore last night’s backup, be running again by lunchtime.

That instinct is the most expensive mistake available to you, and it is worth understanding why before you act on it.

What to Do in the First Hour After a Ransomware Attack

Isolate, don’t power off. Disconnect affected systems from the network: unplug ethernet, disable Wi-Fi, segment the affected VLAN. Do not shut them down. Encryption keys and attacker tooling sometimes live only in memory, and powering off destroys them along with much of the evidence about how far this reached.

Stop all restore and deletion activity. Tell everyone, explicitly, to stop. Well-meaning staff deleting encrypted files or kicking off a restore will destroy evidence and potentially overwrite the clean data you still need.

Protect your backups immediately. Modern ransomware targets backups first and often has been resident for weeks specifically to find them. Disconnect or lock backup systems now, before anyone touches them. If your backups are online and reachable from a compromised domain account, assume they are in scope until proven otherwise.

Notify your cyber insurer. Before recovery work starts. Most policies require prompt notification and many mandate the use of approved incident-response vendors; engaging your own people first can reduce or void cover. This is not a formality, it is a step that can determine whether the recovery is funded.

Engage legal counsel. Ransomware creates legal obligations before it creates technical ones, and counsel should be directing the sensitive parts of the investigation from the start.

Convene a response team and start a written log. Who decides what, who talks to staff, who talks to customers. Write down times, actions and decisions from this point forward: you will need it for the insurer, possibly for regulators, and certainly for the post-incident review.

Preserve everything. The ransom note, affected system images, logs, the timeline. CISA’s#StopRansomware guidance is the reference to work from.

Why Restoring From Backup Immediately Is Usually a Mistake

Because of one question that almost nobody asks in the first hour: restore into what?

If you restore into the same environment, through the same unpatched vulnerability or the same compromised credentials the attacker used to get in, you are rebuilding a house on the fault line. Organizations that skip remediation get encrypted a second time, sometimes within days, using access the attacker never lost.

There is also the matter of when. Ransomware is usually the last act. The dwell time before it (the period the attacker spent inside, moving laterally, escalating privilege, and locating your backups) means a backup from the night before the encryption may already contain their access. Working out how far back your last genuinely clean restore point is, is an investigation output, not a guess.

And restoring destroys evidence. That evidence determines whether data was exfiltrated as well as encrypted, which is the difference between an availability incident and a reportable data breach, with everything that follows from it.

Definition: double extortion. An attack where data is copied out before being encrypted, so the attacker can demand payment both to restore access and to not publish the stolen data. It means paying for a decryption key does not resolve the disclosure exposure.

Who Needs to Be Told, and in What Order

Your insurer, before your IT provider starts work. Prompt notification is usually a policy condition, and many policies require approved responders. Call them first.

Legal counsel. Counsel should be engaged early and may direct the investigation so that findings attract legal privilege where that applies. They also own the notification analysis: what is reportable, to whom, and within what deadline.

Report the attack to law enforcement. In the US, you can report a ransomware attack to the FBI through the Internet Crime Complaint Center (IC3), directly to CISA through its ransomware reporting channel, or to a US Secret Service field office. You only need to report through one of these; the agencies coordinate and notify each other from there. Reporting does not oblige you to do anything else, and law enforcement occasionally holds decryption keys or intelligence on the specific ransomware variant involved. It is also not purely a compliance step: organizations that involve law enforcement during a ransomware incident have cut their average breach costs by roughly $1 million compared to those that don’t, according to IBM’s Cost of a Data Breach research.

Regulators, patients and customers. This is a legal determination, not an IT one, and the clocks are short. Healthcare organizations handling protected health information have obligations under the HIPAA Security Rule and Breach Notification Rule, the kind of compliance pressure we’ve helped a Texas healthcare network client manage alongside strict uptime and cybersecurity requirements; financial institutions have their own regulator and examiner expectations; most US states impose their own notification requirements. Counsel decides. Not the IT team, and not your provider.

Should You Pay the Ransom?

This is the question everyone asks and the one this article will not answer for you, deliberately, because it is a legal, financial and insurance decision made with counsel and your insurer, not a technical one.

What is worth knowing going in:

• There are sanctions implications. Payments to sanctioned entities or jurisdictions can carry legal exposure regardless of the circumstances; see OFAC’s advisory activity. Counsel needs to run this analysis before any payment is contemplated.
• Paying does not reliably restore you. Decryption tooling supplied by attackers is frequently slow, incomplete or buggy. Paying buys a key, not a recovery.
• Paying does not undo exfiltration. If data was taken, it has been taken. A payment is a promise from someone who just extorted you.
• Your insurer likely has a position, and it may be binding on your cover.

The organizations that face this decision from the strongest position are the ones with tested, isolated backups, because they have an alternative to paying. Having that alternative is built long before the incident, not negotiated in the moment.

Would your backups survive this? A free IT assessment inventories every server, endpoint and application, flags what’s end-of-life or unsupported, and shows whether your backups are isolated and verified, before you need to find out.

The Ransomware Recovery Process: Three Tracks Running at Once

The single most useful thing to understand is that recovery is not sequential. Three tracks run at once, under different owners, and treating it as a queue is how weeks get lost.

Track One: Contain and Investigate: Isolate affected systems. Establish the entry point, the dwell time, what privilege was obtained, what moved laterally, and, critically, whether data left the building. This track produces the answer to “which restore point is clean.”

Track Two: Legal, Insurance and Notification. Runs in parallel from hour one, owned by counsel and the insurer. Notification deadlines are statutory and do not pause while IT works.

Track Three: Rebuild and Restore. Rebuild clean infrastructure, apply the remediation the investigation identified: patch the entry point, reset credentials estate-wide, remove persistence, then restore data from a verified-clean point and bring systems back in dependency order. Identity and authentication first, then core infrastructure, then applications, then endpoints.

Through all three, our managed IT services role is the operational one: the estate inventory that tells you what you actually have, the monitoring that shows whether anything is still moving, and the backup verification that tells you whether a restore point is real rather than assumed.

How Long Does Ransomware Recovery Take?

Honestly: it depends, more than anyone wants to hear, and anyone quoting you a standard figure is guessing.

What actually drives the timeline is how quickly it was detected and isolated, whether backups survived and had been tested, how complete the asset inventory is, how many systems are involved and how entangled their dependencies are, and whether the entry point was found quickly. An organization with a current inventory, isolated tested backups and monitored infrastructure is working in a different order of magnitude from one reconstructing what it owns while under pressure.

What Makes the Difference Before It Happens

Everything that determines how bad a ransomware incident becomes is decided before it starts, and the biggest single lever is having a written, tested ransomware incident response plan. Organizations with a tested incident response plan have saved an average of $2.66 million per breach compared to those without one, the largest cost reducer measured in IBM’s Cost of a Data Breach report. A plan doesn’t need to be complicated. It needs to name who makes the isolation call at 2am, who contacts the insurer, who talks to staff, and where the current asset inventory and backup verification records live, so nobody is improvising that on the day itself.

Everything below is what a good plan is built on:

• Backups that are isolated and tested. Not just running. Isolated, so a compromised domain account cannot reach them, and tested, so you know a restore works. The standard reference point is the 3-2-1 rule: three copies of critical data, on two different types of media, with at least one copy offline or offsite. A backup job that reports success and has never been restored from is a belief, not a capability.
• An asset inventory that is current. You cannot secure, or rebuild, an estate you cannot enumerate. In the first week of a new environment, the pattern is consistent: unsupported operating systems in production, firmware years behind, credentials still active for people who left, and backup jobs failing quietly for long enough that nobody remembers the last successful restore.
• Patching and end-of-life discipline, because most intrusions use a vulnerability that already had a fix.
• Access that gets removed when people leave, automatically.
• Monitoring that would notice the dwell time. The weeks of lateral movement before encryption are the window where this is cheap to stop. Most organizations discover ransomware from the ransom note, which is the last possible moment.
• Multi-factor authentication everywhere it is supported, and phishing awareness, because that is still how a large share of intrusions begin. This is the kind of layered control our Security as a Service offering is built around: endpoint, network, and identity protection working together instead of as separate purchases.
• Multi-factor authentication everywhere it is supported, and phishing awareness, because that is still how a large share of intrusions begin. This is the kind of layered control our Security as a Service offering is built around: endpoint, network, and identity protection working together instead of as separate purchases.