Organisations should prioritise refusing ransom demands when they have credible recovery options, tested backups, and a restoration plan that can meet business needs. The article suggests more defenders are willing to say no, which changes attacker calculations. Negotiation becomes weaker when recovery is faster and leadership can tolerate operational disruption during restoration.
Why refusal becomes stronger when recovery is real
The practical threshold is not whether ransom is painful, it is whether the organisation can restore service without paying. When recovery is credible, the attacker loses leverage because disruption is no longer the only path back to operations. That makes refusal more defensible, especially when leadership has already accepted the short-term operational pain of restoration.
Fast recovery also changes negotiation dynamics. If the business can reconstitute data and services from known-good backups, the ransom demand stops being a bridge to continuity and becomes a pure transfer to the attacker.
What conditions make negotiation the weaker option?
Negotiation is usually weaker when backup integrity, restoration timing, and containment all point in the same direction, namely that the organisation can recover on its own terms. In that situation, paying only increases the chance of funding repeated extortion without materially improving recovery. It also creates a false signal that the organisation will buy its way out of future pressure.
Refusal is especially rational when the demanded amount exceeds the cost of restoration, when systems can be rebuilt in a controlled sequence, and when there is enough evidence that the attacker cannot block recovery from offline or otherwise protected copies.
How executives should decide before opening a channel to attackers
The decision should be made against operational reality, not against fear of prolonged outage. If restoration has been tested, dependencies are understood, and critical services can be brought back within acceptable business tolerances, the organisation should treat refusal as the default position. If those conditions are missing, the organisation is not choosing between payment and no payment, it is choosing between uncertain delay and a harder recovery path.
That is why the response must be owned jointly by incident response, business continuity, legal, and leadership. The key judgement is whether negotiation would buy time that recovery cannot already provide.
Risk and Threat Considerations
Ransomware actors rely on time pressure, uncertainty, and the belief that payment is the fastest route to normal operations. When backups are weak, untested, or too slow to restore, the organisation is more exposed to double extortion, repeated pressure, and operational paralysis. A credible restore path removes much of that leverage.
Failure mechanism: The attacker succeeds when defenders overestimate their recovery capability, discover backup gaps too late, or lack a rehearsed restoration sequence for critical systems.
Impact: Paying under those conditions can still leave the organisation with slow recovery, repeat targeting, and no guarantee that stolen data will not be used again.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-11 — Data Recovery | Recovery readiness determines whether ransom leverage exists. |
| Recommendation — Test restore capability and recovery time before deciding whether to refuse ransom demands. | ||
| NIST CSF 2.0 | RC.RP-01 — Recovery Plan is Executed | The question turns on whether recovery can replace paying the attacker. |
| RC.RP-02 — Recovered Assets are Restored and Reconstituted | Refusal is strongest when assets can be restored to trusted state. | |
| Recommendation — Execute and validate the recovery plan to reduce dependence on attacker cooperation. Restore trusted systems and data before considering any ransom negotiation. | ||
| ISO/IEC 27001:2022 | A.5.30 — ICT readiness for business continuity | Business continuity readiness underpins the decision to refuse ransom. |
| A.8.13 — Information backup | Backups are the core control that makes refusal viable. | |
| Recommendation — Align recovery capability with business continuity requirements before ruling out payment. Maintain and test backups so recovery remains feasible without paying attackers. | ||
Practitioner Guidance
What to prioritise: Decide the pay-versus-refuse posture before a crisis by validating that backups are usable, isolated, and fast enough to meet business recovery objectives. If restoration has not been rehearsed, the organisation should not assume it can confidently refuse.
What to verify: Confirm that the latest restore point is clean, that critical dependencies can be rebuilt in order, and that the business can tolerate the outage window implied by refusal. A backup that exists but cannot be restored on time does not change the negotiation calculus.
Practitioner takeaway: Organisations should refuse when recovery is genuinely executable, because the strongest defence against extortion is not a better negotiation, it is a restoration capability the attacker cannot meaningfully disrupt.