A ransomware incident rarely stops at the files employees use every day. Once an attacker gains administrative access, they often look for the backup system next. So, can ransomware encrypt cloud backups? Yes, in many cases it can. Cloud storage alone does not make a backup safe from encryption, deletion, or tampering.
For a small or midsize business, that distinction can determine whether an attack becomes a short recovery project or a prolonged business interruption. A medical practice may lose access to patient records. A CPA firm may be unable to retrieve tax files during a deadline. A law office may face missed court dates, confidential-data exposure, and expensive downtime.
The good news is that cloud backups can be designed to withstand ransomware. The difference is not simply where the backup lives. It is how the backup is isolated, protected, retained, monitored, and tested.
How ransomware reaches cloud backup copies
Ransomware does not need to physically reach a server in your office to damage backups. Modern attackers commonly use stolen Microsoft 365 credentials, remote access accounts, VPN credentials, exposed administrative tools, phishing emails, or unpatched systems to establish a foothold. From there, they work to obtain higher-level privileges and identify systems that could help them prevent recovery.
If a backup application, cloud storage account, or backup management portal uses the same administrator credentials as the rest of the network, an attacker may be able to sign in and make changes. They may encrypt files that are synchronized to cloud storage, delete retained backup versions, shorten retention settings, disable scheduled backups, or remove the backup software entirely.
A cloud backup can also be compromised when it behaves more like file synchronization than a true backup. If an employee’s shared drive syncs to a cloud platform and ransomware encrypts the local files, those encrypted files may synchronize to the cloud almost immediately. Version history may help, but only if it is enabled, retained long enough, and still accessible to an authorized administrator.
Attackers understand this. Many ransomware groups spend time inside a network before launching encryption. They look for backup consoles, cloud administrator accounts, credentials saved in browsers, documentation files, and password managers. They may attempt to delete backups before encrypting production systems because they know a company with no recovery option is more likely to pay.
Can ransomware encrypt cloud backups when immutability is enabled?
Immutability changes the answer significantly, but it is not a magic setting. An immutable backup is stored so it cannot be altered or deleted for a defined retention period, even by an administrator in many configurations. If ransomware reaches the backup platform, it should not be able to encrypt or erase recovery points that are still under that retention lock.
That makes immutable storage one of the strongest defenses against backup-targeting ransomware. However, the protection depends on the implementation. If retention is set too briefly, attackers may wait until older clean backups expire. If an attacker controls the account that can change immutability policies before the lock takes effect, they may weaken the protection. If only some workloads are immutable, the unprotected systems remain a recovery risk.
A properly configured solution needs more than a checkbox. It needs separate administrative access, multi-factor authentication, defined retention periods, alerting for policy changes, and periodic review. The goal is to make it difficult for a compromised network administrator account to destroy every available copy.
The difference between cloud storage and a recoverable backup
Businesses often assume that files stored in OneDrive, SharePoint, Google Drive, Dropbox, or a cloud file server are automatically protected from ransomware. Those services provide valuable collaboration and availability features, but they should not be treated as the only backup strategy.
Cloud collaboration platforms may offer recycle bins, version history, and retention capabilities. These features can be enough to recover a mistakenly deleted document or a small number of damaged files. They may be less effective during a serious ransomware event involving thousands of files, compromised administrator accounts, intentionally deleted versions, or a broad Microsoft 365 tenant takeover.
A recoverable backup is built for a different purpose. It creates independent recovery points, retains them according to policy, protects them from unauthorized deletion, and gives the business a way to restore data after a major incident. For critical systems, it should also support restoring entire servers, applications, and configurations, not just individual files.
That distinction matters when a business needs to rebuild quickly. Restoring a few documents from version history is not the same as recovering an accounting server, a line-of-business database, a virtual machine, or a complete Microsoft 365 environment.
Build backups that ransomware cannot easily destroy
The familiar 3-2-1 backup model remains useful: keep at least three copies of data, on two different types of storage, with one copy offsite. For ransomware resilience, businesses should go further with the 3-2-1-1-0 approach. It adds one offline or immutable copy and zero unverified backup errors.
For many Chicago-area businesses, a practical design includes a local backup for fast restores, a separate cloud backup for offsite protection, and immutable retention for the most important data. The exact design depends on the applications in use, recovery time requirements, internet bandwidth, data volume, and compliance obligations.
Four controls deserve particular attention:
- Separate backup credentials: Backup administration should not rely on the same account used for daily email, file access, or network administration. Use unique accounts and require multi-factor authentication.
- Immutable or offline copies: Keep at least one copy beyond the reach of ordinary network credentials. Immutability is often more practical than physical media, but both can have a role.
- Protected backup infrastructure: Secure the backup server, management console, and storage access with patching, endpoint protection, restricted network access, and logging.
- Documented retention policies: Retain recovery points long enough to recover from an attack discovered weeks later. The right period varies, but a few days is rarely enough for critical business data.
Not every system needs identical retention. A legal practice may need long-term document retention. A medical office may need to protect electronic health record data and meet privacy obligations. A business with a large design archive may need monthly long-term copies alongside frequent daily backups. The key is to make those decisions intentionally rather than accepting default settings.
Testing is what makes a backup trustworthy
A backup job marked “successful” does not prove that you can recover. It may only prove that data was copied somewhere. The backup could be incomplete, corrupted, inaccessible because of credentials, or too slow to restore within an acceptable timeframe.
Test restores on a schedule. Start with individual files, then test a full folder, a key database, a virtual machine, or another business-critical workload. Confirm that the restored data opens correctly and that the process can be completed by the people who will handle an actual incident.
Testing also exposes operational gaps. Perhaps the backup is technically available, but no one has the recovery keys. Perhaps it takes four days to download the data over the current internet connection. Perhaps the line-of-business software requires a separate license key or configuration file that was never included in the backup.
Document those findings and adjust the plan. Recovery is not just an IT task. Owners and operations leaders need to know who can authorize restoration, how employees will communicate if email is unavailable, and which systems must come back first.
What to do if ransomware may have reached backups
Do not assume the newest backup is clean. Ransomware may have been present for days or weeks before encryption becomes obvious. Preserve available evidence, isolate affected devices, and avoid logging into every system with the same potentially compromised administrator account.
A qualified IT team should identify the attack path, review backup console activity, determine whether backup retention or deletion settings changed, and locate the last known clean recovery point. If immutable copies are available, confirm their status before beginning restoration. Restoring too quickly from an infected or incomplete backup can restart the incident.
Before putting restored systems back into production, reset compromised credentials, close the entry point, apply needed patches, review remote access, and verify endpoint and network security controls. Otherwise, the attacker may still have a way back in.
Cloud backups are a critical part of business continuity, but they are only as secure as the design behind them. A backup strategy that separates access, protects recovery points, and proves recoverability through regular testing gives your business a real path forward when an attack occurs.