TL;DR: Ransomware doesn’t stop at your production systems — it goes after your backups next, and 89 percent of organizations have already had a backup repository targeted by an attacker. An immutable backup closes that specific gap: data is written once, locked for a set retention period, and cannot be altered, encrypted, or deleted by anyone, including an attacker holding valid administrative credentials. This matters more than ever in 2026, when 56 percent of ransomware attacks still succeed in encrypting data and only 28 percent of victims recover all of it afterward. This post explains how immutability actually works in data protection, how it differs from an air-gapped copy, and what to check before you assume your own backups qualify.
Ransomware attackers now assume a competent target has backups, so they target the backups first. Once an attacker holds administrative credentials, a standard backup is just another file they can encrypt, alter, or delete before the ransom note appears — and this is not a hypothetical: 89 percent of organizations have had a backup repository directly targeted in an attack.
The reason this works is that most backup storage is mutable by default — writable and deletable by anyone with the right access, the same access an attacker has already compromised to reach the rest of the network. A backup that an administrator can change is a backup that whoever is impersonating one can change too.
Immutable backup storage removes that access path entirely. Once written, the data is locked for a defined retention period in a write-once, read-many (WORM) state — unable to be changed, not just harder to reach. ThinkOn Immutable Backup and Archive applies that lock by default, so the retention period is set at onboarding rather than left to be configured, or forgotten, later.
Glossary
Immutable backup: A backup copy that cannot be modified, encrypted, or deleted for a defined retention period, even by someone holding valid administrative credentials.
WORM (Write Once, Read Many): The storage mode that makes immutability possible: data can be written once and only read afterward, never altered or erased, until the retention period expires.
Object lock: The mechanism cloud object storage (including S3-compatible platforms) uses to enforce WORM behavior on a per-object or per-bucket basis.
Retention period: The length of time a backup stays locked under immutability before it can be deleted or overwritten — set once and, on most platforms, difficult or impossible to shorten early.
Air-gapped backup: A backup copy with no continuous network connection to production systems, so a compromised environment has no network path to reach it, whether or not it is also immutable.
Backup repository: The storage location where backup data actually lives — the specific target ransomware attackers look for once they are inside a network.
Hardened repository: A backup repository, commonly Linux-based, configured with restricted access and its own immutability controls, separate from the general-purpose storage the rest of the environment uses.
3-2-1-1-0 rule: An industry backup standard: three copies of data, on two different media, one copy off-site, one copy offline, air-gapped, or immutable, and zero errors confirmed through recovery testing.
What are immutable backups?
An immutable backup is a backup copy that cannot be altered, encrypted, or deleted for a set retention period, even by an administrator.
Immutability is a storage property, not a separate backup product. It can be applied to backups already being taken — on object storage through object lock, on a hardened Linux repository through file-system-level controls, or through a managed service that applies the lock by default. Whatever the mechanism, the guarantee is the same: for the length of the retention period, the data cannot be changed, no matter who, or what, tries.
How does immutable backup storage actually work?
Immutable storage writes data once, locks it under a retention timer, and rejects every delete or overwrite request until that timer expires.
When a backup lands on immutable storage, the platform attaches a retention flag to that data before it is ever exposed to normal file operations. Any attempt to modify or delete the object — from a script, an administrator console, or an attacker’s command line — is rejected at the storage layer itself, not by a permissions check that a compromised credential could bypass. The retention timer, not a login, is what is actually being enforced.
Are backups on hyperscale cloud platforms immutable by default?
No. Hyperscale cloud backups are typically mutable by default; immutability is an object-lock setting the customer has to configure and maintain.
Major cloud platforms support immutability, but almost none of them ship with it switched on. Object lock and similar retention settings have to be enabled per bucket or per policy, and a setting nobody enabled protects nothing. Before assuming any backup — cloud, on-premises, or managed — is immutable, confirm the following:
- Is immutability actually enabled on this specific repository, not just available as an option?
- What is the configured retention period, and who has the access to shorten it?
- Does the immutability lock survive a compromised administrator account, or only a standard user account?
- Has anyone actually tested that a delete request fails — not just read the settings page?
What’s the difference between an immutable backup and an air-gapped backup?
Immutability locks data against changes; air-gapping removes the network path to it. The strongest protection uses both together.
The two terms get used interchangeably, but they solve different problems. An immutable backup can still sit on the same network as production systems — it is protected because it cannot be altered, not because it cannot be reached. An air-gapped backup is protected because there is no live network connection to reach it at all, whether or not it is also immutable. A backup that is both immutable and air-gapped removes both problems at once, which is why the 3-2-1-1-0 rule calls for a copy that is offline, air-gapped, or immutable, rather than treating one guarantee as a stand-in for the other.
How long should an immutable backup’s retention period be?
Long enough to cover realistic attack-detection time, typically 30 to 90 days, balanced against storage cost.
Most ransomware isn’t detected the moment it lands — dwell time between initial access and discovery can run to weeks. A retention period shorter than that window can lock in a backup that is already compromised, or expire the clean restore point before anyone knows they need it. Longer retention costs more to store and makes the immutability commitment harder to walk back if the policy needs to change, so the period is worth setting deliberately rather than accepting a platform default.
Why do compliance frameworks recommend immutable backups?
Ransomware guidance from agencies such as CISA specifically recommends offline, unalterable backup copies as a primary defense.
The U.S. Cybersecurity and Infrastructure Security Agency’s Stop Ransomware Guide calls for maintaining offline, encrypted backups of critical data as one of the highest-priority ransomware mitigations, and immutability is the mechanism that makes that guidance practical to sustain — an offline copy that anyone can still edit or delete once reconnected is only offline part of the time. Regulatory frameworks that require demonstrable, tamper-proof data retention, such as audit trails under HIPAA and GDPR, rely on the same underlying property: a record that provably has not been altered since it was written.
How do the common approaches to immutability compare?
Most approaches require the customer to configure and maintain immutability themselves; a managed implementation applies the lock by default.
The table below compares the most common ways organizations end up with, or without, immutable backup — from doing nothing extra to a fully managed implementation.
| Approach | Can an attacker alter or delete it? | Retention control | Compliance / audit fit | Setup & management |
| Hyperscale cloud default backup | Yes — writable unless object lock is separately enabled | None by default | Weak unless configured | Customer configures and maintains |
| Traditional on-premises backup | Yes, with valid admin credentials | None | Weak — no tamper-proof trail | Simple, but no ransomware safeguard |
| Customer-configured object lock | No, within the lock window | Customer sets and maintains | Moderate, configuration-dependent | Customer owns setup and ongoing upkeep |
| Air-gapped offline copy only | No — no live network path | Manual, human-dependent | Strong for audits, weak for fast recovery | High manual overhead |
| Self-hosted hardened repository | No, within retention period | Customer sets, tied to in-house admin | Moderate | Requires dedicated Linux/storage expertise |
| Managed immutable backup and archive (ThinkOn) | No, locked for the full retention period by default | Included at onboarding | Strong — WORM-backed, audit-ready by default | Included — no in-house build required |
Lock down your backup layer
Explore ThinkOn Immutable Backup and Archive for a managed implementation where the retention lock is set at onboarding, not left for someone to configure later.
Key figures at a glance
89%: organizations that have had a backup repository directly targeted by attackers — Veeam, 2025 Ransomware Trends and Proactive Strategies
56%: ransomware attacks that succeeded in encrypting data in 2026, up from 50% in 2025 — Sophos, State of Ransomware 2026
28%: of ransomware victims who recovered all of their affected data in 2026 (72% recovered on average) — Veeam, Data Trust and Resilience Report 2026
Frequently asked questions
What is an immutable backup?
An immutable backup is a copy of data that cannot be modified, encrypted, or deleted for a set retention period, even by someone with administrative access.
Is an immutable backup the same as an air-gapped backup?
No. Immutability prevents changes to the data; air-gapping removes the network connection to it. They are complementary, not interchangeable.
Does standard cloud backup already include immutability?
Not by default. Most cloud backup is fully writable and deletable unless object lock or an equivalent retention setting is specifically enabled and configured.
