How should organisations prepare for ransomware if they want to avoid paying ransom?

They should build and repeatedly test a recovery model that proves critical services can be restored without attacker cooperation. That means defining minimum viable operations, validating clean backups, rehearsing restoration sequencing, and assigning decision authority before an incident. Payment becomes less likely when recovery is demonstrated, not assumed.

Why This Matters for Security Teams

ransomware preparedness is not just an incident response exercise. It is a resilience test that determines whether an organisation can keep operating when adversaries encrypt systems, destroy backups, or steal credentials to pressure payment. Current guidance from the ENISA Threat Landscape and NHIMG research shows that attackers increasingly combine extortion with identity compromise, which means recovery depends on both restore capability and access control. The practical objective is to make payment unnecessary by proving restoration is possible under stress.

That is especially important when service accounts, secrets, and administrative sessions are part of the blast radius. NHIMG’s Ultimate Guide to Non-Human Identities notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. In ransomware events, those same identities often become the path to backup deletion, backup encryption, or re-entry after containment. In practice, many security teams encounter the need to restore only after production has already been disrupted and attacker access has already been assumed away.

How It Works in Practice

A no-ransom recovery model starts with defining minimum viable operations. Security, IT, and business owners should identify which services must come back first, which dependencies can wait, and which systems can be isolated without stopping recovery. That sequencing matters because ransomware rarely affects one system in isolation; it often spreads through shared authentication, remote management, and backup tooling.

Recovery design should then prove that clean data exists and can be restored at speed. This includes immutable or offline backups, frequent restore tests, and verification that backup admin credentials are separate from production admin credentials. The backup process should be treated as a protected service, not just a storage feature. Where identities are involved, use strong separation of duties so that compromised operator accounts cannot delete recovery points or approve their own access.

Practitioners should also rehearse decision-making before an incident. That means assigning authority for isolation, restoration, communications, and legal review in advance. The best playbooks assume partial compromise, not perfect visibility. For example, a restore test should include:

• Validation that backups are clean before restoration begins
• Testing restoration sequencing for core identity, file, and application services
• Checking whether privileged access, secrets, and tokens were reused across environments
• Confirming that service accounts can be rebuilt or reissued, not just re-enabled

NHIMG analysis of the MGM Resorts Breach 2023 and the Caesars Entertainment Breach 2023 highlights a recurring pattern: identity compromise can precede destructive extortion, so recovery has to assume attacker knowledge of internal access paths. These controls tend to break down when backup systems share the same identity plane as production because the attacker can encrypt both recovery data and the controls meant to protect it.

Common Variations and Edge Cases

Tighter recovery controls often increase operational overhead, requiring organisations to balance faster restore times against stricter segregation, more testing, and added change management. That tradeoff is real, especially in environments that run legacy applications, thin IT teams, or cloud workloads with tightly coupled services. Current guidance suggests this is not a reason to skip rigor, but it does mean the recovery plan should be prioritised by criticality rather than applied uniformly.

There is no universal standard for ransom decision-making, but best practice is evolving toward pre-defined governance that removes panic from the response. Some organisations will never fully disconnect backups from production because of operational constraints; in those cases, compensating controls should include separate admin identities, delayed deletion windows, and offline copies of the most critical restore sets. The same logic applies to SaaS, IaaS, and OT environments, where restoration can depend on the vendor, contractual support, or air-gapped procedures.

Identity and credential hygiene also matter more than many teams expect. If attackers can reach backup consoles through over-privileged service accounts, or if secrets are stored in code or CI/CD tools, recovery confidence drops sharply. NHIMG research shows that 96% of organisations store secrets outside secrets managers in vulnerable locations, which is a direct resilience problem as well as an access-control issue. Organisations that want to avoid paying ransom should treat NHI governance, restoration rehearsals, and backup isolation as one control system, not separate programs.

Related resources from NHI Mgmt Group

• How should organisations prepare for ISO 27001:2022 certification if they rely on cloud access and admin credentials?
• What should organisations measure if they want to know fraud controls are working?
• How should organisations prepare their NHI programmes for Agentic AI adoption?
• How can organisations prepare identity programmes for AI-enabled access?