Ransomware Readiness When Backups Are Not the Answer

Ransomware planning still tends to be built around a scenario that has become the less common one: files encrypted, systems halted, a decryption key offered for payment. That scenario still occurs. But a large share of extortion now involves no encryption at all.

That shift matters because it invalidates the control most organizations rely on. Backups answer encryption. They do not answer publication.

1. Extortion without encryption

The economics changed. Encrypting an environment is noisy, technically demanding, and increasingly likely to be interrupted. Copying data out is quieter, faster, and produces the same leverage. Many groups now steal data and threaten to publish it, skipping encryption entirely.

Against that model, a tested restore process is necessary and insufficient. An organization can restore every system, resume operations by the afternoon, and still face the disclosure of client records, employee data, or contractual material — with the regulatory and reputational consequences that follow.

Layered on top is pressure applied to third parties: contacting clients, partners, journalists or regulators directly to increase urgency. The incident becomes a communications and legal event, not only a technical one.

2. Access is usually bought, not earned

The groups that deploy ransomware are frequently not the ones that gained entry. Initial access brokers sell footholds; affiliates operate the extortion using tooling built by someone else. This has two implications for defenders.

First, entry is usually unremarkable — valid credentials, an unpatched edge device, an exposed remote access service, or a supplier connection. It rarely requires anything novel.

Second, there is normally a dwell period between access and impact. That window is where detection is possible and where most organizations lose the opportunity, because the activity looks like ordinary administration.

3. What actually reduces exposure

• Immutable, isolated backups. Backups that cannot be altered or deleted with production credentials. Attackers target backup infrastructure deliberately and early.
• Restoration tested at business scale. Not a file recovery test — a rehearsal of bringing a material service back, timed, with the dependencies that make it work.
• Privileged access constraints. Eliminating standing domain administration removes the mechanism most commonly used to move from foothold to enterprise-wide deployment.
• Egress visibility. If the threat is data leaving, then detecting bulk outbound transfer matters as much as detecting malware.
• Edge and remote access hygiene. Internet-facing appliances and remote access services patched on a defined cadence, because they are where the initial foothold repeatedly originates.
• Data minimisation. Data no longer retained cannot be published. Retention schedules are an underrated security control.

4. Decisions to make before the incident

The worst time to reason about these questions is during the event, under time pressure, with counsel joining a call for the first time.

• Who has authority to declare a major incident, and who can authorise taking systems offline?
• What is the organizational position on payment, and who decides — including the sanctions and legal review that decision requires?
• Which regulators, clients or contractual counterparties must be notified, within what deadlines?
• Which external parties are retained in advance — incident response, legal counsel, communications?
• How does the team communicate if the corporate messaging and email systems are unavailable or untrusted?
• Does the cyber insurance policy require a specific notification sequence or approved vendors?

Documenting these before an incident converts a crisis into a procedure. Most of the cost in a ransomware event accrues during the days spent deciding rather than acting.

5. Recovery takes longer than planned

Recovery expectations are routinely optimistic. Restoring data is one task; rebuilding domain trust, validating that the intrusion path is closed, reissuing credentials, and returning systems to service in dependency order is a different and longer one. Planning assumptions built on the technical restore time alone tend to be wrong by a wide margin.

It is worth establishing, in advance, which services the organization must run manually and for how long — because that, rather than the restore itself, usually determines the operational damage.

Plan for publication, not just encryption

The controls that answered the encryption scenario are still necessary. They are no longer sufficient. An organization confident it can restore quickly, but unable to say what data left the environment or who must be told, has planned for the version of this threat that is receding.

This article is general educational guidance, not legal advice, a certification, or a substitute for an organization-specific security assessment.