The 3-2-1 Rule, RTO/RPO + Immutable Backups

Encryption protects data from being read. Backups protect data from being lost — to a fat-fingered delete, a failed disk, a bad deploy, or, increasingly, ransomware that encrypts your production data and demands payment for the key. When a framework says "data is backed up and recoverable," it is testing whether you can get your data back, within a defined time, after the worst day. That is a control with sharp, measurable edges, and it is one auditors probe hard because so many organizations have backups and discover, mid-incident, that they cannot actually restore from them.

This lesson covers the backbone of a backup program: the 3-2-1 rule, the RTO/RPO objectives that define "recoverable," and immutability — the property that makes backups survive an attacker who is specifically trying to destroy them.

The 3-2-1 rule

The 3-2-1 rule is the durable baseline for backup design. It says:

• 3 copies of your data (the production copy plus two backups),
• on 2 different types of media or storage, so a single technology failure can't take all copies,
• with 1 copy off-site (a different location/region/account), so a localized disaster — fire, flood, a compromised cloud account — doesn't destroy everything.

In the cloud the rule translates cleanly: the production data, a backup in the same account/region, and a copy replicated to a different region and ideally a different account with separate credentials. Modern guidance extends it to 3-2-1-1-0: add 1 immutable or air-gapped copy and 0 errors on a verified restore test. The extra digits exist because ransomware changed the threat model — it's no longer enough to have copies; you need a copy the attacker cannot reach or alter, and proof that the copy actually restores.

RTO and RPO: defining "recoverable"

"We have backups" is meaningless without two numbers that define what recovery means. These are the vocabulary of every backup and disaster-recovery conversation, and you must keep them straight:

• RPO — Recovery Point Objective: how much data you can afford to lose, measured in time. An RPO of 1 hour means backups are frequent enough that, after an incident, you lose at most the last hour of data. RPO drives backup frequency: a 1-hour RPO needs at least hourly backups (or continuous replication); a 24-hour RPO allows nightly.
• RTO — Recovery Time Objective: how long you can afford to be down, measured in time. An RTO of 4 hours means you must be fully restored and operational within 4 hours of the incident. RTO drives restore architecture: a 4-hour RTO for a 100 TB dataset is a very different (and more expensive) design than a 72-hour RTO.

The two are independent and both matter. A system can have a great RPO (tiny data loss) but a terrible RTO (takes three days to actually restore), or vice versa. They are set by the business based on how critical the data is — a payments database might be RPO 5 minutes / RTO 1 hour, while an internal analytics warehouse might be RPO 24 hours / RTO 72 hours.

Immutability and air-gapping: surviving an attacker

Traditional backups assume accidents. Ransomware assumes an adversary — one who, once inside, specifically hunts for and destroys backups so you have no choice but to pay. Modern attackers delete snapshots, encrypt backup repositories, and target backup admin credentials. A backup an attacker can delete is not a ransomware control.

Two properties defend against this:

• Immutability (WORM — write once, read many): the backup, once written, cannot be modified or deleted until a retention period expires — not even by an administrator. In the cloud this is S3 Object Lock, GCS Bucket Lock / retention policies, and Azure immutable blob storage. Even an attacker with full admin and the root credentials cannot delete a locked backup before its retention window ends.
• Air-gapping / isolation: the backup copy lives somewhere the production environment cannot directly reach — a separate cloud account with independent credentials, an isolated backup vault, or offline media. The logic: if the blast radius of a production compromise doesn't include the backups, the backups survive.

The strongest designs combine them: an immutable copy in an isolated account, so the data is both unreachable and undeletable. This is what lets you say, credibly, "even if our entire production environment is ransomwared, we can restore."

Restore testing: the control nobody runs until it's too late

The single most common backup failure is not the absence of backups — it's backups that were never restored. Backups silently corrupt, miss critical data, or take far longer to restore than anyone assumed. A backup you have never restored is a hypothesis, not a control. The discipline that turns it into a control is regular, documented restore testing: actually restoring from backup on a schedule, verifying the data is complete and correct, and measuring whether the restore meets the RTO. The "0" in 3-2-1-1-0 is this — zero errors on a verified restore.

For a GRC Engineer, restore-test evidence is gold: a dated record showing "we restored dataset X on date Y, it completed in Z hours (within the 4-hour RTO), and the data validated" is exactly what proves the backup control operates rather than merely exists.

Mapping to frameworks

Backup and recovery controls appear across every major framework, and the same evidence is reusable:

• SOC 2 — Availability criteria (A1.2, A1.3) covering backup, recovery, and environmental protections; CC-series for the integrity of the process.
• ISO 27001:2022 — Annex A 8.13 (information backup) and 8.14 (redundancy of information processing facilities), plus the business-continuity controls in 5.29/5.30.
• NIST CSF / 800-53 — the Recover function; CP-9 (system backup) and CP-10 (recovery and reconstitution).

The evidence package is consistent: the backup policy with RTO/RPO targets, the backup configuration (frequency, copies, immutability, locations), and — most importantly — the restore-test records proving recovery works within objectives.

What to carry forward

A real backup program is 3-2-1 (extended to 3-2-1-1-0 for the ransomware era), with RPO setting backup frequency and RTO setting restore architecture, at least one immutable and isolated copy that an attacker cannot delete, and restore testing that proves it all works within objectives. "We have backups" is not the control; "we can restore, on time, after the worst day, and here's the test that proves it" is.

In the next lesson you'll watch a ransomware tabletop exercise walk through an incident in real time — and see exactly where backup programs that look fine on paper come apart under pressure.