Ransomware is no longer a distant or occasional threat. Today, it is part of the operational risk of any organisation, regardless of its size or sector. As a result, ransomware and backups have become inseparable topics: increasingly sophisticated attacks target not only production systems but also the backups themselves, in a clear attempt to eliminate any chance of recovery without paying a ransom.
In this scenario, backups play a critical role. However, experience shows that many companies, despite having backup copies, fail when the time comes to recover. The reason is simple: not all backups are prepared to withstand a ransomware attack.
Why ransomware has changed the way we think about backups
Traditionally, companies saw backups as a solution for technical failures or human error. Ransomware has changed that paradigm. Today, attackers deliberately try to identify, encrypt or delete backup copies before launching the main attack.
This means that older strategies, such as backups permanently connected to the network, without access control or without protected versions, are no longer enough. The focus has shifted from simply having backups to making them resilient.
When backups fail at the critical moment
After an attack, companies often discover problems they had never considered:
Backups encrypted by the ransomware itself
Backup copies containing already compromised data
No clean versions from before the attack
Restore times incompatible with operations
No clear recovery procedures
These situations turn backups into a false safety plan, increasing the pressure to pay the ransom.
The role of immutability in protection against ransomware
One of the most important concepts in fighting ransomware is backup immutability. Immutable backups are copies that nobody can alter or delete for a defined period, not even users with elevated permissions.
This approach ensures that, even if attackers gain access to the systems, they cannot delete or modify the backup copies. Immutability therefore becomes an essential layer of defence, especially in critical environments.
Separating environments: A fundamental principle
Another essential good practice is to separate production and backup environments. When backups sit too close to the main systems, sharing credentials, access or infrastructure, they become easy targets.
An effective strategy includes:
Isolated backup infrastructure
Dedicated accounts and permissions
Strong, controlled authentication
Restricted and monitored access
This separation significantly reduces the attack surface and increases the chances of recovery.
Backups with clean versions and adequate retention
In a ransomware attack, it is not always clear when the infection began. For this reason, it is essential to keep multiple versions of backups over time. A well-defined retention policy lets you go back to a safe point, before attackers compromised the systems.
Retention periods that are too short can mean losing every clean version. On the other hand, excessive retention increases costs and complexity. The balance should reflect the risk and criticality of the data.
Restore tests: The difference between theory and reality
Having protected backups is not enough. It is essential to test regularly whether you can successfully restore those backups after a ransomware incident.
Restore tests make it possible to:
Validate the integrity of the copies
Confirm actual recovery times
Identify forgotten dependencies
Prepare teams for crisis scenarios
Without these tests, the ability to recover remains purely theoretical.
Benefits of a ransomware-ready backup strategy
Companies that adopt a mature, preventive approach gain clear advantages:
A drastic reduction in the impact of attacks
Less reliance on decisions made under pressure
A faster return to normal operations
A lower likelihood of paying ransoms
Stronger internal and external trust
In addition, a solid backup strategy supports legal compliance and the organisation’s reputation.
Practical recommendations to strengthen recovery
To make sure backups fulfil their role in a ransomware scenario, a few actions are essential:
Implement immutable backups wherever possible
Isolate the backup infrastructure from production
Define clear retention and versioning policies
Automate backups and monitor failures
Carry out periodic restore tests
Document incident response procedures
These measures do not eliminate the risk, but they significantly reduce the impact.
The first hours after an attack
The ability to recover depends largely on what the organisation does in the first few hours. For this reason, the organisation should write and test its response plan before any incident:
- Contain. First, isolate the affected systems from the network to stop the attack from spreading.
- Protect the copies. Next, confirm that the backup infrastructure remains isolated and that the immutable copies are still intact.
- Assess. Identify the affected systems, the likely time of infection and the data involved, including personal data.
- Notify. Meet the applicable notification obligations, for example to the Portuguese Data Protection Authority (CNPD) in the event of a personal data breach and, for entities in scope, to the CNCS. It is also advisable to report the crime to the authorities.
- Recover. Restore from a clean version, in order of system priority, after removing the cause of the attack.
- Learn. Finally, analyse what went wrong and strengthen the controls.
Does paying the ransom solve the problem?
Cybersecurity authorities advise against paying. In fact, paying does not guarantee data recovery, it funds new attacks and it can make the organisation a preferred target. Moreover, even when attackers hand over the decryption key, recovery is often slow and incomplete. Therefore, the best way to avoid facing that decision is to have backups that withstand the attack and a tested recovery plan.
Resilience checklist
| Question | Expected answer |
|---|---|
| Is there an immutable or offline copy of critical systems? | Yes, with a defined retention period |
| Are backup credentials separate from production credentials? | Yes, with multi-factor authentication |
| How many previous versions can we recover? | Enough to return to a point before the infection |
| When was the last full recovery test? | Within the period defined in the policy |
| Is there a written response plan that everyone knows? | Yes, with up-to-date owners and contacts |
Example: An infection that began weeks earlier
Attackers hit an organisation on a Monday, but the analysis showed that they had been inside the network for three weeks. The previous week’s copies already contained malicious tools. Since the retention policy kept daily versions for thirty days, the team managed to restore from a version prior to the intrusion. It then applied the most recent data after checking it. As a result, a well-sized retention policy made the difference between a clean recovery and reinfecting the systems.
Resilience indicators
- percentage of critical systems with an immutable copy;
- number of recoverable versions per system;
- actual recovery time in the latest tests;
- accounts with access to the backup infrastructure and how they authenticate.
In this way, management can track how prepared the organisation is with concrete data, not just with assurances that backups exist.
Frequently asked questions about ransomware and backups
Does a cloud copy protect against ransomware?
Only if it has protection against modification and deletion, and if nobody has exposed the access credentials. For example, a folder that syncs with the cloud may simply replicate the encrypted files.
How often should we review the response plan?
At least once a year and whenever systems, suppliers or key people change. Likewise, an annual simulation exercise helps make sure everyone knows their role.
Questions for senior management
- If attackers struck today, would we have a copy they could not delete?
- Who decides, and on what criteria, during the first hours of an incident?
In short, making sure recovery is possible requires three things: copies that the attacker cannot destroy, enough versions to return to a clean point and tests that prove restoring works. When these three conditions are in place, ransomware remains a serious incident, but it no longer threatens the organisation’s survival.
Furthermore, ransomware preparation should involve management, not just the technical team. After all, decisions such as the recovery order of systems or how to communicate with customers directly affect the business.
In this way, recovery no longer depends on luck but on a process that the organisation knows, has tested and can carry out under pressure.
Backups as the last line of defence, but not the only one
It is important to stress that backups do not replace other security measures, such as antivirus software, network segmentation or user training. However, when all the other layers fail, backups determine whether the company recovers or collapses.
Therefore, companies should treat backups as a strategic asset, not as a simple technical task.
Conclusion: Recovery is the real victory
In a ransomware attack, the real victory is not avoiding the incident at all costs, which is increasingly difficult, but recovering quickly, without irreversible losses and without giving in to blackmail.
Ransomware-ready backups are the result of careful design, protection and testing. Companies that invest in this preparation gain resilience, autonomy and response capacity. The rest keep relying on luck and, with cyberattacks on the rise, that is a risky bet.
See also: Ransomware: The code that holds digital data hostage and The importance of backup restore tests for business continuity and security.
For guidance on ransomware prevention and response, see the Portuguese National Cybersecurity Centre (CNCS).