loader
Newsroom
Cybersecurity

The Ransomware Payment Decision

Whether to pay is decided under time pressure with bad information. Understanding what actually drives the decision is work that has to happen beforehand.

This is an analysis of the factors organisations weigh. It is not legal advice. Payment can carry sanctions and regulatory exposure that varies by jurisdiction and by who the recipient turns out to be — involve legal counsel and, where relevant, law enforcement before any decision.

The decision is made badly because it is made late

Almost every organisation facing this decides it for the first time while systems are down, information is incomplete, and people who have not slept are being asked to authorise something irreversible.

The single most useful intervention is to have discussed it in advance: who decides, on what basis, who must be consulted, and what would have to be true for each answer. That conversation costs an hour when calm and is close to impossible to have well during an incident.

Note that deciding in advance does not mean committing in advance. A blanket "we will never pay" adopted without examining recovery capability is a position rather than a plan, and organisations holding it have paid anyway when they discovered their backups were encrypted too.

What payment actually buys

Not recovery. It buys a decryption tool, and the distinction matters enormously.

Decryption after a large incident is slow, partial and error-prone. Tools supplied by operators are frequently poorly engineered, run at disappointing speed, and fail on some proportion of files. Restoring from good backups is often faster than decrypting, which is why the question "do we pay" should always follow "how long does recovery take" rather than precede it.

Where data was stolen as well as encrypted, payment buys a promise of deletion. There is no mechanism to verify that promise, the data has typically been copied more than once, and organisations have seen stolen data published after paying. The value of that promise should be assessed accordingly.

What actually drives the decision

Recovery capability. The dominant factor. If clean, isolated backups exist and a restore has been tested, payment is usually unnecessary. If backups were reachable with the credentials the attacker held, the decision changes entirely. This is determined by architecture decided long ago.

What was taken. An encryption-only event is an availability problem. Data theft makes it a disclosure event with notification duties that payment does not remove — regulators are not a party to the transaction, and obligations attach to the breach rather than to whether the operator publishes.

Time. What does an additional week of downtime cost, and can the organisation survive it? For some businesses the answer makes the decision; for others it makes it irrelevant.

Legality. Payment may be prohibited or may create liability depending on jurisdiction and on who the recipient is, which is frequently unknown at the moment of decision. This is why counsel is not optional.

Insurance. Policy terms may cover payment, require prior consent, or exclude it. Discovering these terms during an incident is common and avoidable.

What follows either way

The parts that are identical regardless of the decision are the parts most likely to be neglected.

The intrusion has to be investigated and the entry point closed. Restoring or decrypting into an environment the attacker still holds access to leads directly to a second event, and repeat incidents against the same victim are well documented.

Credentials have to be rotated comprehensively, on the assumption the directory was compromised. Notification obligations have to be assessed on the facts rather than on the outcome of a negotiation. And recovery has to be sequenced so that the systems everything else depends on come back first — which is a plan best written before it is needed.

The preparation that changes the answer

Everything that improves this decision is done beforehand, and none of it is exotic.

Backups that are immutable or offline, held in a separate trust domain, and restored as a test rather than assumed. Segmentation so one compromise is not total. Identity separation so backup administration is not reachable from production. A recovery runbook that assumes a hostile network and an untrustworthy directory. Logging shipped off-host in real time, so scoping is possible when local logs are gone.

Organisations that have done these things face a bounded operational problem. Organisations that have not face a negotiation — and the terms of that negotiation were set months earlier, by decisions that had nothing to do with ransomware at the time.