What do organisations get wrong when they assess ransomware readiness?

Why This Matters for Security Teams

Ransomware readiness is often judged by how many copies exist, but that framing misses how attackers actually win: they disable identity controls, move laterally, and pressure recovery paths before the business can respond. The practical question is not whether backups exist, but whether privileged access, segmentation, logging, and restoration can withstand active abuse. ENISA’s Threat Landscape continues to show ransomware as a business-disrupting campaign, not just a data encryption event.

NHI Management Group research shows why identity matters here: 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage. That is a readiness problem, not a recovery-only problem, because leaked API keys, service account credentials, and vault misconfigurations often give attackers the access needed to sabotage backups or encrypt at scale. In practice, many security teams discover this only after the incident response bridge is already filled with failed restore attempts and uncertain privilege boundaries.

How It Works in Practice

Effective ransomware readiness starts with assuming the attacker will try to reach backup systems, identity stores, and remote administration tools before launching encryption. That means testing whether privileged accounts are isolated, whether admin credentials are vaulted and rotated, and whether restoration can happen from clean, immutable sources. Identity-centric controls matter because the common failure mode is not just malware on endpoints, but compromised access to hypervisors, cloud consoles, backup software, and directory services, as seen in incidents such as MGM Resorts Breach 2023 and Cisco Active Directory credentials breach.

Practitioners should evaluate readiness across four layers:

• Identity hardening: privileged access management, MFA, and strict separation between daily work and recovery roles.
• Recovery integrity: immutable backups, offline copies where justified, and restore tests that include directory services and SaaS control planes.
• Detection and containment: logging that can confirm which identities were used, where they moved, and which systems were touched.
• Decision readiness: executive authority to isolate systems, delay risky restores, and accept temporary business disruption.

NHIMG analysis of the Caesars Entertainment Breach 2023 reinforces the point that credential theft can precede extortion by days or weeks, which makes pre-incident identity hygiene part of readiness. Current guidance suggests treating backup validation, identity recovery, and incident command as one exercise, not three separate programs. These controls tend to break down when backup credentials share the same trust domain as production admin accounts because a single compromise can disable both protection and restoration.

Common Variations and Edge Cases

Tighter recovery control often increases operational overhead, requiring organisations to balance rapid restoration against stronger access segregation and test discipline. That tradeoff becomes more visible in hybrid estates, where legacy servers, SaaS platforms, and cloud storage each have different restore procedures and different admin models. There is no universal standard for this yet, but best practice is evolving toward role-separated recovery access, immutable logging, and rehearsed approval chains for high-impact restores.

Two edge cases are frequently missed. First, organisations with excellent backups but weak identity governance may still fail because attackers can delete snapshots, alter retention settings, or lock operators out of the console. Second, groups with strong endpoint security may still be exposed if third-party access, service accounts, or automation tokens are left active during a crisis. The NHIMG guide notes that only 5.7% of organisations have full visibility into their service accounts, which is a serious blind spot when those accounts can reach backup infrastructure or orchestration tools.

In older environments, offline recovery media and manual procedures may still be the safest fallback, while cloud-native environments need strong control-plane logging and recovery-time identity checks. Organisations get this wrong when they measure readiness by backup frequency alone instead of proving they can restore cleanly under attack, with the same access restrictions that would exist during a real incident.

Related resources from NHI Mgmt Group

• What do organisations get wrong when they rely on certification alone to evaluate passwordless readiness?
• What do organisations get wrong when they secure AI only at the model layer?
• What do organisations get wrong when they let AI assistants handle privacy lookups?
• What do organisations get wrong when they treat identity verification as a pilot project?