The 3-2-1-1-0 Backup Rule Explained: What Each Number Requires and How to Prove It

The classic 3-2-1 backup rule was written for disk failure and site loss, and on its own it does not stop an attacker with backup admin rights from deleting every copy before encrypting production. The 3-2-1-1-0 rule adds two requirements that answer that threat: one copy that cannot be reached or altered, and zero errors when restores are verified. This guide explains what each number means, what counts as offline or immutable, how to apply the rule to virtual machines, databases, SaaS and identity systems, and how to show auditors and executives that it actually holds. It is for infrastructure, backup and security teams, and for anyone asked "is 3-2-1 enough for ransomware?". Architecture and hardening of the backup platform itself is covered in the Backup Security and Immutable Backup Guide.

Key takeaways

• 3-2-1 is about accidents. Three copies, two devices or media, one offsite protects against hardware failure and site loss; it does not require any copy to be offline, as the UK NCSC points out.
• The extra 1 is about attackers. One copy must be offline, air-gapped or immutable so that stolen admin credentials cannot delete or encrypt it.
• The 0 is about proof. Zero errors means restores are tested and verified, not that backup jobs reported success.
• Each number needs a test. Count copies per system, confirm the copies do not share an account or console, attempt a deletion of the protected copy with an admin account, and restore from it on a schedule.
• Identity decides whether the rule holds. If one credential can reach every copy, the rule is satisfied on paper and fails in practice.

What each number means

The UK National Cyber Security Centre describes the 3-2-1 rule as "at least 3 copies, on 2 devices, and 1 offsite". 3-2-1-1-0 is industry shorthand rather than a published standard: it keeps the first three numbers and adds one offline, air-gapped or immutable copy and zero errors in recovery verification. Treat each number as a requirement with an owner and a test.

The numbers are minimums. A system can have four copies on three platforms; what matters is that each property is present for every system in scope, and that the offline or immutable copy is the one you plan to restore from in a ransomware event.

Is 3-2-1 enough for ransomware?

Usually not. Modern ransomware operators look for recovery options before they encrypt. MITRE ATT&CK tracks this as T1490 Inhibit System Recovery, alongside T1486 Data Encrypted for Impact and T1485 Data Destruction. If the backup server is domain-joined, if the backup console uses the same directory as production, or if a cloud access key can delete both the data and its snapshots, every copy is inside the attacker's reach no matter how many there are or where they are stored.

The PocketOS database deletion is a compact example: an account-scoped API token was used to delete a production volume, and the volume-level backups went with it in the same call. The copies existed; they shared a control plane and a credential with production. That is what the extra 1 is designed to break.

Government guidance lines up with the extended rule. The CISA #StopRansomware Guide tells organisations to "maintain offline, encrypted backups of critical data" and to "regularly test the availability and integrity of backups in a disaster recovery scenario". The NCSC advises keeping at least one backup disconnected from live systems at all times. NIST IR 8374 Rev. 1, Ransomware Risk Management: A Cybersecurity Framework 2.0 Community Profile (final, June 2026), maps ransomware readiness onto CSF 2.0 outcomes including PR.DS-11, "Backups of data are created, protected, maintained, and tested".

The extra 1: offline, air-gapped or immutable

Three different mechanisms can satisfy the requirement. They protect in different ways and fail in different ways, so choose by what an attacker would need to defeat them.

The NCSC explains that cloud storage cannot be unplugged, so it has to be disconnected digitally: protect every account that can reach backups with strong authentication, make sure backup clients hold no valid credentials when storage is idle, and where possible allow only authorised clients to add data and reject connections while storage is idle. A client that can only create new data cannot overwrite existing backups. Those three layers are a practical test for any "logical air gap" claim. See the Cyber Recovery Vault Guide for vault design.

Immutability settings in the main cloud object stores

Cloud providers are listed alphabetically. Each offers WORM retention with a test mode and an enforced mode; the enforced mode is the one that counts for the extra 1.

Two points apply everywhere. First, object lock protects stored objects, not the account: whoever controls billing, the organisation root or the tenant can still cause harm, so the account that holds the immutable copy should be separate from production and governed by different administrators. Second, CISA notes that immutable storage should be used carefully because misconfiguration can be costly; test retention settings in the unlocked or governance mode, then switch. Provider-specific hardening is in the AWS Backup Security Guide and the Azure Backup and Recovery Services Vault Security Guide.

The 0: what verified restores mean

A green backup job tells you data was written. It does not tell you that the data is complete, uncorrupted, free of the attacker's tooling, or restorable inside your recovery time objective. NIST CSF 2.0 separates this into its own recovery outcome, RC.RP-03: "The integrity of backups and other restoration assets is verified before using them for restoration." Zero errors should cover four levels.

1. Integrity: checksums or the backup platform's verification jobs confirm that the stored data matches what was written. Run them on the immutable copy, not just the primary backup target.
2. Restorability: files, volumes and databases are restored to an isolated environment on a schedule. CIS Controls v8.1 Safeguard 11.5 asks for recovery testing on a sample of in-scope assets at least quarterly (IG2 and IG3).
3. Application recovery: the restored system boots, the database opens and passes its consistency check, and a business user confirms the data is usable. This is where missing dependencies show up: certificates, licence servers, DNS, identity providers.
4. Clean state: restore points are scanned for malware and known attacker persistence before they are trusted, and the last known clean point is identified. In a real incident the most recent backup may contain the attacker's foothold.

Record each test: system, recovery point, copy used, time taken, data checks, result and fixes. "Zero errors" is a claim about that record. The Backup and Recovery Testing Checklist gives a test plan structure.

Applying the rule to different workloads

The rule is easy to meet for file servers and hard to meet for systems where the backup is tied to the same platform as the data. Apply it per workload, not once for the estate.

Where identity fits

Every backup copy is protected by an identity: a backup service account, a cloud role, an access key, a vault administrator. If any one of them can delete all copies, the rule collapses to a single point of failure. Give the immutable or isolated copy its own administrators, its own identity provider or account boundary, phishing-resistant MFA for humans, and narrowly scoped, short-lived credentials for the machine identities that write to it. Writers should be able to add backups, not delete or change retention. Review these identities as tier 0. See the Backup Identity Isolation Guide.

Decision guidance by size

• Small organisation, mostly SaaS: production in the SaaS platform, one backup to a separate service with its own admin account and MFA, and one copy to immutable cloud storage with a locked retention policy. Test a mailbox, a site and a file restore each quarter. CIS Safeguards 11.1 to 11.4 are IG1, so this is the baseline, not an aspiration.
• Mid-sized, hybrid: local backup appliance for fast restores, replicated offsite, plus an immutable cloud copy in a separate account. Backup infrastructure not joined to the production domain. Quarterly application-level restore tests for tier 1 systems.
• Large or regulated: isolated recovery vault with its own identity domain, tape or equivalent offline media for the longest retention, immutable cloud copies, a clean room for restoring and scanning, and recovery exercises that include identity systems. See the Cloud Recovery and Clean Room Guide.

Choose retention on the immutable copy from your dwell-time assumption: if an intrusion could go unnoticed for weeks, a seven-day lock may only preserve infected restore points. Balance that against storage cost and any obligation to delete personal data on request.

Implementation: a phased approach

1. Scope and tier: list systems, owners, recovery time and recovery point objectives, and which tier each sits in. Include identity, DNS, backup infrastructure itself and IaC.
2. Gap check against the numbers: for each system, record copies, media, offsite location, protected copy and last verified restore. The gaps are the plan.
3. Separate the control plane: move the protected copy to a separate account, tenant or domain with its own administrators before turning on immutability.
4. Pilot immutability in test mode: use governance mode or unlocked policies on a pilot bucket or container, confirm jobs, retention and costs, then switch to compliance mode or lock the policy.
5. Prove the extra 1: with a privileged production account, try to delete a protected backup and to shorten its retention. Both should fail and raise an alert.
6. Prove the 0: schedule restore tests per tier, record results, fix failures and re-test.
7. Rollback and change: immutability cannot be rolled back once locked, so changes to retention go through change control with a second approver; misconfigured locks are corrected by adding new policies on new storage, not by removing old ones.

Detection and measurement

Alert on backup job deletions, retention or lock policy changes, attempts to disable versioning, new administrators on backup consoles and vault accounts, and bypass header use in governance mode. Forward these logs outside the backup platform. Track:

• Rule coverage: percentage of tier 1 systems that meet all five numbers.
• Protected copy coverage: percentage of in-scope systems with a current recovery point in immutable or offline storage.
• Restore test pass rate: successful application-level restores divided by tests run, per quarter.
• Time since last verified restore: per tier 1 system; anything over three months is a finding.
• Measured recovery time against objective: actual time to restore in tests compared with the recovery time objective.
• Shared credential count: identities that can delete or modify more than one backup copy; the target is zero.

Common failure patterns

• Snapshots counted as backups: snapshots on the same storage or account fail with it and are deleted with the same credentials.
• Same identity for every copy: one backup admin or one cloud key reaches the local, offsite and cloud copies, so the attacker needs one credential to remove all of them.
• Immutability left in test mode: governance mode or unlocked policies left in place for months, so anyone with the bypass permission can delete.
• Job success treated as verification: no one restores until the incident, when missing databases, expired encryption keys or absent catalogues appear.
• Retention shorter than dwell time: every immutable restore point already contains the attacker's foothold.
• Backup keys stored with the backups: encryption keys or the key management account are reachable from production, so data is intact but unreadable.

Framework mapping

CIS Control 11 detail is in the CIS Control 11 Data Recovery Guide.

Practitioner checklist

• Record copies, media, offsite location, protected copy and last verified restore for every tier 1 system.
• Stop counting same-platform snapshots as separate copies.
• Put the immutable or isolated copy in a separate account, tenant or domain with its own administrators.
• Run immutability in test mode on a pilot, then switch to compliance mode or a locked policy.
• Set retention on the protected copy longer than your realistic dwell time.
• Prove with a privileged production account that the protected copy cannot be deleted or its retention shortened.
• Restore tier 1 systems at application level at least quarterly and record the results.
• Scan restore points before trusting them and identify the last clean point in exercises.
• Include identity systems, IaC templates, golden images and the backup platform's own configuration.
• Alert on retention changes, backup deletions and new backup administrators, with logs held outside the platform.

Standards and references

• NCSC: Offline backups in an online world
• CISA: #StopRansomware Guide
• NIST: IR 8374 Rev. 1 Ransomware Risk Management, a CSF 2.0 Community Profile
• NIST: Cybersecurity Framework 2.0
• CIS: Control 11 Data Recovery
• AWS: Locking objects with Object Lock
• Google Cloud: Bucket Lock
• Microsoft Learn: Immutable storage for Azure Blob Storage

Related NHI Mgmt Group resources: Backup Security and Immutable Backup Guide · Backup Identity Isolation Guide · Backup and Recovery Testing Checklist · Cloud Ransomware Guide · Backup and Recovery Policy Template