Immutable backup: why it is non-negotiable under NIS2 in 2026

What immutability means technically

Immutable backup means a backup, once written, cannot be modified or deleted for a defined retention period, not even by privileged accounts or the backup admin themselves.

Three common technical implementations. WORM (Write Once Read Many) at object-storage level, e.g. S3 Object Lock in compliance mode, Azure Blob Immutability Policy, Google Cloud Storage Bucket Lock. Hardware immutability via tape or object-based appliances (Veeam Hardened Repository, Dell PowerProtect Cyber Recovery). True air-gap solutions where the storage is physically connected only during the backup window.

Soft immutability (a delete lock that admins can override) is not enough. If the backup admin can delete the storage through credentials, the attacker can too.

Why cloud backup alone is not enough

Many organisations treat cloud backup as sufficient because the cloud feels safe. It is not. A Microsoft 365 or Google Workspace world with the backup in the same identity trust zone has no real air gap.

Example: ransomware compromises a Domain Admin or Global Admin. The attacker can change backup configurations, set retention to zero, delete snapshots. Cloud backup without object-storage-level immutability is lost.

Cloud backup becomes strong when immutability is enabled at object-storage level and the customer holds the keys (BYOK), not the provider.

The 3-2-1-1-0 architecture

An extension of the classical 3-2-1 rule. Three copies of the data, on two different media, one offsite, one offline or immutable, zero errors in the regular recovery test.

Concrete: production database, snapshot in a second region, backup on object storage with WORM, plus regular recovery testing. The zero stands for zero errors in the test, i.e. tested backup not just backup.

Insurers and audits broadly accept this architecture. Anything less risks an audit finding under NIS2 Art. 21 (c).

Typical audit failures

Backups are taken but never restored. NIS2 requires regular effectiveness testing. No restore logs, no effective backup.

Backup kept in the same identity domain. Compromise of a domain admin encrypts both production and backup.

Retention too short. If ransomware is dormant for three months, 30-day retention is useless. 90-180 days of immutable retention is state of the art for critical data.

Key custody unclear. If the provider holds the key, a US CLOUD Act order can compel backup access without the organisation knowing.

Pragmatic plan

1. Inventory: which workloads, which retention, which storage tier, which encryption.

2. Classification: critical (RTO < 4h, RPO < 1h), important, supporting. Per class an architecture.

3. Architecture decision: 3-2-1-1-0 as target, gap analysis, quick wins (WORM on existing S3) and medium-term investments (Hardened Repository or PowerProtect Cyber Recovery).

4. Recovery testing plan: quarterly restore tests for critical applications, annual end-to-end DR test.

5. Decision memo: document the vendor choice with weighted criteria, dealbreakers (immutability, key custody, EU hosting), stakeholder alignment, residual risks. The result is an audit-defensible backup concept.