The Most Underrated Number in the 2025 Sophos Report
When Sophos published its 2025 State of Ransomware report, most coverage focused on the headline metrics: encryption rates falling, recovery times improving, ransom payments declining. Those numbers are real, and they matter. But buried in a section of the report explored for the first time this year — the organizational factors that left companies exposed — sits a single statistic that, in our view, reframes how enterprise risk leaders should think about ransomware entirely.
Across the 3,400 organizations surveyed, victims identified an average of 2.7 different contributing factors behind the attacks that succeeded against them.
Not one. Not even two. Almost three independent weaknesses operating simultaneously in every successful incident.
This is not a footnote. It is the mathematical proof that the era of single-control ransomware defense is over — and that backup architecture has quietly become the most important compensating control in the modern enterprise stack.
At BackupSec, we believe the 2.7 figure is the most strategically useful number in the entire report. This article unpacks what it actually means, why it makes prevention-only strategies mathematically untenable, and what it implies for organizations still treating backup as an afterthought to "real" security.
What the 2.7 Actually Represents
In the 2025 Sophos report, for the first time, respondents were asked to identify the organizational factors that contributed to their being hit — not just the technical entry point, but the broader operational conditions that left them vulnerable. The findings paint a picture that no executive summary captures cleanly:
- 40.2% cited lack of expertise — insufficient skills or knowledge to detect and stop the attack in time.
- 40.1% cited unknown security gaps — weaknesses in defenses they were unaware of until the incident.
- Significant percentages cited lack of capacity, lack of protection products, gaps in process discipline, and incomplete visibility into their own attack surface.
- Technical root causes layered on top: exploited vulnerabilities (32%), compromised credentials (23%), malicious email (19%), and phishing (18%).
When respondents tallied the factors they believed contributed to their incident, the average came to 2.7. Sophos calls this "a complex, multi-faceted situation." We would call it something more precise: structural inevitability.
If every successful ransomware incident in 2025 involved nearly three independent failures, then the implicit defense model that most enterprises are still operating against — "find the gap, close the gap" — is operating against an attacker who only needs to find one of the three. Meanwhile, the defender has to manage all of them simultaneously.
That is not a security problem. That is an asymmetry problem.
The Asymmetry: One Door Versus Seven
Consider the math from the attacker's perspective.
A modern ransomware operator — whether a state-aligned group, a RaaS affiliate, or an independent operator — does not need to identify and exploit every weakness in your environment. They need to find a single viable path: one unpatched system, one set of compromised credentials, one misconfigured cloud bucket, one phishing-susceptible user, one administrative gap.
Now consider the math from the defender's perspective. You are responsible for:
- Vulnerability management across thousands of assets, in cycles that no patching cadence reliably keeps ahead of.
- Identity governance across human users, service accounts, federated identities, and increasingly autonomous agents.
- Email and collaboration security, the most common entry point and the one with the most human variability.
- Endpoint protection against payloads that evolve faster than signature-based detection can adapt.
- Network segmentation designed against threat models that change continuously.
- Cloud and SaaS configuration across dozens or hundreds of services, each with its own permission model.
- Backup and recovery infrastructure that must work under conditions that the rest of your stack has already failed to prevent.
The attacker plays one cell on this board. The defender plays all seven, every day, with finite resources.
The 2.7 number from Sophos is the empirical confirmation that this asymmetry is no longer hypothetical. In the real incidents that occurred in 2025, defenders were failing in nearly three cells simultaneously — not because they were negligent, but because the model is structurally rigged against complete prevention.
Why "Just Fix the Root Cause" Is Bad Math
A common response to incident analysis is to identify the "root cause" and remediate it. Compliance frameworks reinforce this thinking. So do most post-incident reviews. The 2025 Sophos data exposes why this framing, while intuitively satisfying, is increasingly disconnected from how modern incidents actually unfold.
If the average successful incident involves 2.7 contributing factors, then identifying a single root cause is, by definition, an incomplete analysis. It tells you which door the attacker walked through — not why the building had so many unlocked doors that one of them was always going to be available.
This matters operationally because the resources spent obsessing over the specific entry vector of last year's incident are resources not spent on the architectural gaps that will determine next year's. The Sophos data implies that organizations operating in single-root-cause mode are systematically under-investing in the layered controls that determine whether any entry vector leads to a catastrophic outcome.
The strategic reframing is this: for any sufficiently complex enterprise environment, attackers will eventually find a viable path. The question that determines whether that path leads to a paid ransom is not "did we close every door?" but "does our architecture survive once one of them opens?"
The Compensating Control Most Enterprises Underestimate
Here is the architectural insight that the 2.7 figure makes inescapable: when prevention will fail with mathematical regularity, the layers that determine business outcomes shift downstream.
This is where backup architecture moves from "infrastructure hygiene" to "primary strategic control."
In a single-vector threat model, backup is a fallback. In a 2.7-factor threat model, backup is the compensating control for every prevention failure that will inevitably occur. The 2025 Sophos data shows this in stark terms:
- 48% of enterprise organizations paid the ransom despite improvements in prevention.
- Backup usage to recover encrypted data dropped to a four-year low of 53%, down from 73% the previous year.
- The average enterprise recovery cost reached $1.83 million for organizations with 1,000–5,000 employees — and that figure excludes any ransom paid.
When you read those numbers against the 2.7-factor backdrop, the story becomes coherent: organizations are getting better at preventing some attacks but are not improving the recovery architecture that determines outcomes when prevention fails. The result is a widening gap between prevention maturity and recovery maturity — and that gap is exactly where ransom payments live.
For enterprise risk leaders, this implies a specific reallocation of architectural attention. Investments in detection, identity, and patching all remain essential. But none of them eliminate the 2.7. They merely shift which three doors are open on a given day. The control that determines whether an opened door becomes an existential incident is the one most organizations have under-modernized: the architecture that holds clean, immutable, validated copies of business-critical data and can restore them under adversarial conditions.
What 2.7 Looks Like in an Actual Incident
To make this concrete, consider how the 2.7 typically composes in a real enterprise environment. The specific factors vary, but the pattern is consistent:
Factor one is usually an entry vector: an unpatched edge device, a compromised credential reused across systems, or a successful phishing email. This is the failure that the post-incident report will call the "root cause."
Factor two is typically a privilege or visibility failure that allowed the initial foothold to expand: excessive standing permissions, gaps in lateral movement detection, or inadequate segmentation between business units.
Factor three is almost always a recovery-layer failure that turned a contained breach into a paid ransom: backup credentials reachable from production, retention policies modifiable by compromised admins, or restore procedures that have never been tested against the actual scenario the team now faces.
The first two factors get the attention in incident response. The third determines the financial outcome. And the third is the one most enterprises are least equipped to evaluate honestly before an incident forces the question.
This is the operational reality the 2.7 figure points at. The factors are not abstract — they are the specific sequence of failures that turn a manageable security event into a board-level crisis.
What This Means for Risk Allocation
If you accept the 2.7 finding as architecturally meaningful — and the underlying Sophos dataset of 3,400 organizations makes it hard to dismiss — several allocation conclusions follow.
Diversify investment across the failure chain, not within a single layer. Doubling down on email security while leaving recovery architecture unchanged shifts which factor fails first; it does not reduce the total number of failures. Enterprise security budgets that allocate disproportionately to prevention while treating backup as a commodity line item are operating against a threat model that no longer reflects how incidents actually unfold.
Evaluate architectures against multi-factor scenarios, not single-vector tests. A penetration test that confirms one defense holds is not evidence that your environment survives a real attack. The Sophos data shows that real attacks exploit nearly three weaknesses simultaneously. Tabletop exercises and red-team engagements should be designed to test that compound condition explicitly.
Measure recovery confidence, not backup completion. The 53% backup-usage rate in the Sophos enterprise data is not a story about backups failing in general. It is a story about backup architectures designed for single-factor failures (a server died, a user deleted a file) being asked to perform under multi-factor conditions (the attacker has been in the network for two weeks and has touched everything). Those are different problems, and most enterprise backup environments were built for the first.
Treat the recovery layer as the compensating control it has become. When prevention will fail by mathematical regularity, the layer that determines outcomes is the one that holds clean, isolated, immutable copies of data and can restore them at speed under hostile conditions. That layer must be architected, governed, and tested with the same rigor as the production environment it protects.
Where BackupSec Comes In
At BackupSec, our entire approach is built around a single architectural premise: prevention will eventually fail, and when it does, the recovery layer is what determines whether the failure is recoverable or existential.
The 2.7 finding from the Sophos data is, in many ways, the empirical justification for that premise. The three services we deliver — observability, advisory, and pentested recovery proof — are designed to answer the questions the 2.7 figure forces enterprise risk leaders to confront:
- ZeroMON answers "What is our backup environment actually doing right now?" — through continuous monitoring of backup operations and security signals, real-time forensic audit trails, configuration drift detection, and Veeam-ready visibility across the entire backup estate.
- ZeroTAM answers "Do we have the expertise to interpret what we are seeing?" — through a dedicated backup security advisor who knows your environment, your recovery priorities, and your architecture, available for proactive guidance and crisis response without the friction of rotating support tickets.
- ZeroPEN answers "Can we actually recover when the prevention layer fails?" — through backup penetration testing that targets your management planes, access controls, and immutability posture, followed by real restore scenarios that validate clean, complete, on-time recovery against your stated RTO and RPO.
BackupSec is deployed on-premise, connects through read-only API access, and never moves backup data or telemetry outside your environment. We do not replace your backup platform — we make the recovery layer that platform supports observable, advisable, and provable under the multi-factor conditions the Sophos data describes.
If your organization is reading the Sophos 2025 report and concluding that the answer is to close every door, the data is telling you something else: the doors will not all stay closed, and the architecture that determines what happens when one of them opens is the conversation worth having in 2026.
Talk to BackupSec about recovery validation →
This analysis draws on the Sophos State of Ransomware 2025 report and the broader 2025 ransomware research landscape. The interpretation and framework presented here are BackupSec's own. To discuss how this analysis applies to your specific environment, get in touch with our team →