Immutable Backups and the 3-2-1 Rule: The First Layer of Cyber Resilience

Sooner or later the board asks a simple question. When something breaks, can we come back? It might be ransomware, a bad deployment or an AI agent that deletes the wrong thing.

Most teams answer with the two controls they trust most. We keep immutable backups, and we follow the 3-2-1 rule for where our copies live.

Both are good answers, and both belong in a recovery plan. But they cover one part of a bigger question, and the numbers show where that part ends.

In the Veeam Data Trust and Resilience Report 2026, 90% of organizations said they were confident they could recover from a cyber incident. Only 28% of ransomware victims got all of their data back.

Confidence usually comes from the backup plan itself. Results depend on everything that plan assumes will still be in place on the day you need it.

What is the 3-2-1 backup rule?

The 3-2-1 backup rule says to keep three copies of important data, on two different types of storage, with one copy stored off-site. CISA's backup guidance uses the same definition, and it adds offline copies and regular restore tests.

The rule was written for tapes and disks, and it still works in the cloud. "Two types of storage" now means copies that share no single point of failure, such as a different storage class or service. "Off-site" means a separate account and a separate region, so one stolen login or one regional outage cannot reach every copy.

So 3-2-1 tells you where your copies live. Whether anyone can change or delete them is a separate setting.

What is an immutable backup?

An immutable backup is a copy that cannot be changed or deleted until its retention period ends. Once written, it cannot be encrypted, overwritten or cut short, by an attacker, a buggy script or a tired engineer at 2 a.m.

Most platforms do this with write-once, read-many (WORM) storage or an object lock. AWS S3 Object Lock shows why the settings matter. In governance mode, users with special permissions can still remove the lock. In compliance mode, no user can remove it or shorten the retention period, including the root account.

For a backup facing an attacker with admin credentials, the mode decides whether the copy survives.

Immutability is often paired with an air gap, and each does its own job. Immutability stops a copy from being changed. An air gap separates the copy from the network and credentials production uses, so an attacker inside production cannot reach it at all.

Why backups get destroyed, on purpose and by accident

Ransomware crews know a working backup is the victim's best reason not to pay. So they plan for it.

Mandiant's M-Trends 2026 report describes ransomware operators who target identity services, virtualization management planes and backup infrastructure. In one case, attackers compromised backup management servers, pulled credentials from their configuration databases and wiped millions of backup objects from cloud storage.

Gambit's threat research saw the same pattern in the Ababil of Minab campaign, where an Iran-linked crew destroyed IT systems, backups and recovery capability at a subset of its victims.

Not every loss is deliberate. In an ongoing campaign against online retailers, our researchers watched an AI agent clean up after stealing card data. Its cleanup dropped 180 database tables whose names matched "ZQ" or "Backup", including backup tables the victim's own administrators had made. The backups were collateral damage.

And backups now carry more of the recovery than ever. According to the Sophos State of Ransomware 2026, two-thirds of organizations whose data was encrypted recovered it from backups, up 12 percentage points in a year.

The permission trap

This gap is easy to miss, because the backups look protected. 

An infrastructure team locks down its backups with access controls. Nobody on the team has permission to delete a backup, so the backups look safe, and for daily operations they are.

But permissions belong to whoever controls the admin account. The administrator who removed the delete permission can add it back, and so can an attacker or a runaway automation using that account. Taking over admin accounts is exactly what the Mandiant report describes.

Access control protects well against everyday mistakes. An attacker, or an agent, holding your own credentials is a different kind of user. A compliance-mode lock does not care who is asking, which is why "we restricted access" and "we locked the copy" lead to very different mornings.

From 3-2-1 to 3-2-1-1-0

So the industry updated the rule. The 3-2-1-1-0 version adds one copy that is immutable or offline, and zero errors when backups are checked by actually restoring them.

Zero errors matters as much as the extra copy. The NIST Cybersecurity Framework 2.0 captures it in control PR.DS-11, which says backups of data are created, protected, maintained and tested. CISA asks teams to test restores both fully and partially.

A verified restore proves the data comes back. It does not prove the business does.

Backups are one layer of three

For a business to come back, three layers have to return together. The data, the infrastructure it runs on and the application that serves customers.

The 3-2-1-1-0 rule protects the first layer. Encryption keys, identities, network paths, DNS records and load balancers usually sit outside the backup. When one of them has changed or disappeared, the data comes back with nowhere to run.

In the CrowdStrike 2025 State of Ransomware Survey, nearly 4 in 10 victims could not fully restore the data they lost. Veeam's 2026 report found that organizations recovered 72% of affected data on average.

Our researcher Naama Etzion walked through the most common failures in Congrats on the Backup! Now, where's the App?. For the cloud side of the same problem, read Cloud Disaster Recovery vs. Ransomware.

Five questions to ask about your backup posture

Take these to your infrastructure team or your backup provider.

1. Which critical backups sit under a compliance-mode lock, and which rely on permissions alone?
2. Who can shorten a retention period, and does anyone get alerted when it happens?
3. Does each tier-one application have at least one copy that meets 3-2-1-1-0?
4. When did we last restore a full application, beyond a single volume or database?
5. What has changed since that restore, and did any change touch what the application depends on?

The fifth question is the hardest to answer by hand. Cloud estates change hundreds of times a day, so last quarter's successful restore was tested against an environment that no longer exists.

Where Resiliency Posture Management fits

Backup platforms do the data layer well. Resiliency Posture Management adds the view across all three layers.

Resiliency Posture Management maps each business application to what it depends on across cloud, backups, infrastructure as code and on-prem hypervisors. Then it checks continuously whether the conditions recovery depends on are met, including backup coverage, real immutability, configuration and the dependencies outside the backup.

Your team still runs the recovery, and the goal is a minimum viable business that stays continuously recoverable, with gaps found on a normal Tuesday instead of in the middle of an incident.
‍

See where your own recovery conditions stand. Book your Resilience Assessment.