When ransomware hits, the question “Should we pay a ransom?” lands fast and without ceremony.
It rarely lands with clarity.
In a recent live incident teardown with CloudGuard, we walked through a scenario that mirrors what many UK organisations face.
A mid-sized manufacturer. Strong turnover. Orders mid-cycle. A lean IT function already under pressure.
On a Sunday morning, the CEO receives a message confirming the network has been compromised and encrypted.
By 8:30am, the board is modelling the numbers.
- The demand is £500,000, potentially negotiable to £250,000.
- Downtime is costing approximately £225,000 per day.
- Without payment, recovery is estimated at ten days.
- With successful decryption, operations might resume in three.
At that moment, paying a ransom feels commercially arguable to most organisations. And that’s where most serious discussions begin.
The Financial Case to Pay
Boards are not emotional in the first instance, they are comparative.
In our example scenario, all production is affected and orders in progress are delayed. The business is losing approximately £225,000 per day in operational impact. Without payment, recovery is estimated at ten days.
That places the immediate disruption cost at roughly £2.75 million when downtime, rebuild (£225,000), recovery effort (£250,000) and working capital exposure are factored in.
Insurance provides £1 million in cover, but only £250,000 applies to business disruption. The remaining exposure sits with the company.
Now compare that with the payment scenario.
The £500,000 ransom is negotiated down by 50%, bringing the payment to £250,000. With “successful” decryption, operations resume in three days rather than ten. That seven-day difference represents approximately £1.575 million in avoided downtime.
Even after factoring in rebuild and recovery costs of £225,000, the total estimated cost to the business falls to approximately £1.8 million.
From a purely financial modelling perspective, the difference between paying and not paying appears to be nearly £1 million.
This is why, in the room, payment initially feels commercially defensible.
And that distinction matters in a board-level discussion.
Pay vs. No-Pay: Cost Comparison at a Glance
| Cost Item | Pay the Ransom | Do Not Pay |
|---|---|---|
| Ransom payment | £250,000 (negotiated) | £0 |
| Downtime (3 vs 10 days) | £675,000 | £2,250,000 |
| Rebuild & recovery | £225,000 | £225,000 |
| Working capital exposure | £250,000 (est.) | £250,000 |
| Insurance offset | − £1,000,000 | − £1,000,000 |
| Total estimated cost | ~£1.8 million | ~£2.75 million |
Based on the Codestone/CloudGuard incident teardown scenario. Figures are illustrative and based on real-world incident patterns.
The numbers appear compelling. But as the investigation deepened, that initial calculation began to unravel.
What Changes Once the Investigation Deepens
“Most incident response plans stop at containment. They don’t prepare you for the decision-making pressure that follows.”
— Matt Lovell, CloudGuard, CEO
The investigation quickly revealed that this wasn’t a weekend incident at all.
- Access had been established weeks earlier through a compromised MFA session.
- A critical SAP vulnerability had also been exploited, and firewall logs confirmed that data had already been exfiltrated.
- During the attack window, several security controls had been disabled, allowing the intrusion to progress undetected.
If data has already left the environment, paying a ransom does not retrieve it.
If persistence mechanisms remain, paying does not remove them. If systemic vulnerabilities exist, payment does not close them. In fact, less than half of ransomware victims get all of their data back.
“Ransoms do not guarantee any certainty, recovery or decryption. They don’t prevent any data leakage or even future data attacks. The likelihood of them coming back is very high.”
— Javid Khan, CloudGuard, Chief Technology Officer
The technical reality reinforced that warning. A decryption key was obtained and tested, and it failed. At that point, the board could no longer assume that payment would deliver a clean or predictable recovery.
At that stage, the board realises something — regardless of payment, the environment must be rebuilt.
The ransom is no longer a substitute for remediation. It becomes an additional cost layered on top of it.
MGM Resorts: A Case Study
The experience of MGM Resorts in September 2023 illustrates this clearly. After detecting a ransomware attack linked to the Scattered Spider group using ALPHV ransomware, MGM chose not to pay.
Despite that decision, the company was forced to shut down core systems, terminate compromised Okta infrastructure, rebuild its Azure environment and restore services over a ten-day outage. The financial impact was estimated at $100 million in lost earnings, with a further $10 million in remediation, legal and advisory costs.
The rebuild was unavoidable. Once attackers achieve persistence and exfiltrate data, the technical reset becomes mandatory.
This pattern is consistent with broader industry data. The IBM Cost of a Data Breach Report consistently finds that organisations with mature incident response capabilities reduce their overall breach costs by an average of $2.66 million — reinforcing that preparation, not negotiation, determines financial outcomes.
The Operational Reality After Payment
One of the most valuable insights shared in our Incident Response Teardown was a simple operational rule: multiply your estimated recovery time by 42 to understand the broader business impact.
If systems return in three days, that does not mean the business returns to normal on day four. It can mean months of elevated monitoring, customer reassurance, forensic review, remediation projects and staff fatigue.
Paying a ransom does not remove that broader operational impact. It may reduce the immediate downtime caused by encryption, but it does not eliminate the extended strain on teams, systems and leadership focus.
There is also the question of repeat targeting. Organisations that choose to pay are 1.8x–4x more likely to be attacked again. In practical terms, payment signals both financial capacity and a willingness to negotiate — factors that matter in criminal marketplaces.
On top of this, only around 22% of organisations fully implement all recommended post-incident improvements. For the majority, known gaps remain.
Those unresolved weaknesses often become the entry points for the next incident. Research from Cybereason supports this, finding that reinfection is a significant and underappreciated risk for organisations that pay.
The UK Legal and Regulatory Context
In the UK, the decision to pay a ransom carries additional layers.
Paying a ransom isn’t automatically illegal, but making funds available when you know or have reasonable cause to suspect they will benefit a terrorist organisation could constitute an offence under the Terrorism Act 2000.
Regulatory scrutiny is tightening. Insurers increasingly require evidence that baseline security standards were met before supporting ransom payments.
Under the NIS Regulations 2018, operators of essential services face additional reporting obligations and regulatory scrutiny following significant cyber incidents. The UK government has also signalled that mandatory reporting of ransomware payments may be introduced in future legislation.
Organisations should use the government’s Where to Report a Cyber Incident portal to determine which authorities to notify. For most ransomware attacks:
- Action Fraud is the primary reporting centre for cybercrime and ransomware extortion.
- NCSC offers technical triaging, guidance, and can coordinate support across government.
- If personal data has been compromised, you must report to the ICO within 72 hours under UK GDPR rules. Codestone’s Data Privacy & Governance service can support you with post-incident compliance obligations.
Reporting helps authorities understand the threat, support your response and in some cases may help mitigate regulatory outcomes. It also contributes to national cyber threat intelligence that helps protect other UK organisations.
So, Should You Pay a Ransom?
There is no universal answer that applies to every sector, particularly where life safety or critical national infrastructure is involved.
For most commercial UK organisations, however, the evidence suggests that paying:
- Does not guarantee full recovery
- Does not prevent data leakage or resale
- Does not remove the need for rebuild
- Increases the likelihood of future targeting
- May carry legal and regulatory risk — particularly if funds reach sanctioned individuals or organisations
However, if you do decide to pay, take these into consideration:
- Always use an experienced negotiator. Before making any payment, take expert advice.
- Transactions are not always instant.
- Payment will likely come with terms and conditions, and they won’t be yours.
- Payment guarantees nothing.
- Always record all details and ensure the relevant authorities are updated.
- Do not expect a return to ‘business as usual’.
- Immediately review your cyber posture and configuration.
The strongest strategy is reducing recovery time and improving early detection so that paying a ransom never becomes the least-worst option.
To build that resilience, the NCSC’s 10 Steps to Cyber Security and the Cyber Essentials scheme provide a solid baseline framework for UK organisations.
Our CyberCare managed security service and Cyber Security Workshop are built around helping businesses reach and exceed that baseline before an incident occurs.
Because once criminals set the price, you are negotiating from a position defined by your preparedness.
And preparedness, not negotiation, is what ultimately determines the outcome.
Before the Ransom Note Arrives
To reduce the likelihood of ever debating a ransom payment, start by understanding what attackers can already see.
Our free External Exposure Analysis with CloudGuard shows you exactly that — open ports, unpatched systems, exposed credentials, and misconfigured services that represent your current attack surface.
