A ransomware crew announced this month that a household-name consumer brand had "no chance of recovering" without their encryption key. Production in the company's US facilities had already stopped. Two weeks later, most of it was running again. Nobody paid, and the crew was left grumbling that the victim reported the incident instead of following the instructions left on its network.
They were wrong about the recovery. For most companies, they would have been right.
Why do companies pay ransoms?
Companies pay because the math went against them, and the math closed long before the attack. Three variables decide it.
1. How long a real restore takes.
In Eon’s 2026 survey of 583 cloud IT leaders, 60% need six hours or more for a single full restore. Only 5% can finish one in under an hour. Now run that across a few hundred systems while revenue sits at zero. The ransom looks cheap fast.
Steve Stone, Chief Customer Officer at SentinelOne, put it bluntly on Cloud Cuts Live:
"I have never seen a full restore. I've never seen it once. It's always partial restores, and it's always sequential."
2. Whether the recovery layer survived.
Attackers go after backups on purpose, because backups are your leverage. Sophos found attempts to compromise backups in 94% of ransomware cases, and 57% of those attempts worked. A recovery copy that shares credentials, a management plane, or hardware with production is a second copy of the same target. Hyperconverged platforms make it worse: compute, storage, and backup images sit behind one management layer, and CISA updated a joint advisory in November 2025 after a major ransomware operation encrypted hypervisor disk files on one of those platforms for the first time.
3. Whether the data has already left.
Encryption is no longer the whole event. Stone's team almost never sees an encryption-only intrusion anymore. Theft and long-term access come standard, and in his experience, extortion over stolen data is why most ransoms have been paid in the last 18 months. Recovery brings your systems back. It can't unsteal a terabyte.
Teams set all three of those variables in architecture reviews and budget cycles. The ransom note reads your old decisions back to you.
Why are the most confident teams the most exposed?
90% of cloud IT leaders say they could recover from a cyberattack (Based on Eon’s survey data). At the executive level, 75% admit their teams rely on assumptions rather than verified testing.
Stone's incident-response teams see where that goes. Almost nobody stress-tests recovery live on the wire, so the first real test happens mid-intrusion, at the worst possible moment.
What does AI change?
Two things, and neither is the sci-fi version.
First, more crews clear the technical bar. Stone's framing on our show: AI raised the floor of attacker capability, not the ceiling. Nobody is watching AI invent attacks defenders have never seen. What changed is that capability once reserved for nation-state programs now belongs to anyone who can write a decent prompt. More attackers will reach your recovery layer, and they won't be the sophisticated ones.
Second, and stranger: AI can delete the ransom from the incident entirely. An AI coding agent with valid production credentials can drop a table or corrupt a schema in seconds. No dwell time, no note, no key to buy, nobody to negotiate with. The damage is ransomware-shaped, and the one variable you still control is whether you can recover, granularly and fast, from a copy the incident couldn't touch.
The ransom, it turns out, was always the optional part.
What does refusing a ransom actually require?
The bar isn't "we have backups." The bar is four questions you can answer under pressure, with evidence:
- Can an attacker reach your recovery copy with stolen production credentials? If backups sit in the same accounts, behind the same management plane, or on the same hardware as production, the honest answer is yes.
- How long does your biggest restore take, measured? A number from a real test on your largest workload counts. A number from a runbook doesn't.
- Is the copy you plan to restore clean? Stone puts typical dwell time at 5 to 7 days before encryption. Roll back 24 hours and you often restore the attacker along with the data. An immutable snapshot of an infected database is still infected.
- What did they take? Extortion leverage depends on what left the building. If you can't say what data lived in the affected systems, the attacker sets the price of your uncertainty.
Where Eon fits
We built Eon's recovery layer around those four questions. Backups land in an isolated, logically air-gapped vault in a separate account, beyond the reach of stolen production credentials. Ransomware detection reads the logical content of database backups, row counts, cardinality shifts, and schema changes, and separates clean recovery points from poisoned ones before you restore. Recovery is granular, down to the row and file, so you bring back the one table the incident touched rather than an entire estate. Classification runs continuously, so "what data lived there" has an answer before anyone demands money for it.
NETGEAR cut a 10TB SQL Server restore from 24 hours to under three on Eon. Based on the math above, that gap is often the distance between negotiating and refusing.
Edit the confession while you can
The brand in this month's headlines got to say no because of recovery choices the attackers couldn't undo in a week of dwell time. Every team faces the same choices. Most make them by default, in a budget line nobody reviews, and will learn what they picked mid-incident.
A ransom payment is a confession written in advance. The only time to edit it is before anyone asks you to sign.
Eon’s 2026 Cloud Data Infrastructure Report covers the recovery confidence gap in depth, across 583 cloud IT leaders.
