What is Ransomware? Ransomware is malicious software that encrypts an organisation’s systems and data, with attackers demanding payment for the decryption keys, and often threatening to leak stolen data if the ransom isn’t paid.
It has become a significant driver of investment in disaster recovery services, and for good reason. According to the DSIT Cyber Security Breaches Survey 2025, the estimated percentage of UK businesses experiencing a ransomware crime increased significantly, from less than 0.5% in 2024 to 1% in 2025. This may sound small, but it equates to around 19,000 more businesses falling victim in a single year.
The National Cyber Security Centre also continues to identify ransomware as one of the most significant cyber threats facing UK organisations.
Yet, the frequency of attacks is only half the story. What has fundamentally changed is how ransomware attacks work and, specifically, what they target. Understanding that change is essential to designing a recovery strategy that helps you recover when needed.
A decade ago, most ransomware was opportunistic. An infected attachment encrypted whatever it could reach, and an organisation with reasonable backups could usually restore its data and move on. That model no longer reflects how capable threat actors operate.
Modern ransomware attacks are now generally more targeted, more patient, and designed to undermine recovery capabilities before the encryption event is ever triggered. Attackers will usually spend time inside an environment, mapping it, escalating privileges, and locating the systems that would allow the business to recover without paying.
In 2023, according to Veeam research, 93% of cyber attacks targeted backup repositories, with attackers deleting or encrypting restore points to remove the victim’s alternatives to payment.
The commercial logic for this is straightforward; an organisation with intact, isolated, recoverable backups has a strong negotiating position. An organisation whose recovery capability has already been destroyed is often left with none. This is why, in many incidents, the recovery infrastructure is the primary target, and the encryption is the final step.
The consequence is that many businesses discover their recovery gaps at the worst possible moment, typically during a live incident when the ability to recover has already been compromised.
Partially, and that qualification matters. Backups protect your data if they survive the attack and can be restored cleanly. Neither of those conditions can be assumed in a modern ransomware disaster recovery scenario.
Backups may not survive because attackers actively seek out repositories that are visible from the production network, reachable with production credentials, or lacking immutable protection.
There is also the question of which restore point you can trust. As covered above, attackers rarely encrypt on day one, and before an attack becomes visible, threat actors typically spend days inside the environment escalating privileges and establishing persistence. Mandiant's M-Trends research puts the median dwell time for ransomware-related intrusions at six days, rising to 29 days where the intrusion was discovered internally rather than announced by the attackers themselves.
This creates a difficult trade-off at the point of recovery. Restore points created during the dwell period may contain the attacker's persistence mechanisms, compromised credentials, or corrupted data, so restoring your most recent backup risks restoring the compromise alongside it.
Rolling back to a point before the intrusion means asking a harder commercial question - can the business afford to lose a week or more of transactions, documents, and customer records? For many organisations, the honest answer is no - and that answer often isn't discovered until they're mid-incident.
The implications for backup strategy are twofold: retention must extend well beyond typical dwell times, so a known-clean restore point actually exists, and restore points must be validated in an isolated environment before reintroduction to production - not assumed clean because they predate the encryption event.
Even where restore points survive, restoring them is not the same as recovering the business. Infrastructure, applications, identity, and networking all need to be brought back in the right sequence into an environment you can trust.
Backups are necessary but not sufficient. Ransomware protection at the recovery layer requires backups that cannot be destroyed, an environment that cannot be contaminated, and a recovery process that has been proven to work.
Most recovery strategies that fail under ransomware conditions don’t fail because the technology was faulty. They fail because the architecture around it was designed for accidental loss, hardware failure, human error and corruption, rather than for an intelligent adversary deliberately attacking the recovery capability itself.
Common structural weaknesses can include:Recovery environments sharing production credentials: if the same administrative accounts control both production and recovery, a compromised credential compromises both. The attacker who encrypts your production estate can delete your recovery estate with the same login.
Flat network architecture: without segmentation, attackers can move laterally from an initial foothold to backup infrastructure, identity platforms, and management systems before deploying the ransomware payload.
Backup infrastructure visible to attackers: repositories that are discoverable and reachable from the production network are on the attacker’s target list from the moment they gain access.
No clean recovery zone: without an isolated environment to restore into, organisations face an uncomfortable choice - restore into potentially compromised infrastructure, or delay recovery while the production environment is investigated and rebuilt.
No validated recovery testing: restore points that have never been tested may be corrupted, incomplete, or slower to restore than the business can tolerate, and this is only discovered when it’s too late to fix.
Overconfidence in retention policies: long retention means little if every restore point within it can be deleted or encrypted by an attacker with administrative access.
Each of these weaknesses is often invisible in day-to-day operations. Backups complete successfully, dashboards stay green, and the organisation reasonably believes it is protected. Ransomware is what exposes the difference between backup success and actual recoverability.
What is immutable storage? Immutable storage holds data in a way that is designed so it cannot be altered, deleted, or encrypted after it has been written - for a defined retention period, by anyone, including administrators. An immutable backup is therefore a restore point designed to survive even if an attacker gains full administrative access to your backup infrastructure. Note that immutability doesn’t only apply to secondary copies; primary backups can also be written to immutable storage. Immutability protects the integrity of restore points, and isolation protects the environment you recover into.
Both are needed, and together they address the two ways in which ransomware defeats recovery:Isolated failover environments: recovery infrastructure that is logically or physically separated from production (air-gapped) so that lateral movement from a compromised production network cannot reach it.
No inherited credentials: the recovery environment operates its own administrative accounts and access paths, stored securely outside the systems an incident might affect. Compromised production credentials carry no authority in the recovery environment.
Segregated compute resources: workloads are restored onto infrastructure that shares nothing with the potentially compromised estate - no shared hypervisors, no shared management plane.
Controlled reintroduction to production: recovered workloads are validated as clean before being reconnected, preventing reinfection from restore points that captured dormant malware.
Isolation and immutability protect your recovery capability, but only validation proves it works. In a ransomware scenario, for DCS, that validation takes a specific form with clean room recovery, where workloads are restored into an isolated sandbox environment, separated from both production and primary backup infrastructure, and verified before anything returns to service. This is the approach behind our CloudCover Recover service.
Effective validation under ransomware conditions typically covers:
How often this validation should happen depends on your risk profile and how quickly your environment changes, our blog on how often you should test your disaster recovery strategy covers this in detail. For organisations with meaningful ransomware exposure, the answer is rarely “annually.”
Across recovery tests and live incidents, the same gaps recur. Use this list as a quick self-assessment - each item you can’t confidently answer represents a dependency an attacker can exploit:
Shared administrative credentials between production and backup or recovery infrastructure
No immutable retention protecting restore points from deletion or encryption
Backup network is not segmented from the production estate
No documented recovery runbooks, or runbooks that haven’t been updated as the environment has changed
No recovery validation history - restores have never been tested end-to-end
No defined escalation path for a live incident, internally or with a provider
None of these gaps are unusual, and none are a criticism of the teams involved. They are the natural result of recovery architectures designed before ransomware made the recovery layer itself the target. The important thing is to close them before an attacker finds them first, whether through internal investment or managed backup solutions that build immutability, segregated credentials, and validated restores as standard.
Everything in this guide is built on three foundations. If your recovery strategy delivers all three, you are in a strong position. If any are missing, that is where to focus next.
1. Data integrity: immutable storage protecting recovery points, designed so restore data survives even a full administrative compromise.
3. Validated recovery execution: tested, documented, and measurable recovery processes, so recoverability is evidenced rather than assumed.
At DCS, as a UK-based, engineer-led cloud and cyber resilience provider, we build recovery environments that are secure by design - immutable, isolated, and validated against defined recovery targets. Our engineering team provides the escalation support that matters most during a live incident.
If you’re unsure whether your current recovery capability would withstand a modern ransomware attack, the most effective next step is a structured ransomware-readiness review with one of our engineers. Contact us today.