Immutability has become a buzzword in the backup and cybersecurity world — and on the surface, it sounds like the perfect solution to a terrifying problem: ransomware.
The promise is simple: once your backup is written, it can’t be changed, deleted, or corrupted — even by you.
But here’s where, once again, you need to read the fine print: Not all “immutable backups” are actually immutable. And relying on the wrong kind could leave you just as vulnerable as if you had none at all.
Let’s Talk About What “Immutable” Really Means
In its truest form, immutability means WORM — Write Once, Read Many. It means there is only one original copy of your data which cannot be deleted or altered. You can replicate or read this immutable backup, but one thing is for sure, the original backup cannot be erased or modified. By anyone.
That’s the kind of protection you get when you’re using tools like:
- AWS S3 Object Lock (in Compliance Mode)
- Azure Immutable Blobs
- AWS Backup Vault Lock
These are storage-level protections — not just software switches. When set up properly, not even the root account can modify or delete your backups. We like to say, not even God can touch them! That’s the gold standard.
Now contrast that with what some SaaS backup vendors offer. They’ll tell you their backups are immutable too — but dig deeper and you’ll find:
❌ They rely on software controls
❌ The immutability is enforced by the SaaS platform itself
❌ A privileged user or a compromised token can sometimes delete data
❌Some third-party solutions offer “immutability” but store metadata or backups in ways that can be tampered with or aren’t independently verifiable.
If that’s the case, you’re just one exploit away from losing everything.
Even in the Cloud, There Are Pitfalls
Let’s say you’re using AWS or Azure — you’re still not out of the woods. There are modes and settings that make or break your protection:
- Governance Mode vs Compliance Mode in AWS S3: Governance Mode can be overridden by privileged users. Compliance Mode cannot — that’s the one you want.
- Object Lock or Vault Lock not enabled? Your backups can be deleted.
- Short retention settings? That backup might be gone before you realize you’ve been attacked.
- IAM Compromised? An attacker could stop backups, modify backup jobs, or encrypt production data — and if your backups aren’t frequent enough, your “latest backup” may already contain encrypted files.
Real-World Ransomware Protection: What You Actually Need
To build a truly resilient backup strategy, specific questions need to be asked and specific needs need to be addressed. You need to get a bit technical, and you need to get serious.
Here are some best practices to ensure you’re covered:
1. Use True WORM Protection
Enable S3 Object Lock or AWS Backup Vault Lock — and set them to Compliance Mode. Even the root user won’t be able to delete your backups. That’s real immutability.
2. Separate IAM Roles
Create and enforce dedicated IAM roles just for backup operations. Don’t let production users have access to delete or modify backup jobs.
3. Air-Gap Your Backups
Use cross-account or even cross-cloud strategies. Your backups should not be directly accessible from your production environment — period.
4. Monitor, Monitor, Monitor
Turn on CloudTrail, AWS Config, and GuardDuty to keep an eye on access logs and detect unusual activity. Backup deletions, policy changes, and login anomalies should all trigger alarms.
5. Test A Full Failover – OFTEN
A backup that can’t be restored quickly and cleanly isn’t a backup — it’s shelfware. Simulate a ransomware, malware, really any type of breach. Set up as many recovery scenarios as you possible can. Make sure you are drilling on a regular basis and that in addition to servers, network configurations, permissions and other settings are also restored. Test your ability to recover and generate comprehensive success logs. Make this a routine, not a checkbox and hand out all reports to relevant stakeholders.
Ask the Hard Questions
So here’s your challenge: Ask your backup vendor — or your team — the tough questions.
- What exactly is enforcing immutability? Is it through native APIs, or an external SaaS offering?
- Is it enforced by the storage layer or the software layer?
- Can a privileged user delete or modify backups?
- What’s the retention policy?
- When’s the last time you tested a full restore?
Because when ransomware strikes, it’s too late to figure out that your “immutable” backup wasn’t so immutable after all. Immutability is not a marketing feature. It’s a security foundation. And like any foundation, it only holds if it’s built correctly — from the ground up.
Don’t settle for checkbox resilience. Go deeper. Ask more. Protect better.
Making Immutability (Ridiculously) Easy with N2W
Setting up truly immutable backups and ensuring they truly are protecting your data can not only be complex, but costly. N2W changes that, as it’s designed to simplify protection and recovery and ensure maximum security with cost savings to boot.
Here are a few ways N2W helps strengthen your backup and recovery approach:
Affordable, Compliance-Ready Immutability
Protect both short- and long-term data with cost-effective, compliance-mode immutability across AWS EBS, S3, and Azure—real WORM storage, without the overhead.
Cross-Cloud Volume Restore
Easily back up AWS volumes and restore them in Azure. Ideal for improving data isolation, supporting compliance strategies, or building out cross-cloud resilience.
Time-Based Retention That Works for You
Set flexible retention schedules—whether it’s for a few days or several years. You’re in control of what stays and for how long.
Built-In Tamper-Proof Protection
Leverage API-level compliance mode to ensure backups can’t be deleted, even by root users. No third-party SaaS layers—just secure, built-in immutability.
Clear Monitoring & Reporting
Get full visibility into your backup posture with detailed reporting on what’s protected, locked, or needs attention.
