Ransomware Readiness: Where Most Organizations Actually Fail

Most organizations that get hit by ransomware aren't undone by the encryption itself, they're undone by discovering, mid-incident, that their backups were also encrypted, that nobody knew who had authority to make a six-figure decision at 2 a.m., or that the "isolated" segment the attacker started in wasn't actually isolated from anything that mattered. Readiness isn't a single control; it's whether these gaps get found in a tabletop exercise or during the real thing.

Backups: the control that matters most, tested the least

A backup that's reachable from the same domain admin credentials as production isn't a backup, it's part of the blast radius. The specific, verifiable requirements:

• At least one backup copy that's genuinely offline or immutable (not just "on a different server"), so a compromised domain can't reach it.
• Backups tested by actually restoring from them on a schedule, not just confirmed as "completed successfully" by a job log. A backup nobody has ever restored from is a hypothesis, not a control.
• Backup retention long enough to reach back past the dwell time before encryption, ransomware operators often sit inside a network for days or weeks before triggering, which is long enough to have already encrypted your most recent backup generations too.

Segmentation: does it stop lateral movement, or just look like it does

"We have VLANs" is not the same claim as "an attacker with a foothold on a workstation cannot reach the domain controller." The difference only shows up under an assessment that actually tries to move laterally, see our Network Security service for how we test this specifically, rather than reviewing a network diagram and taking segmentation on faith.

The decision that stalls incident response

Most incident response plans specify technical steps and skip the one decision that predictably causes hours of delay: who has the actual authority to approve a costly action, taking production systems offline, engaging outside counsel, deciding on ransom, at 2 a.m. without waiting for a full leadership meeting. If that person and their backup aren't named in the plan by role, not just "leadership will decide," the plan has a gap that only shows up when it's too late to fix it.

Detection: the earlier you notice, the smaller the blast radius

Ransomware has a deployment phase before the encryption phase, credential harvesting, lateral movement, and often disabling of backup and EDR agents. CISA's #StopRansomware guidance is a solid baseline for what to actually monitor for during that window, since encryption is the last, loudest, and most expensive stage to catch it at.

What to check before assuming you're ready

1. Restore a real system from backup, end to end, and time how long it takes.
2. Confirm your backup credentials are separate from your domain admin credentials.
3. Run a tabletop exercise that includes the decision-making chain, not just the technical playbook.
4. Verify segmentation with an actual test, not a network diagram review.
5. Check whether your domain's email authentication is configured well enough to make phishing, still the most common ransomware entry point, measurably harder.

If you're not confident in the answer to more than one of these, that's exactly the gap a penetration test or an incident response readiness review is built to surface before it's tested for real. A meaningful share of real ransomware incidents also trace back to a compromised vendor or managed service provider, see our piece on third-party and supply chain risk for what that gap actually looks like.