An immutable backup is a copy of your data that nobody can change or delete until a retention period you set has run out. That includes the attacker holding a stolen admin password, and it includes your own administrators. It works because the storage enforces a write-once-read-many (WORM) rule, so the lock does not depend on anyone's permissions. If ransomware reaches your network, immutable copies are the ones still standing.
This guide explains how immutability works, where it gets misconfigured, what it looks like in Azure and AWS, and how to test that it will actually bring your business back.
TL;DR
- Immutable backups use WORM storage, so data cannot be modified, encrypted or deleted for a fixed retention period, even by privileged admins.
- The lock mode matters more than the product. A mode that admins can still override gives you little protection against a compromised admin account.
- Pair immutability with soft delete, separate backup admin accounts and monitoring that lives outside production.
- Follow the 3-2-1 rule, and prove recovery by restoring whole workloads, not single files.
- Start with a modest retention lock. A locked multi-year setting cannot be shortened if you get it wrong.
Table of Contents
- What makes a backup immutable
- Why attackers go after backups first
- The lock mode is the whole game
- Immutable backups in Azure
- Immutable backups in AWS
- Immutability is not enough: the other failure points
- A practical rollout for a small business
- Costs and tradeoffs to expect
- Our perspective
- Where Mindpod can help
- FAQ
- Sources
What makes a backup immutable
Most backups are protected by permissions: only certain accounts can delete them. That works until one of those accounts is stolen. Immutability replaces the permission check with a time-based rule enforced by the storage platform. Microsoft describes its immutable storage for blob data as a WORM state in which data cannot be modified or deleted for a user-specified interval. Once the interval is set and locked, the platform refuses delete requests, no matter who sends them.
Two details are easy to miss:
- Immutable does not mean invisible. You can still read and restore the data. You just cannot change it.
- Immutable does not mean forever. Data becomes deletable once the retention period ends. That is how you control storage cost.
An immutable copy is a restore point frozen at a moment in time. If you restore it, you get exactly what existed when the backup was taken.
Why attackers go after backups first
Modern ransomware crews do not simply encrypt files. They look for your recovery options first. The August 2026 CISA advisory on Gunra ransomware describes a variant that targets backup infrastructure and volume shadow copies before it encrypts anything. The same guidance recommends testing offline, immutable backups kept in physically separate or segmented locations, so you can recover without paying a ransom.
For a small or midsize business, this changes the question. It is no longer "do we have backups?" It is "can an attacker with domain admin rights delete them?" If the honest answer is yes, you have a copy of your data that is only as safe as your weakest credential.
The lock mode is the whole game
Immutability comes in two broad flavors, and the difference decides whether it protects you.
| Mode | Who can remove protection | Ransomware value | Main risk |
|---|---|---|---|
| Unlocked or governance style | Privileged users can shorten or remove the policy | Low if an admin account is compromised | Gives a false sense of security |
| Locked or compliance style | Nobody, until retention ends | High | A mistaken long retention cannot be undone |
Microsoft's ransomware-resilient backup architecture guidance is explicit that a locked vault is irreversible. Once locked, you can extend retention but you cannot reduce it, and not even the account owner can undo it. That is the point, and it is also the hazard. If you set a multi-year lock on the wrong vault, you will pay for that storage for the full term.
A sensible approach for a first rollout:
- Enable immutability in the unlocked state on a test vault.
- Confirm backups, restores and retention behave as expected.
- Lock it with a retention period that matches your real recovery needs, not the longest option available.
- Extend later if requirements change. Extending is always allowed, shortening is not.
Immutable backups in Azure
If you run Microsoft workloads, Azure offers two distinct tools. They protect different things, and it is common to confuse them.
Immutable vault for Azure Backup. This protects recovery points inside a Recovery Services or Backup vault. Microsoft says it blocks operations that could lead to loss of recovery points, and you can lock the setting to make it irreversible. It applies to the whole vault, so everything protected in it inherits the rule.
Immutable blob storage. This protects blob data at the account, container or version level through time-based retention policies or legal holds. It suits archived backup files and copies exported from other systems, including backups from non-Azure tools that write to blob storage.
For databases, Azure SQL has its own option: backup immutability for long-term retention backups keeps those backups in a WORM state for a user-defined period.
Add soft delete and separate permissions
Immutability is not a standalone control. Microsoft's Azure Backup best practices recommend layering it with other protections:
- Soft delete with a retention of at least 35 days, aligned to your primary backup retention. Soft delete can be configured up to 180 days. It covers data deleted before the lock takes effect or during an incident.
- Multi-User Authorization so that one compromised account cannot change protection policies alone.
- A locked immutable vault so recovery points cannot be removed early.
Soft delete and immutability are complements. Soft delete is a safety net for deletions that already happened. Immutability prevents the deletion in the first place.
Immutable backups in AWS
If your backups sit in Amazon S3, the equivalent feature is Object Lock. AWS documents two retention approaches, retention periods and legal holds, and lets you set a default retention on a bucket or a unique period on individual object versions. AWS also notes that Object Lock has been assessed for environments subject to SEC 17a-4, CFTC and FINRA rules, which matters if you are a regulated firm.
The same lock-mode warning applies. Check which retention mode your bucket uses before you trust it. A mode that privileged users can bypass is a convenience feature, not a ransomware defense.
Immutability is not enough: the other failure points
Most backup disasters are not caused by missing technology. They come from how it is administered. A few patterns show up repeatedly in CISA and NIST guidance and in Microsoft's architecture material.
Shared administrators
If the people and accounts that run production also control the backup vault, one stolen credential loses both. Microsoft's architecture guidance calls for separation of duties, with just-in-time elevation through privileged identity tools, so backup administrators are distinct from production operators. In a ten-person company this feels heavy, but it can be as simple as a separate backup admin identity with multifactor authentication that nobody uses for daily work.
Monitoring that lives in the same place
An attacker who controls your production subscription can mute alerts and delete diagnostic logs, buying time to destroy backups quietly. Route backup health alerts, failed-job reports and logs to a separate, hardened environment. Even a simple out-of-band channel helps: a dedicated alert mailbox for monitoring that is not tied to your production tenant keeps failure notices reachable when the main environment is compromised.
A single copy, a single location
The long-standing 3-2-1 rule from NIST's National Cybersecurity Center of Excellence says to keep three copies of your data, on two different media types, with one copy off-site or physically isolated. Attackers seek out every connected repository, so relying on one method or location is a primary failure point. If you are sizing on-premises disk for a local copy, a RAID capacity calculator helps you estimate usable space. Remember that RAID protects against disk failure, not against deletion or encryption.
Backups that have never been restored
A green "backup succeeded" status says only that data was written. It says nothing about whether you can use it. Restores fail because of missing encryption keys, network dependencies or wrong permissions. NIST material treats recovery testing, including full restoration drills, as a periodic requirement to confirm data integrity and that recovery time objectives are met.
A practical rollout for a small business
You do not need an enterprise budget. You need a clear order of operations.
Step 1: List what you cannot lose
Name the systems that would stop revenue if they vanished: accounting, customer records, line-of-business databases, file shares, email and identity. Rank them by how many hours of downtime and how much lost data (recovery time and recovery point objectives) the business can survive.
Step 2: Pick the immutable target
Match the tool to the data:
- Azure virtual machines and databases protected by Azure Backup: immutable vault.
- Backup files and exports stored as blobs: immutable blob policies.
- Data in S3: Object Lock in a mode that admins cannot override.
- On-premises backup software: confirm it can write to an immutable repository or an immutable cloud tier.
Step 3: Set retention deliberately
Start from your real needs. Many businesses hold 30 to 35 days of operational backups plus longer monthly or yearly copies for finance and compliance. Do not lock anything beyond what your policies or regulators require until you have restored from it successfully.
Step 4: Separate the keys
Create dedicated backup administrator identities, require multifactor authentication, and remove standing access for production admins. Keep break-glass credentials offline and documented.
Step 5: Move monitoring out of production
Send alerts and logs somewhere an attacker in production cannot reach. Review failures on a schedule, not only when someone remembers.
Step 6: Test the restore
Once a quarter, restore an entire critical workload into an isolated network and time it. Check that the application starts, that users can sign in and that the data is current. Write down what broke and fix it. CISA's Gunra guidance stresses this end-to-end view rather than single-file spot checks.
Costs and tradeoffs to expect
Immutability is not free, and it is better to know the tradeoffs before you commit.
- Storage cost. Data you cannot delete accrues charges until the retention ends. Short, well-reasoned retention keeps this predictable.
- Operational rigidity. A locked mistake stays a mistake. Test in an unlocked state first.
- Data you must remove. If privacy rules require deleting specific records, long immutable retention may conflict. Talk to your counsel about retention periods before locking sensitive data for years.
- False confidence. Immutability protects the backup copy. It does not stop an attacker from stealing data, and it does not fix a backup that captured already-infected systems. Pair it with patching, identity hardening and detection.
These are manageable. The cost of recovering without clean backups is typically far worse.
Our perspective
When we look at small-business environments, the gap is rarely that nobody bought backup software. It is that backups are treated as a checkbox owned by whoever set them up years ago. The vault is reachable by the same admin accounts as everything else, alerts go to a mailbox nobody watches, and no one has ever restored a full system under pressure.
Our view is that immutability is worth doing, but only as part of a tested recovery design. We would rather see a business lock a modest 35-day vault, separate its admin identities and run a real restore drill than lock three years of data it has never recovered. We also push for plain-language ownership: you should be able to read your own recovery plan, know who can change it and know how long it takes to bring the business back.
That is how we approach backup and disaster recovery work: find the failure points, rank them by risk and cost, fix the ones that matter first, and prove the result with a restore.
— jaras
Where Mindpod can help
If you run on Azure and are not sure whether your backups would survive a compromised admin account, we can look at it with you. Our free technology assessment reviews how your backups, access and monitoring are set up and gives you a prioritized plan in plain language that you own. You can read about our cloud and training services or talk to us about an assessment.
FAQ
Are immutable backups the same as offline or air-gapped backups?
No, though they solve a similar problem. An air-gapped or offline copy is protected by being unreachable. An immutable copy can stay online and reachable for restores, but the storage refuses changes and deletions. CISA's guidance speaks of offline, immutable backups, and many businesses use both.
Can ransomware still encrypt an immutable backup?
Not the locked copy itself. Ransomware can still compromise your production systems, and it can delete or encrypt backups that are not protected. The risk with immutable copies is configuration: if the mode lets privileged users shorten retention, an attacker with those rights may be able to remove protection first.
What retention period should I choose?
Match it to how long it takes you to notice a problem and to what your policies require. Microsoft recommends soft delete of at least 35 days, aligned with primary backup retention, so many small businesses start near that figure for operational backups. Extend later if needed, because shortening a locked period is not possible.
Do I need immutable backups if I already use a cloud service like Microsoft 365?
Cloud providers keep their platform running, but you remain responsible for your data. Deleted or encrypted content can be lost if the retention windows lapse or an admin account is abused. Check what your plan retains and consider an independent, immutable copy of the data you cannot afford to lose.
How often should I test a restore?
NIST treats recovery testing as a periodic requirement. For most small businesses, a full restore of one critical workload each quarter, plus a test after any major change, is a workable rhythm. Record the time it takes and compare it with your recovery time target.
Sources
- CISA: #StopRansomware Gunra Ransomware
- Microsoft Learn: Immutable storage for blob data
- Microsoft Learn: Design a ransomware-resilient backup architecture
- Microsoft Learn: Concept of immutable vault for Azure Backup
- Microsoft Learn: Backup immutability for Azure SQL long-term retention
- Microsoft Learn: Azure Backup security best practices
- AWS: Locking objects with Object Lock
- NIST NCCoE: Protecting data from ransomware