What happens if an attacker deletes your backups before encrypting your servers? For far too many organizations, that is not a hypothetical. It is the exact sequence that turns a bad day into a business-ending event. Backup immutability is the control that breaks that chain, and this checklist walks through what to verify, in what order, and where teams usually get it wrong.
What Backup Immutability Actually Means
Immutable backups cannot be altered or deleted by anyone, including administrators, for a set period. That is the whole point. A traditional backup that an admin account can delete is not a real defense against ransomware, because attackers routinely harvest admin credentials first.
The concept is not new. Storage vendors have sold WORM (write once, read many) systems for decades, largely to satisfy financial record-retention rules. What changed is the audience. Immutability moved from a compliance checkbox to a core security control, and frameworks now treat it that way. The NIST Cybersecurity Framework 2.0, released in February 2024, added a dedicated Recover function covering backup restoration and integrity, which makes recovery testing an explicit governance activity rather than an IT afterthought.
Immutability vs. Air Gaps vs. Versioning
These terms get mixed up constantly. They solve overlapping problems but are not interchangeable.
| Control | What it stops | Weakness |
|---|---|---|
| Immutable storage (WORM, object lock) | Deletion and modification during a retention window | Depends on correct policy configuration |
| Air gap (offline copy) | Almost all remote attacks | Slow to restore, easy to neglect |
| Versioning / snapshots | Overwrites and accidental changes | Can be deleted if the attacker controls the account |
| Encryption with separate keys | Data theft from stolen media | Useless if key management is sloppy |
A mature setup uses at least two of these together. Immutability alone, configured badly, is a false sense of security.
The Checklist: Ten Items to Verify
Work through these in order. Skipping ahead is the most common mistake, because retention policies built on a broken access model protect nothing.
1. Map Every Backup Copy and Who Can Delete It
List every repository, bucket, tape vault, and cloud account. For each one, write down who holds delete rights. If the answer includes a domain admin account used for daily work, flag it. Attackers target backup infrastructure first precisely because it is the recovery lifeline.
2. Enforce Immutability at the Storage Layer
Immutability must live below the backup software. If the backup application enforces retention but the underlying storage allows deletion, an attacker with application credentials can wipe everything. Look for object lock, WORM volumes, or tamper-evident appliances. AWS introduced S3 Object Lock in November 2018, and its compliance mode prevents deletion even by the root account until retention expires, which is the behavior you want to test for.
3. Set Retention Longer Than Your Realistic Recovery Window
Ask a blunt question: how long would it take to notice a breach, investigate it, and rebuild? Retention shorter than that window is decoration. Many teams settle on 30 to 90 days minimum for critical systems, but the number should come from your own incident timeline, not a vendor default.
4. Separate Credentials and Networks
The backup system should not share identity with production. Use a dedicated account, separate authentication, and where possible a separate network segment. NIST’s SP 800-209, Security Guidelines for Storage Infrastructure, treats immutability features like snapshots and WORM as controls against ransomware and insider deletion, and it stresses that these controls depend on sound access management around them.
5. Keep at Least One Copy Offline or Out of Band
The long-standing 3-2-1 rule (three copies, two media types, one offsite) is an industry heuristic rather than a formal standard, but it still holds. The newer 3-2-1-1-0 variant adds one immutable or offline copy and zero restore errors. Tape in a vault, a rotated drive, or a disconnected cloud account all count.
6. Encrypt Backups and Store Keys Separately
Encrypt at rest and in transit, and keep keys out of the backup system’s own credential store. If keys sit alongside the data, encryption protects against theft of the disk but not against an attacker with account access.
7. Monitor for Policy Drift
Immutability settings get disabled during troubleshooting and never turned back on. This is one of the most common real-world failures. Alert on any change to retention policy, lock configuration, or delete permissions, and review those alerts weekly.
8. Test Full Restores, Not File Retrieval Alone
Restoring a single document proves almost nothing. Run a full system restore into an isolated environment on a schedule. Record how long it took and whether the restored system actually booted and passed checks. CISA’s #StopRansomware Guide, a joint CISA and MS-ISAC product updated in May 2023, recommends maintaining offline, encrypted backups and testing restoration, which is the same advice from a government source.
9. Document the Recovery Runbook
Write down who declares an incident, who authorizes a restore, and how to reach the key holders at 3 a.m. A runbook nobody has read is not a runbook. Keep a printed copy, because your documentation server may be the thing that is encrypted.
10. Review Quarterly
Threats, staff, and infrastructure change. Put a quarterly review on the calendar with a named owner and a short written record of what was tested and what failed.
Where Teams Slip Up in Practice
A few failure patterns show up again and again when teams audit their own setups.
Immutability enabled on the wrong tier. Teams lock the archive tier and leave the fast-recovery tier mutable, then discover during an incident that the only usable copy was the unprotected one.
Retention set by default, not by design. A 14-day lock sounds fine until an investigation takes three weeks. By the time anyone notices the encryption, the immutable window has expired and the good copies are gone.
The “temporary” exception that never closed. Someone disables a lock to free space during a migration. Six months later it is still off. Policy drift is boring, which is exactly why it is dangerous.
Restore tests that never touch the real thing. Pulling a few files from the most recent snapshot is a backup check, not a recovery test. The gap between those two activities is where most surprises live.
Keys stored with the data. Convenient, and completely defeats the purpose.
For teams building out the hardware and storage side of this, practical buying guidance helps: see these picks for the best external hard drives for backup and these options for photo backup solutions if you also protect large personal media libraries. Home and small-office readers running critical systems should also look at the best home generators and solar generators for home backup power, because power loss during a restore is its own kind of outage. (Backup)
Compliance Drivers Worth Knowing
Even if no regulator oversees you, the rules explain why immutability features exist and what “good” looks like.
SEC Rule 17a-4(f) governs electronic record retention for broker-dealers and historically drove WORM adoption across the storage industry. Amendments adopted in 2022 (Release No. 34-97121) updated the audit-trail and WORM requirements, so verify current effective dates before relying on older guidance.
GDPR Article 32, in force since May 25, 2018, requires appropriate technical measures including the ability to restore availability and access to personal data in a timely manner after an incident. That is a legal obligation to be able to restore, not merely to hold a backup.
NIST SP 800-209 remains a useful technical reference for storage-level controls, and the NIST Cybersecurity Framework 2.0 gives you the governance vocabulary to justify the spend to leadership.
A Simple Scorecard
Score each item from 0 to 2 and total it. Anything under 14 out of 20 means the recovery plan has a hole someone could drive through.
| Area | 0 (missing) | 1 (partial) | 2 (verified) |
|---|---|---|---|
| Storage-layer immutability | None | Enabled on some tiers | All critical tiers locked |
| Credential separation | Shared admin | Separate account | Separate identity and network |
| Offline copy | None | Irregular | Scheduled and tested |
| Restore testing | Never | Annual | Quarterly, documented |
| Drift monitoring | None | Manual checks | Automated alerts |
The score matters less than the conversation it starts. Most teams discover at least one item they assumed was handled.
Practical Tips That Actually Work
Start with your most critical system, not your largest. Get one workload genuinely immutable and restorable, then replicate the pattern. Document the retention decision in writing with a date and an owner, because future-you will want to know why 45 days was chosen. Run the first full restore test during business hours so the right people are available, and expect it to take longer than planned. Finally, treat the immutability configuration as code where possible, so it can be reviewed, versioned, and restored like everything else.
If your team handles endpoints and mobile devices too, the same verification mindset applies elsewhere: it is worth knowing how to check whether an apk file is safe before sideloading anything, and how to check whether a link is safe before clicking. On the hardware side, checking GPU temperatures and learning how to check for malware on a Mac round out a basic hygiene routine that complements a solid backup strategy.
Conclusion
Backup immutability is not a product you buy and forget. It is a set of verified decisions: where the lock lives, who can turn it off, how long it holds, and whether anyone has actually restored from it recently. The checklist above is deliberately unglamorous, and that is the point. Attackers count on teams skipping the boring steps. Walk through all ten items, score yourself honestly, put the review on the calendar, and the next incident becomes a bad week instead of a final one.
Frequently Asked Questions
What is backup immutability in simple terms?
It means a backup copy cannot be changed or deleted for a set period, even by an administrator. The lock is enforced by the storage system itself, not by the backup software, so stolen credentials cannot override it.
Is immutable backup enough on its own?
No. Immutability protects copies from deletion during the retention window, but it does not guarantee the data inside is clean or that you can restore it. Pair it with an offline copy, separate credentials, encryption, and regular full restore tests.
How long should immutable retention be?
Long enough to cover discovery, investigation, and rebuild. Many teams choose 30 to 90 days for critical systems, but the right number comes from your own incident timeline. If retention expires before you notice a breach, the lock did nothing.
Can ransomware delete immutable backups?
Not during the retention window, assuming the lock is configured correctly at the storage layer and the attacker lacks the ability to change the policy. The realistic risk is a misconfigured or disabled lock, not the immutability feature failing.
How often should restore tests happen?
Quarterly full restores into an isolated environment are a reasonable baseline for critical systems, with lighter checks in between. Test the whole system rather than individual files alone, and record the time to recovery each run.
Does immutability help with compliance?
Yes, in several contexts. Financial record-retention rules have long required WORM storage, and data protection law requires the ability to restore personal data after an incident. Immutable backups make both obligations easier to evidence during an audit.
