The 3-2-1-1-0 Backup Rule Explained

The 3-2-1 rule predates cloud computing and ransomware as a named threat. It is widely attributed to photographer and author Peter Krogh, who set it out in the context of protecting irreplaceable digital photography from loss, and it was subsequently adopted broadly across general IT backup practice as a simple, memorable standard: three copies of data, on two different types of media, with one copy kept offsite.

The logic was originally about disaster and hardware failure rather than deliberate attack. A single copy can be lost to a failed drive. Two copies on the same medium can both fail to the same defect or the same local disaster. An offsite copy protects against the loss of an entire site to fire, flood or theft. As a baseline against accidental loss, the rule has held up for decades.

The extended rule keeps the original three digits and adds two more that address a threat model the original rule did not anticipate: an adversary who deliberately targets backup infrastructure.

The additional one addresses a specific, observed pattern in ransomware operations: attackers who gain a foothold now routinely search for and attack backup infrastructure before deploying the payload that encrypts production systems, precisely because a working backup removes their leverage. Guidance from CISA and the MS-ISAC and from NCSC UK both recommend keeping backups offline, or on a separate network segment that is not continuously reachable, for exactly this reason.

Offline, air-gapped and immutable are not interchangeable terms

These three terms are frequently used as if they meant the same thing. They do not, and the difference matters when deciding whether a given copy actually satisfies the rule.

Immutable backup

Data cannot be altered or deleted for a set period, enforced by policy on storage that remains network reachable.

Air-gapped

A general term for storage with no network path, which can be achieved physically or, less reliably, through strict logical isolation.

Offline

The storage medium has no active network connection while disconnected. This is a physical state, not a configuration setting.

A copy protected only by immutability settings, however well configured, is still one privileged account compromise, one misconfiguration, or one sufficiently patient attacker away from being at risk. The rule's added one is specifically written to require the stronger guarantee.

The zero refers to the number of errors an organisation should find when it actually restores from a backup copy. It is a deliberately blunt way of saying that a backup which has never been restored is not a proven backup, it is an assumption. Backup software reporting a job as successful confirms that data was written; it does not confirm that data can be read back, that it is complete, or that dependent systems can actually be brought back into a working state from it.

Each part of the rule has a distinct, observable way it commonly fails when organisations believe they are compliant but are not.

1. Three copies fails. when two of the three copies are actually snapshots or replicas of the same underlying storage system, sharing a single point of failure despite being counted separately.
2. Two media fails. when both media are different products from the same vendor sharing the same management software, so a single exploit or licensing failure affects both.
3. One offsite fails. when the offsite copy is in a different building on the same organisational network, sharing the same identity plane and therefore the same attacker access path.
4. One offline fails. when the offline copy is described as air-gapped but is in fact a logically isolated network segment that a determined attacker with enough time and lateral movement can still reach.
5. Zero errors fails. when test restores are skipped, scripted to only check that a file exists rather than that it is usable, or performed once at implementation and never repeated.

Verification is not a one-off activity. It is a recurring discipline that should be scheduled, resourced and documented in the same way as any other control.

The 3-2-1-1-0 rule is not itself a formal published standard, but each of its elements is reflected in established guidance. NIST SP 1800-11 sets out practical patterns for maintaining and verifying recoverable data copies after a destructive event. The recovery function of the NIST Cybersecurity Framework 2.0 expects organisations to test recovery plans and capability, not merely to hold copies of data.

NCSC UK's guidance on offline backups and its ransomware mitigation guidance both recommend an offline or logically separated copy and regular restore testing as core defensive measures, and CISA's Ransomware Guide states the same expectation for US organisations, reinforcing that the additions to the classic 3-2-1 rule reflect converging guidance rather than a single vendor's marketing framework.

Cyber insurance renewal questionnaires and audit frameworks increasingly ask specific questions that a written backup policy alone does not answer. Evidence needs to be dated, specific and reproducible.

The strongest evidence combines system generated logs, such as a tamper evident connection log for an offline copy, with human documented test restore reports. Insurers and auditors are increasingly asking for the connection log specifically, because a written policy stating that a copy is offline is not proof that it is.

• Confirm each of the three copies sits on genuinely independent underlying storage.
• Confirm the two media types do not share a single management plane or vendor vulnerability.
• Confirm the offsite copy has independent power, network and physical access controls.
• Confirm the offline copy has no active network interface while disconnected, not merely a locked configuration.
• Schedule and document test restores at a frequency aligned with your recovery time objective.
• Keep dated evidence, including connection logs and restore reports, ready for audit or insurance renewal.

The rule is a resilience baseline, not a complete recovery strategy. It says nothing about recovery time objectives, the order in which systems should be restored, dependency mapping between applications, or the staffing and runbooks needed to execute a recovery under pressure. Organisations that satisfy every digit of 3-2-1-1-0 can still fail to recover quickly if they have not separately planned and rehearsed the operational sequence of a real incident.

The rule also does not specify how quickly the offline copy can be brought back online, which is a legitimate design trade-off between security and recovery speed. An organisation should decide that trade-off deliberately, based on its recovery time objective, rather than let it be an accidental consequence of how the offline copy happens to be implemented.

Firevault Offline Secure Storage® is designed specifically to satisfy the offline one in the 3-2-1-1-0 rule with a physical, Layer 1 disconnection rather than a logical or policy based one. The storage hardware has no network interface enabled while offline, so there is no IP address, no listening service and no credential path available to an attacker during that period.

Connection windows are scheduled and identity verified through Firevault Control, an out-of-band management plane, and every connection and disconnection is recorded in a tamper evident log. That log, combined with a documented test restore process on the organisation's own backup platform, is the kind of paired evidence auditors and insurers are increasingly asking for against the offline and zero-errors requirements of the rule. Firevault does not replace the production or immutable cloud copies an organisation already relies on; it is designed to be the offline copy those approaches cannot themselves provide.

• CISA and MS-ISAC, Ransomware Guide (StopRansomware.gov)

  Recommends maintaining offline, encrypted backups and regularly testing them, reflecting the offline and verification additions to the classic 3-2-1 rule.

• NIST SP 1800-11, Data Integrity: Recovering from Ransomware and Other Destructive Events

  Practice guide on maintaining recoverable, verified backup copies to recover data integrity after a destructive event.

• NIST Cybersecurity Framework 2.0, Recover function

  Sets expectations for backup, restoration and verification as part of an organisation's recovery capability.

• NCSC UK, Offline backups in an online world

  UK guidance explaining why an offline copy defeats a class of attacker that immutable-but-connected backup cannot.

• NCSC UK, Mitigating malware and ransomware attacks

  Recommends keeping backups offline or in a separate network, and regularly testing that they can be restored.

Related Firevault guides