Few areas of IT see as much consensus as cybersecurity. While infrastructure teams may debate deployment models, and network teams topographies, cybersecurity conversations tend to converge quickly. Ask ten practitioners how to reduce access risk and you will hear the same answer: Zero Trust. Ask how to prepare for ransomware, and best practices such as segmentation, least privilege, regular testing, and backup immutability will undoubtedly be stated. And yet, for all this agreement, execution tells a very different story.
To recognise and understand this disconnect, it’s helpful to zero in on backup immutability. It’s a concept that’s been discussed, recommended, and widely endorsed since the late 2010s. In theory, it is one of the clearest and most effective safeguards against ransomware as it ensures that at least one copy of data cannot be altered or deleted, even by an attacker with elevated access. And yet, despite everyone agreeing on the value of immutability, why is so little data actually protected by it? And more importantly, what does that tell us about cybersecurity more broadly?
Adoption vs. coverage: The reality check
The answer begins with a reality check. On the surface, adoption appears strong. Industry surveys suggest that 59% of organisations report having immutable backups, while 94% say they either use or plan to use immutable storage within a year. At the same time, 72% report using air-gapped backups. Awareness is clearly not the issue.
But when we look beyond presence and into actual coverage, a different picture emerges. Acronis telemetry shows that while approximately 170,000 customer tenants actively use immutable storage, protecting around 49 petabytes of data, this represents just 1.4% of the total 3,600 petabyte backup footprint. In other words, immutability exists in many environments, but only protects a small fraction of the overall data estate.
This distinction matters. The industry tends to measure adoption in terms of presence — whether a capability exists somewhere within the environment. But resilience is determined by coverage. When attacks happen, what really counts is how much of the data that truly matters is protected. The gap between the two is where risk lives.
The real barrier: Operability, not technology
It would be easy to assume this is a technology problem. It is not. The capability is mature and widely available. Modern backup platforms support immutability through tenant-level settings and storage-layer controls such as object lock and WORM policies. Importantly, telemetry shows no meaningful performance difference between immutable and non-immutable backups in terms of success rates, duration, or retry behaviour.
The barriers are far more practical. Storage planning is one of the most immediate challenges. Once immutability is enabled, data cannot be deleted before its retention period expires. For teams already managing growing backup volumes (where data churn increased by approximately 35% in the second half of 2025 alone) this introduces understandable caution.
The issue is compounded by cost anxiety. The way backups are designed has a direct impact on storage consumption. For example, protecting a 1TB Microsoft Exchange workload using full image backups can generate up to 24.76TB of archive data over 30 days. At an estimated storage cost of $0.025 per gigabyte, that translates to roughly $619 per month. By contrast, an application-aware backup of the same workload may produce just 380GB over the same period, costing under $10. The security control is the same but it’s the design choice which determines whether it feels sustainable.
Uncertainty around retention policies, combined with the reality that IT teams must prioritise immediate operational issues, further slows adoption. In practice, immutability often becomes something that is configured, tested, and then deferred to the long list of “important but not urgent” tasks.
A design problem disguised as a security gap
This points to a broader truth. Cybersecurity does not fail because organisations lack knowledge. It fails because what we should do does not always align with how systems are designed, budgeted, and operated.
In that sense, immutability reveals a deeper issue. Security is often treated as a feature to be added, rather than a design principle to be embedded. Controls are layered onto environments that were not built to support them efficiently at scale. When those controls introduce friction whether in cost, complexity, or operational overhead, they are applied selectively, inconsistently, or not at all. The result is a gap between the preferred and the possible.
From designing for perfection to designing for practice
Part of the challenge is that best practices themselves can be overly idealistic. They present a clear, linear path to security maturity, but real-world environments are rarely linear. Teams encounter constraints related ot budgets, legacy systems, and competing priorities. When perfection proves unattainable, progress often stalls entirely. This is why the conversation needs to shift from designing for perfection to designing for practice.
In the context of immutability, that means moving away from the idea of “immutability everywhere” as an immediate goal. Instead, organisations should focus on a more pragmatic standard: ensuring that every critical workload has at least one recent, tested, immutable recovery path that can survive a ransomware attack or administrative compromise.
A selective approach also aligns more naturally with operational realities. By prioritising critical systems, optimising backup methods, and planning retention carefully, organisations can introduce immutability without triggering unsustainable storage growth or cost pressure. From there, coverage can expand over time as confidence and capacity increase.
Closing the gap between strategy and reality
This mindset of starting with what is practical, then scaling deliberately is not unique to backups. It reflects a broader pattern across cybersecurity. Zero Trust architectures are often defined comprehensively but implemented incrementally. Patch management policies are well understood but inconsistently applied. Identity environments continue to grow in complexity, even as organisations strive to simplify access control.
Until systems are designed with operational realities of cost, scale, and human behaviour in mind, we will continue to see the same pattern of strong consensus, but uneven outcomes. Immutability, in this sense, is more than a backup feature. It is a litmus test for how well cybersecurity strategies translate into real-world resilience. Because ultimately, resilience is not defined by the controls we claim to have. It is defined by the ones that remain intact when everything else fails.
Discussion about this post