Immutable backup 3-2-1-1-0: definition and principles

An immutable backup is a copy that cannot be modified or deleted for a defined period, including when ordinary administrative accounts have been compromised.

Purchase, logistics and personal use policy needed.

The Centre for Cybersecurity Belgium CCB updated its recommendations on 14 January 2026. It emphasises immutability designed in from the outset, layered protection, environment isolation, sufficiently long retention periods and rehearsed recoveries. These are resilience principles, not an endorsement of any specific product.

Why an attacker targets backups first

A mature ransomware operation reduces the victim’s negotiating position by deleting or disabling recovery paths before encrypting systems.

CCB’s technical report on Qilin, published on 17 July 2026, describes in particular the deletion of Volume Shadow Copies, the disabling of restore points and the deletion of tape backups or scheduled tasks. The example shows why a green status indicator in the console is not sufficient evidence: the same console can become a target.

The simplest attack paths are often administrative. A domain account used on the backup server, a secret stored in the same vault as production, a domain-joined NAS or a bucket accessible through the same cloud identity create a shared dependency. The attacker does not need to break the backup algorithm; they only need to obtain permission to delete.

How to interpret 3-2-1-1-0 without turning it into a slogan

The 3-2-1-1-0 rule is a design aid: it is neither Belgian law, a certification nor a guarantee of recovery.

Purchase, logistics and personal use policy needed.

Veeam popularised this extension of the 3-2-1 rule and explains the role of the second 1 and the 0 in its documentation on 3-2-1-1-0Purchase, logistics and personal use policy needed.

What needs to be protected in a hybrid organisation?

4. Company-owned device

Start with essential folders and applications: ERP, business software, shared files, databases, virtual machines, network configurations, specialist workstations and SaaS data. For Microsoft 365, distinguish Exchange, OneDrive, SharePoint, Teams and the identities required to administer recovery. For a NAS, identify shares, snapshots, internal applications and encryption keys.

Each workload should have an owner, a criticality level, an RPO — the maximum amount of data the business is willing to lose — and an RTO — the target time for restoring service. A shared mailbox may tolerate several hours of data loss; a production database may require a tighter target. These values should come from the business rather than from a software default setting.

The GVISION page dedicated to cloud and local backups presents the available protection components. This guide adds the immutable architecture perspective: it helps determine how to separate copies and how to prove that they remain recoverable.

Purchase, logistics and personal use policy needed.

No method is superior in every situation: the right choice balances resistance to deletion, recovery speed, operations and misconfiguration risk.

A realistic architecture for servers, NAS, workstations and Microsoft 365

A practical architecture combines fast local recovery with a secondary isolated copy and an independent recovery procedure.

For servers or virtual machines, a local repository reduces transfer time during routine recovery. A copy job then sends recovery points to a hardened repository or immutable off-site object storage. The production server should not have permissions to delete this secondary copy. Backup accounts should not be used for day-to-day operations.

For a NAS, local snapshots can speed up recovery after deletion, but they remain attached to the same device. Add a copy to a separate platform, with separate identities and retention policies. For mobile workstations, prioritise genuinely local data and verify that the device can complete the backup despite periods without network connectivity.

Retention, privileges and keys: the irreversible decisions

The immutability period must be long enough to exceed the plausible detection window, without unnecessarily locking data beyond what is required.

An attack can remain silent before encryption. If immutable retention is shorter than this period, the latest healthy recovery points may expire. Conversely, excessive retention increases consumed capacity, future transfer costs and exposure of personal data that is no longer needed. Align operational windows, retention obligations and deletion policies.

In Amazon S3, Object Lock distinguishes between Governance and Compliance modes. Governance mode can be bypassed by identities with a special permission; in Compliance mode, a protected version cannot be overwritten or deleted, even by the root user, before its expiry date. This level requires careful planning and testing.

Azure Blob provides time-based WORM policies and legal holds. It Microsoft documentation also distinguishes between locked and unlocked policies and recommends testing before locking. Keep keys, emergency accounts and procedures in a separate location, with controlled and verified access.

How to prove that recovery will work

The zero in 3-2-1-1-0 does not mean the absence of an overnight alert: it means verified, documented recovery that meets the business objective.

An integrity check verifies that a backup file is not corrupted. An automated boot test verifies that a machine starts. A functional test confirms that the application, database, permissions and dependencies actually allow work to resume. These are different levels. For a critical application, the exercise should go as far as a representative transaction or user scenario.

Restore into an isolated environment to avoid reintroducing malware or creating a conflict with production. Measure the time from the decision to restore until the service is available. Record manual steps, missing credentials, bandwidth, errors and business validation time. Compare the result with the RTO and the restored point with the RPO.

The IT disaster recovery plan links these tests to the restart order, roles, communications and dependencies. Successful data recovery is not enough if DNS, identity, the network, a licence or a critical supplier remains unavailable.

Rollout plan

The size of the organisation matters less than the impact of an outage, data sensitivity and the complexity of dependencies.

A non-profit organisation or a school may depend on Microsoft 365, registration software and a few administrative workstations. The plan should cover accounts, shared documents and recovery during an enrolment or examination period. A managed immutable copy may be more realistic than complex infrastructure without a dedicated owner.

A professional practice or healthcare organisation must distinguish clinical availability, confidentiality and retention. Immutability reduces the risk of deletion, but does not justify keeping every piece of data indefinitely. Access rights, encryption, traceability and the recovery procedure must be proportionate to the sensitivity.

NIS2, GDPR and evidence: what immutability does not prove

An immutable backup supports resilience and secure processing, but by itself it demonstrates neither NIS2 compliance nor GDPR compliance.

European Implementing Regulation 2024/2690, applicable to certain categories of digital entities covered by NIS2, requires business continuity and recovery plans to be tested, reviewed and updated at planned intervals. The EUR-Lex text must be read according to the organisation’s scope of application. Other Belgian entities may fall under the NIS2 Act and different proportionate measures.

Company device

Nine-step implementation plan

The safest approach starts with critical services and then adds immutability to an architecture that is already understandable and testable.

Company device

1. Map the services, data, identities, keys and suppliers required for recovery.
2. Assign a business owner, realistic RPO and RTO to each critical service.
3. Draw the existing copies and mark their accounts, networks, sites and platforms.
4. Identify common points of failure: domain, console, vault, supplier or administrator.
5. Choose the offline or immutable copy based on risk, volumes, recovery time and skills.
6. Define retention, exceptions, expiry and capacity before locking a policy.
7. Separate privileges, enable MFA where available and protect emergency accounts.
8. 4. Company-owned device
9. Schedule recurring tests, address every gap and update the disaster recovery plan after changes.

Common mistakes to avoid

The most dangerous mistakes create a sense of security while retaining a common point of failure.

4. Company-owned device

1. Confusing a snapshot, replication, synchronisation or recycle bin with an independent backup.
2. Joining the backup repository to the same domain and reusing everyday administrative accounts.
3. Calling storage “off-site” when the same cloud account can delete it.
4. Enabling a WORM policy without testing, capacity planning or an expiry procedure.
5. Keeping data for too short a period to survive a silent compromise.
6. Keeping all data indefinitely in the name of GDPR or NIS2.
7. Testing only a file when recovery depends on a complete application.
8. Measuring copy time but not the actual recovery and validation time.
9. Forgetting keys, licences, network configurations, SaaS accounts and supplier contacts.