Ransomware Demands More Than Backups

Druva’s Badri Raghunathan offers commentary on how ransomware demands more than backups. This article originally appeared in Insight Jam, an enterprise IT community that enables human conversation on AI.

Ransomware’s gotten easier to launch and harder to contain. Even teams with solid controls can still end up with encrypted systems and reinfections upon recovery. That’s not a reason to give up on prevention. It’s a reason to stop treating backup and recovery as a compliance-driven insurance problem and start treating it as an operational capability. 

When ransomware hits, the gap usually isn’t a lack of tools. It’s the ever-evolving threat landscape and a lack of repeatable, verifiable cyber recovery processes. Recovery becomes a scramble: Which systems are safe? Who has the authority to shut things down? What do we restore first? How do we avoid reintroducing the attacker during rebuild? 

A practical ransomware recovery strategy comes down to three phases: prepare before the incident, control the blast radius during it, and restore in a way that’s measurable, verifiable, and less likely to repeat:

• Prepare in advance: Recovery starts now, not after an attack. Make decisions today that limit attacker movement and speed rebuilding. It’s critical to make cyber recovery a part of the overall incident response process and make sure it’s tested and verified on an ongoing basis – preferably via automation.
• Harden identity & access: Most ransomware involves credential abuse. Enforce least privilege, reduce standing admin access, separate admin accounts, and tighten controls around privileged actions.
• Protect management planes: Backup consoles, hypervisors, and admin tools are high-value targets. Lock them down with MFA, restricted access, monitoring, and role separation.
• Document a usable incident plan: Define roles, escalation paths, contacts, and external partners now, including legal, insurance, forensics, and law enforcement. 

Align backup testing with your incident response process. Backups should be isolated, immutable, and regularly restored—if recovery hasn’t been tested under pressure, it can’t be trusted. 

A simple way to make this real is to define three things for critical services: 

• RPO: How much data loss you can tolerate 
• RTO: How long you can be down 
• Restore order: What must come back first, second, third 

 Those decisions are what turn backups into recoverability and provide assurance for cyber resiliency.  

When Ransomware Hits, Run Containment & Investigation in parallel

A lot of guidance says, find the root cause first, then recover. In the real world, you don’t usually get that luxury. The better mental model is two tracks: contain quickly to stop the bleeding, and investigate in parallel to understand scope and entry. 

Some ransomware is loud, but many incidents start quietly: unusual authentication patterns, privilege changes, file modification, disabled tools, suspicious backup deletions, or exfiltration alerts. If you suspect ransomware activity, assume the attacker’s already moving laterally. 

Containment Moves That Buy You Time

• Isolate affected hosts and segments, not just individual endpoints 
• Disable or rotate compromised accounts, and revoke active sessions and tokens where possible 
• Block known malicious IPs and command-and-control paths 
• Freeze risky admin activity until you can validate who’s who 
• Protect backup infrastructure and management planes immediately 

At the same time, scope the incident: which accounts were used, what was accessed, what persistence exists, what was encrypted, and whether data was exfiltrated. Forensics matters, but so does uptime: capture key logs, snapshots, configuration changes, and representative system images without delaying containment, and coordinate early with legal and incident response teams. 

Decide on Payment with Governance, Not Panic

One of the most stressful decisions in a ransomware event is whether to pay for a decryption key. There isn’t a single answer that fits every organization, but there are consistent truths: 

• Payment isn’t guaranteed for recovery. Decryptors may fail or never arrive. 
• It won’t stop data leaks. Exfiltrated data can still be published. 
• It can raise future risk. Signals willingness to pay and may attract repeat attacks. 
• Legal matters. Sanctions, compliance, insurers, and counsel should be involved. 

The point isn’t to moralize. It’s to ensure the decision is made through a defined process with the right stakeholders, technical feasibility of restoration, and legal guidance. 

Remediate Before You Restore, or You’ll Reintroduce the Attacker

Recovery fails when organizations restore systems into an environment that’s still compromised. 

Before you bring critical services back: 

• Close the initial access path  

• Reset privileged credentials and remove unnecessary standing access 

• Validate administrative control planes  

• Confirm security tooling is healthy and reporting  

A useful practice here is to rebuild from known-good baselines, not from “whatever was running yesterday.” Golden images and clean configurations speed recovery and reduce uncertainty. 

Restore in Stages, with Verification Gates

The fastest restore is the one you can trust. That means restoring in a sequence, into a controlled environment, with checks before reconnecting systems to production. 

A common restore order prioritizes foundational layers first — identity, security, and infrastructure — before business services, data platforms, and endpoints. 

Your environment will differ, but the principle holds: restore what you need to authenticate, manage, observe, and protect before you restore what users rely on. 

Before declaring recovery complete, validate a basic checklist: patch status, clean security scan, no indicators of compromise, reviewed privileged access, and verified data integrity. Skipping this risks restoring clean data onto infected systems, or reinfecting from a compromised image. 

Run a Blameless Postmortem

After an incident, avoid focusing on a single user or system — most ransomware succeeds because multiple controls fail together across identity, segmentation, patching, monitoring, admin hygiene, or backups. 

A blameless postmortem should answer: How did access occur? How did privilege escalate? How did lateral movement happen? What failed to alert us? What slowed recovery? What prevents this from happening again? 

Then prioritize one or two high-leverage fixes, often hardening privileged access, tightening segmentation, improving backup isolation and immutability, and running regular restore drills. 

Closing the Gap is About Operational Readiness

Ransomware resilience isn’t just about keeping attackers out. It’s about being able to bring systems back in a way that’s fast, repeatable, and defensible. 

If you want to close the ransomware recovery gap, don’t wait for an incident to discover how your organization makes decisions under pressure. Define the process now, test it, and make recovery a practiced capability, not an improvised one.