1. Origin and structural limitations of the 3-2-1 model.

The 3-2-1 rule arose in a predominantly accidental risk model context:

• hardware failure,
• human errors,
• Local events (fire, flood, blackout).

The model implicitly assumed:

• Uncoordinated threats,
• Absence of attackers with persistence,
• Separate but trusted backup systems.

From a technical point of view, the 3-2-1 ensured:

• Data redundancy,
• diversification of media,
• Protection from site-specific events.

What it did not (and could not) cover:

• Attacks with administrative privileges,
• Impairment of identities,
• Lateral movements and “living off the land” attacks,
• Coordinated deletion or encryption of backups.

2. The new threat model: destructive attacks and systemic compromise

In the current threat landscape, backups have become primary targets.
Attackers no longer aim only at encrypting production data, but at:

• Delete backup repositories,
• Bribe catalogs,
• Encrypt snapshots and secondary copies,
• Alter retention and policy,
• Sabotage restoration mechanisms.

From a technical-operational point of view, this means:

• network reachability becomes a vulnerability,
• shared credentials represent a single point of failure,
• logical separation alone is not enough.

A compromised backup is, in fact, equivalent to a nonexistent backup.

3. From backup to recovery assurance

The key shift is not technological, but conceptual:
From backup as an asset to backup as a capability.

In BCM terms:

• it doesn’t matter how many copies exist,
• counts whether and how they can be restored within the defined RTO/RPOs,
• counts the probability of successful restoration under adverse conditions.

This introduces the concept of Recovery Assurance, which requires:

• isolation,
• verifiability,
• testability,
• governance.

4. Technical analysis of rule 3-2-2-1-1-0

The 3-2-2-1-1-0 rule is not a mnemonic formula, but a risk control framework.

3 copies of the data

Minimal redundancy to manage:

• Writing errors,
• silent corruption,
• failure during backup or restore.

2 different supports

Reducing the risk of:

• systemic bugs,
• firmware failure,
• Common platform vulnerabilities.

Examples:

• disk + object storage,
• NAS + tape,
• on-prem + cloud.

2 truly separate copies

Element often underestimated.

Separation must be:

• physical (different sites),
• logic (account, tenancy, subscription),
• administrative (identity and separate roles).

A logic-only separation within the same security domain is insufficient against a persistent attacker.

1 off-site copy

Protection from:

• Local destructive events,
• environmental accidents,
• Prolonged unavailability of the primary site.

From a BCM perspective, this copy is essential for disaster recovery.

1 isolated or immutable copy

It is the real paradigm shift.

Typical solutions:

• air-gapped (physical or logical),
• immutable storage (WORM, object lock),
• backup with non-editable retention,
• Complete separation of credentials.

Key feature:

even with compromised administrative privileges, the copy cannot be altered or deleted.

This copy represents the last line of defense against destructive cyber events.

0 errors in recovery tests

The most stringent requirement.

Meaning:

• Restore automated and periodic testing,
• Data integrity verification,
• Real measurement of RTO and RPO,
• tests even in degraded or compromised scenarios.

A backup that has never been tested is an assumption, not a control.

5. Integration with BCM and BIA

From the perspective of Business Continuity Management:

• the backup strategy must be derived from the Business Impact Analysis,
• data should be classified according to the criticality of the processes,
• RTO/RPO cannot be defined by IT on its own.

Backup becomes a continuity measure, not a generic infrastructure service.

This implies:

• Data mapping ↔ critical processes,
• Differentiation of backup policies,
• Alignment with crisis and incident response plans.

6. Consistency with operational resilience and regulatory requirements.

The 3-2-2-1-1-0 framework is fully consistent with the principles demanded by modern operational resilience requirements:

• ability to withstand extreme but plausible events,
• Demonstrable resilience,
• Objective testing evidence,
• Single point of failure reduction.

It is not required “to have backups,” but to:

• Restoring critical functions,
• Within defined time frames,
• even in the presence of destructive attacks.

7. Technical conclusion

In a modern context:

• backup is no longer an IT function,
• Is an operational resilience capability.

Without isolation, real separation, and rigorous testing,
the presence of backup does not reduce the risk of serious outage.

The operational questions to be asked

• What is the maximum level of compromise our backups can withstand?
• Is there at least one copy that cannot be altered even with identity compromise?
• Do the restore tests really measure the claimed RTO/RPO?
• Is the backup strategy designed on critical processes or infrastructure?

Because, ultimately, resilience is not an architectural statement, but a capability tested under stress

---