Ransomware Cloud Backup: How to Protect Your Backups from Ransomware

Ransomware cloud backup protection means configuring your backup copies so an attack that specifically targets backups, not just production systems, can’t delete, encrypt, or disable them. Ransomware operators now go after backup infrastructure as a deliberate first move, because a working backup is what lets a victim refuse to pay.

If you assumed “we have cloud backup” already answered this problem, you’re not alone, and you’re also not fully covered. Plenty of cloud backups can be deleted, overwritten, or disabled by anyone holding valid admin credentials, which is exactly what a ransomware operator has by the time they reach your backup console. This guide covers what stops that.

Why ransomware attackers go after your backups first

Ransomware groups target backup infrastructure before encrypting production data because a business with intact backups can restore and refuse to pay. Disabling or deleting backups first removes that option, turning a recoverable incident into one where paying the ransom looks like the only path back to operating.

This isn’t a rare tactic anymore, it’s close to standard operating procedure for modern ransomware operations. Attackers who gain access to a network typically spend days or weeks quietly mapping out infrastructure before triggering encryption, and backup systems are near the top of that reconnaissance list. They look for backup software consoles, the credentials that control them, and any snapshot or shadow copy mechanism that could let a victim roll back changes without paying. Security researchers tracking major ransomware families have repeatedly found backup deletion built directly into the attack playbook, executed in the hours before encryption starts, precisely so the victim doesn’t notice until both problems have already happened.

The practical takeaway is that your ransomware cloud backup strategy has to assume the attacker will have valid credentials to your backup environment at some point during the attack. Protecting backups can’t rely solely on network security holding the line, because that’s exactly the assumption ransomware operators are now built to defeat.

The actual attack sequence: how backups get destroyed, step by step

Backup destruction during a ransomware attack follows a predictable sequence: gain a foothold, escalate to admin-level access, locate backup infrastructure and credentials, disable or delete backup jobs and snapshots, then trigger encryption across production systems. Understanding this order is what tells you where to place your defenses.

Stage	What Happens	Why It Matters for Backup
1. Initial access	Phishing, exposed RDP, or a vulnerable public-facing service gets exploited	No backup impact yet, but the clock has started
2. Privilege escalation	Attacker gains domain admin or equivalent access	This is often the access level needed to reach backup consoles
3. Reconnaissance	Attacker maps out backup software, storage targets, and snapshot mechanisms	Backup infrastructure gets specifically identified, not stumbled into
4. Backup neutralization	Backup jobs disabled, snapshots and shadow copies deleted, retention shortened	This is the step immutability and air gaps are built to block
5. Encryption	Production systems and any reachable backups get encrypted	Recovery now depends entirely on what survived step 4

The critical window is step 4. Everything before it is preparation; everything after it is often too late. A backup that can be reached and deleted with the credentials an attacker already stole by step 2 will not survive to step 5. This is exactly why immutability and offline copies matter so much: they take the deletion option off the table even when the attacker already has admin-level access to everything else.

What is an immutable backup, and how does WORM/Object Lock actually work?

An immutable backup is a copy of data that cannot be altered, encrypted, or deleted for a set retention period, even by someone holding valid admin credentials. This is enforced through WORM storage, write once read many, using a mechanism like Amazon S3’s Object Lock, which locks each object at the storage layer rather than relying on application-level permissions.

The mechanics matter here because they explain why immutability works even against a compromised admin account. Once an object is written under Object Lock with a retention period set, the storage system itself refuses delete or overwrite requests until that period expires, regardless of what permissions the requesting account has. This is different from a normal backup file sitting in a folder, where anyone with delete permission on that folder, including an attacker who stole those credentials, can remove it in seconds. Immutable storage moves the protection from “who has permission” to “what the storage engine will physically allow,” which is a much harder barrier for an attacker to defeat.

Most major cloud storage providers and backup vendors now support some form of WORM or Object Lock, but it’s rarely on by default. Someone has to configure it, set a retention period long enough to matter, and apply it to the backups that genuinely need this level of protection.

Compliance mode vs governance mode — a distinction that actually matters

Governance mode Object Lock can be overridden by an account with special bypass permissions. Compliance mode cannot be overridden or deleted by anyone, including the account’s root user, until the retention period fully expires. This difference decides whether your immutable backup is genuinely unbreakable or only unbreakable for most people.

This distinction gets glossed over constantly, and it’s one of the most consequential settings in the entire ransomware cloud backup conversation. Governance mode exists for legitimate operational flexibility, letting an organization correct a mistake or adjust retention without waiting out the full lock period. But that flexibility is controlled by a permission, s3:BypassGovernanceRetention in AWS’s implementation, and any account holding that permission can remove the lock. Here’s the problem: the accounts most likely to hold broad administrative permissions, including bypass rights, are exactly the accounts ransomware operators compromise through privilege escalation. A backup protected only by governance mode is protected against an ordinary user’s mistake, not against an attacker who has already taken over an admin account.

Feature	Governance Mode	Compliance Mode
Can be overridden	Yes, by accounts with bypass permission	No, by anyone, including root
Flexibility	Higher, useful for correcting mistakes	None until retention expires
Ransomware resistance	Moderate, depends on account compromise	High, retention holds regardless of credentials
Best used for	Non-critical or frequently adjusted retention	Critical backups meant to survive a full compromise

For backups you’re relying on as your last line of defense against ransomware, compliance mode is the setting that delivers on the promise of immutability. Governance mode still has legitimate uses, but treating it as equivalent ransomware protection is a mistake several businesses only discover after an incident, when the backup they thought was locked turns out to have been deleted using the exact bypass permission an attacker had already claimed.

The limitation nobody mentions: what happens when the backup itself is already infected

Immutability guarantees a backup can’t be deleted or altered once written. It does not guarantee the data written into that backup was clean in the first place. If ransomware has already encrypted files before the next backup job runs, an immutable backup will faithfully preserve that encrypted, unusable version, permanently, for the full retention period.

This is the gap almost no competitor content addresses, and it changes how you should think about backup frequency and retention depth. Ransomware often sits quietly for days or weeks before triggering encryption, which means your “clean” backup window might have already closed by the time you realize anything is wrong. If your immutable backup only retains the last seven days and the attacker was present for ten, every immutable copy you have could be locked in on already-compromised data. Immutability protected the backup from the attacker’s deletion attempt, but it can’t protect you from backing up a problem that already happened.

The practical fix has two parts. First, retention needs to be long enough to reach back past a realistic dwell time, industry incident response data commonly shows attackers present for one to several weeks before encryption triggers, so a retention window of just a few days is rarely enough. Second, backups need integrity verification, not just immutability, meaning some process checks that a restore point is usable and free of indicators of compromise before you rely on it during a real recovery. A business that only asks “is our backup immutable” and never asks “how far back can we reach a genuinely clean copy” is solving half the problem. This is one of the most common gaps we flag when reviewing backup architecture with clients, because it stays invisible until the exact moment a restore fails to solve the incident.

Immutable vs air-gapped — why you need both, not either

Immutable backup stops deletion and alteration through a storage-level lock. An air-gapped backup stops reachability entirely, by keeping a copy physically or logically disconnected from the network most of the time. They defend against different failure modes, and relying on only one leaves the other door open.

Immutability is powerful, but it typically still lives on infrastructure that’s network-reachable, meaning an attacker with sufficient access could theoretically still reach the storage layer, exfiltrate data from it, or in edge cases exploit a misconfiguration to work around the lock. A true air gap removes that risk by making the backup simply unreachable during normal operations, whether that’s offline removable media, a segmented network with no persistent connection, or a cloud environment intentionally isolated from your production credentials and network path.

Protection	Defends Against	Doesn’t Defend Against
Immutable backup (compliance mode)	Deletion, encryption, and alteration of the backup copy	Reachability if credentials or network access are compromised
Air-gapped backup	Reachability, since the copy isn’t accessible during normal operations	Doesn’t help if the air gap is bridged during a restore and reinfected

The strongest posture layers both together: an immutable copy for backups you need to restore quickly, and a genuinely air-gapped copy as the fallback if something goes wrong with the immutable layer itself, whether that’s a misconfiguration, an expired retention period nobody renewed, or a vulnerability in the storage platform. This layered approach is also what sits behind the 3-2-1-1 rule, covered later in this guide, which explicitly calls for one immutable or offline copy in addition to standard backup redundancy. Treating immutable and air-gapped as competing options, rather than complementary layers, is one of the most common strategic mistakes businesses make when building ransomware-resistant backup.

Does your SaaS platform (Microsoft 365, Google Workspace) protect you here?

Microsoft 365 and Google Workspace do not provide immutable, ransomware-grade backup by default. Their native recycle bin and version history features are built for accidental deletion, with retention windows typically well under six months, and neither guarantees an immutable, air-gapped copy of your data.

This gets missed constantly because SaaS platforms feel like they’re already “in the cloud” and therefore already backed up. That’s a misunderstanding of the shared responsibility model both platforms operate under. Microsoft and Google guarantee the platform stays up and available. They do not guarantee that your specific data survives a user error, an insider deleting content deliberately, or ransomware that encrypts synced files through OneDrive or Google Drive before anyone notices. Native version history can even work against you here, since some ransomware variants create new encrypted versions of files, and if enough clean versions age out of the retention window before detection, there’s nothing left to roll back to.

Cloud-to-cloud backup closes this gap by creating an independent, separately stored copy of your SaaS data, using types of cloud backup designed specifically for platforms like Microsoft 365 and Google Workspace rather than general file backup. Several third-party tools now support immutable, WORM-protected storage specifically for this SaaS backup use case, giving you the same compliance-mode style protection for your email and files that you’d expect from your server backups. If your business runs day-to-day operations through Microsoft 365 or Google Workspace, and most SMBs do, this is not an optional add-on. It’s the backup layer that’s most likely to be missing entirely.

What does NCSC’s own guidance require for cloud backup specifically?

The UK’s National Cyber Security Centre requires that ransomware-resistant cloud backups include an immutable or offline copy, strict access controls separate from production credentials, monitoring for unauthorized backup changes, and regular tested restores rather than backups nobody has verified.

NCSC’s cloud backup principles exist specifically because generic “we have backups” language wasn’t holding up against the attack sequence covered earlier in this guide. The guidance pushes organizations toward exactly the layered approach this article has walked through: immutability so a compromised account can’t delete backups, credential separation so backup access isn’t tied to the same identity an attacker would compromise to reach production, and active monitoring so a backup deletion attempt gets flagged immediately rather than discovered during a failed recovery.

For UK businesses, referencing NCSC’s cloud backup principles specifically, rather than generic backup best practice, is increasingly what insurers and Cyber Essentials assessors expect to see during a review. US businesses without a direct NCSC obligation still benefit from the same logic, since it mirrors what NIST and the broader incident response community, including patterns documented across the Verizon Data Breach Investigations Report, consistently find: backups fail during real incidents because of access control gaps and unverified restores, not because immutability technology doesn’t exist. At Cyber Security Solutions Ltd, backup architecture reviews against NCSC and Cyber Essentials expectations are a regular part of the ransomware readiness work we do with clients on both sides of the Atlantic.

A realistic starting point if you’re not running enterprise-scale infrastructure

A realistic starting point is the 3-2-1-1 rule: three copies of your data, on two different media types, with one copy offsite, and at least one copy immutable or air-gapped. You don’t need enterprise cyber vault infrastructure to implement this, most cloud backup platforms now support it directly.

For a small or mid-sized business, this breaks down into a manageable checklist rather than a large infrastructure project. Start by confirming your current backup provider supports Object Lock or an equivalent WORM feature, and if it does, enable compliance mode, not governance mode, on at least your most critical backup set. Next, separate backup admin credentials from your general IT admin accounts entirely, with multi-factor authentication required, so a compromised general admin account doesn’t automatically grant backup access too. If your business runs on Microsoft 365 or Google Workspace, add a dedicated cloud-to-cloud backup tool rather than relying on native retention. Finally, set a retention period on your immutable copy that reaches back at least two to three weeks, long enough to cover typical ransomware dwell time, and test a real restore at least twice a year so you know the backup works before you need it to.

None of this requires the budget of a large enterprise. It requires deciding that backup configuration is a security control, not a checkbox, and treating the settings covered in this guide, compliance mode, credential separation, retention depth, as decisions worth making deliberately rather than leaving on default.

Conclusion

Ransomware cloud backup protection comes down to a handful of deliberate settings: compliance mode instead of governance mode, credential separation, retention deep enough to outlast dwell time, and at least one copy that’s genuinely air-gapped rather than just labeled immutable. None of these require enterprise budgets, but all of them require someone to configure them rather than assume the default is enough. If you want a second set of eyes on whether your current backup setup would survive the attack sequence covered in this guide, Cyber Security Solutions Ltd reviews backup and ransomware resilience configurations as part of our security assessments. Reach out through cybersecuritysolutionsltd.com to get your setup checked.