Ransomware Recovery: What to Do When Your Business Gets Hit

Ransomware recovery when it actually happens is not a moment to figure things out for the first time. The decisions that matter — whether to pay, who to call, what to communicate publicly, how to restore — need to be made under time pressure with imperfect information. The businesses that come through ransomware best are the ones that had thought through the playbook in advance. Here's what that playbook should include.

The First 24 Hours

The first day's priorities, in order:

• Isolate — disconnect affected systems from the network to prevent spread. Power-on but network-isolated preserves forensic evidence; total shutdown loses it.
• Engage your incident response team — internal security plus external incident response firm if you have one retained. If not, this is the first call.
• Notify your cyber insurance carrier — within hours, not days. They have their own incident response process and approved vendors.
• Notify law enforcement — FBI's IC3 for federal jurisdiction. The reporting itself is required for some insurance claims and can produce useful threat intelligence on the specific variant.
• Engage legal counsel — regulatory notification requirements may apply; counsel guides the disclosure strategy
• Assess the scope — what's encrypted, what's accessible, what backups are uncompromised, what data was potentially exfiltrated
• Stand up incident communications — leadership briefings, employee communication, customer notification planning

The Pay-or-Restore Decision

The most contentious decision is whether to pay the ransom. The honest answer is "it depends," and the factors:

Reasons not to pay: paying funds further criminal activity (and may violate sanctions law in some cases), no guarantee the decryptor will work or that data won't be released anyway, payment marks the business as one that pays which may invite future attacks, and recovery from clean backups is often faster than waiting on decryption support from the attackers.

Reasons to consider paying: backups are inadequate or compromised and rebuilding from scratch isn't feasible, the data is irreplaceable and unique, the operational impact of extended downtime exceeds the ransom plus recovery costs, or specific regulatory or contractual obligations make data restoration time-critical.

The decision should be made by leadership in consultation with incident response, legal counsel, and the insurance carrier. It shouldn't be made by the IT team under pressure in the first few hours.

The Restoration Process

If restoring from backup (the preferred path when feasible):

• Confirm backup integrity before restoring — verify backups weren't compromised before the encryption event
• Rebuild infrastructure on clean systems, not on the systems that were compromised
• Address the root cause before restoring — bringing back the same vulnerable systems just sets up the next attack
• Restore in priority order — critical systems first, then less-critical, then archival
• Validate functionality before declaring services restored — not just "the data is back" but "the applications work and users can do their jobs"
• Reset credentials across the environment — every credential should be considered potentially compromised
• Increase monitoring during the recovery period — attackers sometimes return through whatever vector got them in originally

The Communication Strategy

Communications during and after ransomware incidents are consequential. Internal communication needs to keep employees informed without producing panic. Customer communication needs to be factual without overcommitting to recovery timelines. Public communication needs to be reviewed by legal counsel before release. Regulatory communication has specific timelines (HIPAA, SEC, state breach notification laws) that vary by what data was involved.

The communication strategy should be planned in the incident response plan, not improvised during the incident. Pre-drafted communication templates for various scenarios save substantial time and reduce the risk of unforced errors.

The Post-Incident Lift

After the immediate incident is resolved, the work isn't done. The lessons learned from a ransomware incident should drive specific improvements: address whatever initial access vector was used, improve monitoring on whatever signals the incident produced, harden the controls that didn't work, update the incident response plan with what was learned, and conduct post-incident reviews with leadership to align on the changes coming out of the incident.

Most importantly, the experience should change the security posture going forward. Businesses that survive ransomware and don't make subsequent investment in security typically experience repeat incidents. If you're scoping ransomware preparedness for your business — before an incident happens — a free assessment can identify the highest-impact preparedness gaps.