A ransomware incident rarely begins with a dramatic screen message. More often, an attacker has already spent time inside the network, identifying valuable systems, stealing credentials and looking for the backups that would allow the organisation to recover. So, can ransomware infect cloud backups? Yes, it can, particularly where backups are connected, accessible with everyday administrator accounts or treated as a simple file storage exercise.
Cloud backups can provide excellent resilience, but “in the cloud” is not the same as “out of reach”. The difference comes down to how the backup environment is designed, protected and tested.
Can ransomware infect cloud backups?
Ransomware can encrypt, delete, corrupt or make cloud backups unavailable. Attackers do not need to break into the cloud provider’s infrastructure to do this. In many cases, they use a compromised user or administrator account, an exposed backup management console, or permissions that are broader than they need to be.
If a backup platform is permanently connected to the main network and accepts the same credentials used to manage production systems, it may be within reach of an attacker. They may delete recovery points, reduce retention periods, alter backup jobs or encrypt data that is being synchronised to cloud storage.
There is also a distinction between an infected backup and an unusable one. A backup may remain technically intact but contain encrypted files because the ransomware was copied during a scheduled backup. If the organisation has no earlier clean recovery point, the outcome is much the same: restoring it does not return operations to normal.
The good news is that this is not an unavoidable weakness of cloud backup. Well-designed cloud backup can be significantly harder for an attacker to compromise than a single on-site backup device. It needs the right safeguards, not just a subscription and a daily schedule.
Why cloud backups are a target
Ransomware groups understand that backups change the balance of an incident. An organisation with a clean, tested and accessible copy of its data has a credible alternative to paying a ransom. That makes backup infrastructure a priority target.
Many modern attacks involve a period of reconnaissance before encryption begins. The attacker may identify domain administrators, map servers, locate backup software and attempt to obtain the credentials used by IT teams or service accounts. Some groups also steal data first, then threaten to publish it alongside the encryption attack. Backups help restore systems, but they do not remove the need to manage a data breach properly.
Cloud services introduce several routes that need attention. A file synchronisation service may faithfully copy encrypted files or deletions to the cloud. A compromised Microsoft 365 account could allow an attacker to delete content or recovery versions if permissions and retention controls are not properly configured. A cloud backup console protected only by a password may be vulnerable if that password is reused, phished or obtained through a compromised device.
This is why backup resilience cannot sit separately from identity security, endpoint protection and access management. Recovery is an operational capability, not simply a place where data is stored.
The difference between cloud storage and protected backup
Cloud storage is useful for collaboration and access, but it is not automatically a backup. Services such as SharePoint, OneDrive and Teams include useful retention and versioning features, yet those features are designed around everyday productivity. Their limits, retention settings and recovery options may not meet the organisation’s requirements after a serious incident.
A protected backup is designed to retain recoverable versions of data independently of the live environment. It should allow a business to restore a file, mailbox, server, application or complete virtual machine to a point before the compromise occurred. Crucially, it should not be easy for someone with access to the production network to alter or remove those copies.
Version history can help when a small number of files have been encrypted or overwritten. It is less reassuring when an attacker has administrative access, has been present for weeks, or has deliberately targeted retention settings. Relying on version history alone can leave too much to chance.
What makes a cloud backup resistant to ransomware
There is no single setting that makes backups immune. Effective protection is layered and should reflect the systems that keep the organisation running, the impact of downtime and the sensitivity of its data.
A useful starting point is the 3-2-1-1-0 approach. Keep at least three copies of data, on two different forms of storage, with one copy held off-site, one copy offline or immutable, and zero unresolved errors verified through testing. It is a practical principle rather than a rigid formula. A small business may apply it differently from an academy trust, manufacturer or public sector organisation, but the underlying aim is the same: one compromised system should not be able to destroy every recovery option.
Immutable copies prevent unauthorised changes
Immutability means a backup cannot be changed or deleted for a defined retention period, even by a highly privileged account. This is one of the strongest protections against ransomware because it creates a recovery point outside an attacker’s control.
The setting needs careful planning. Retention periods must be long enough to cover the likely time between intrusion and discovery. If backups are immutable for only a few days, but the attacker was inside the environment for a month, the clean copy may already have expired. Longer retention may increase storage costs, so organisations should base the policy on risk, regulatory duties and realistic recovery needs rather than selecting the cheapest default.
Separate access limits the blast radius
Backup administration should use separate accounts from standard network administration, with multi-factor authentication enforced. Those accounts should be tightly controlled, monitored and used only when required. A compromised everyday Microsoft 365 or domain administrator account should not automatically provide the keys to the backup platform.
The same principle applies to service accounts, application programming interfaces and supplier access. Use least-privilege permissions and review them regularly. In practical terms, this may mean that a service desk user can check whether a backup succeeded but cannot delete a backup repository or change retention rules.
Isolation matters as much as location
A backup copy stored in a different cloud region is useful for availability, but it may still be vulnerable if it is managed through the same console and credentials as the live system. True resilience needs a degree of administrative separation.
Depending on the environment, that might include an isolated backup tenant, a hardened backup vault, restricted network access, or an offline copy. The right choice depends on budget, recovery objectives and technical complexity. The key question is straightforward: if an attacker gains control of the primary environment, what stops them reaching this backup?
Monitoring spots tampering early
Alerts should cover more than failed backup jobs. Sudden deletion requests, changes to retention policies, unusual logins, disabled multi-factor authentication and mass file changes all deserve investigation. Centralised logging makes it easier to see activity across identity systems, endpoints and backup services rather than treating each as a separate event.
Early detection matters because ransomware often has a preparation phase. Finding an attacker before encryption begins can protect both production systems and the clean recovery points needed afterwards.
Recovery testing is where confidence is earned
A backup that has never been restored is an assumption, not a recovery plan. Organisations should test recovery at intervals that reflect the importance of their systems. This should include more than restoring a single document to prove the software works.
Test whether staff can recover key business applications, shared files, mailboxes and critical servers within the required timeframe. Confirm that the restored data is complete, that applications function correctly and that the people responsible know their roles. For a manufacturing business, that may mean testing systems that support production scheduling. For a school or charity, it may mean checking access to safeguarding records, finance systems and essential communications.
Recovery testing can reveal difficult trade-offs. Restoring everything immediately is rarely realistic, particularly after a wide-ranging incident. A documented recovery priority helps the organisation bring essential services back first, while preserving evidence and avoiding the reintroduction of compromised systems.
A practical checklist for decision-makers
Senior leaders do not need to manage backup settings themselves, but they should be able to obtain clear answers to a few questions:
- Are our critical systems and Microsoft 365 data covered by a defined backup policy?
- Do we have immutable or otherwise isolated recovery copies?
- Could a compromised administrator account delete our backups?
- How long would it take to restore the services we need most?
- When did we last complete a successful recovery test?
If the answers are uncertain, treat that as a business continuity risk rather than a purely technical gap. The financial and operational effects of several days without core systems can quickly outweigh the cost of improving backup protection.
A managed technology partner can help assess the current position, set realistic recovery objectives and build a backup approach that fits the organisation rather than forcing a one-size-fits-all design. The aim is not to create unnecessary complexity. It is to ensure that, when a ransomware incident puts normal operations under pressure, there is a clean and proven route back to work.
