NIS2 Backup Requirements 2026: Is Immutable Storage Mandated?

Why backup became a boardroom compliance question, not just an IT task

Ask a compliance officer whether NIS2 mandates immutable backup and the honest answer is: not in so many words. The directive's Article 21(2)(c) requires organisations to maintain policies on business continuity, backup management, and disaster recovery — outcome-based language, not a shopping list of technologies. That gap between what the law literally says and what auditors, insurers, and EU customers actually expect is exactly where UK IT leaders keep getting caught out.

This is a decision article, not a legal one. It walks through the letter of NIS2, the direction of travel of the UK Cyber Security and Resilience Bill, and the practical evidence bar that has emerged around both — so you can decide what to build before someone else's questionnaire forces the issue.

NIS2 Article 21(2)(c): what the law actually requires

The operative text is narrow and deliberately technology-neutral: in-scope entities must maintain policies covering business continuity, backup management, and disaster recovery, alongside crisis management arrangements. There is no clause naming immutable storage, air-gapping, or a specific retention period. The directive is risk-based by design — it sets outcomes and expects organisations to select controls proportionate to their own risk assessment.

The transposition deadline for EU member states was 17 October 2024, and compliance expectations have been running through active 2025-2026 enforcement cycles since. Supporting this is Commission Implementing Regulation (EU) 2024/2690, which member states and auditors use to operationalise the Article 21 control areas in more concrete terms.

It's worth separating the legal text from the guidance built around it. ENISA's technical implementation guidance is published as formal implementation support, not as a legal instrument — it informs how auditors interpret the directive but does not itself create statutory duties. That distinction matters when a vendor or consultant tells you something is 'required by NIS2' — check whether they mean the directive or the guidance layered on top of it.

The technical reading: what a 'compliant' backup looks like in practice

Compliance commentary has converged on a practical benchmark, commonly described as the 3-2-1-1-0 model, that operationalises Article 21(2)(c) without the directive ever specifying it by name:

• •3 copies — production data plus two independent backup copies
• •2 media types — diversifying storage to remove single points of failure
• •1 offsite copy — geographically distant from the primary site
• •1 immutable or offline copy — cannot be altered or deleted during the retention window
• •0 restore errors — verified through documented, repeated restore testing

RTO and RPO: set by risk, proven by testing — not fixed by statute

Neither NIS2's Article 21 nor the guidance built around it prescribes a numeric recovery time or recovery point objective. That's consistent with the directive's risk-based structure: your RTO and RPO should come out of your own risk assessment, weighted by the criticality of each system and service, and then be documented as the justification an auditor will ask to see.

What compliance guidance is explicit about is the proof standard. A successful backup job is treated as insufficient evidence on its own — the widely cited interpretation is that recoverability, not mere copy creation, is the actual compliance test. That means restore testing with documented, dated results against your stated RTO/RPO, not a green tick in a backup console. Before setting those targets, it's worth quantifying what an hour or a day of downtime actually costs your organisation using a downtime cost calculator, so the RTO you commit to on paper is one the business can actually defend.

The UK Cyber Security and Resilience Bill: overlap, not duplication

The Cyber Security and Resilience Bill is UK legislation that has cleared the House of Commons and is currently progressing through the House of Lords towards Royal Assent, expected later in 2026. It should not be treated as a verbatim copy of NIS2 — its exact clauses and final wording differ and are still subject to parliamentary process. Its direction of travel, however, points toward reinforcing resilience and incident-reporting duties in a way that closely echoes the spirit of Article 21(2)(c), even if the backup-specific language ends up worded differently.

For most UK organisations, NIS2 itself has no direct statutory force — it's an EU directive. Direct exposure arises mainly for UK businesses operating through EU entities, EU-critical suppliers, or regulated cross-border services. But the practical pressure is already broader than that: UK suppliers selling into EU-regulated customers are increasingly seeing procurement and incident-response questionnaires that ask for immutable or air-gapped backups, defined RTO/RPO, restore-test evidence, and separation of backup credentials from production systems — regardless of whether NIS2 technically applies to the UK party. Buyers preparing for the UK Bill should treat that questionnaire pressure as a preview, and navigate NIS2 compliance expectations now rather than reactively.

Worked scenario: proving compliance when the questionnaire lands

Consider a UK-headquartered managed service provider with an EU subsidiary delivering a regulated service. An EU customer's procurement team sends a NIS2-aligned supplier questionnaire ahead of a contract renewal, asking the provider to evidence its backup and recovery posture.

The provider needs more than infrastructure — it needs a paper trail. That means a backup and business continuity policy that references its Article 21(2)(c)-equivalent obligations, an architecture diagram showing the 3-2-1-1-0 copy paths including the immutable or offline component, dated restore-test logs showing pass/fail outcomes against stated recovery targets, a risk assessment justifying the RTO/RPO chosen for each in-scope system, and access records showing backup administration credentials are separated from day-to-day production accounts. Providers who can implement robust backup and disaster recovery solutions with this evidence already assembled answer the questionnaire in days rather than scrambling for weeks.

The audit-ready documentation set regulators and customers expect

Across NIS2 guidance and the UK direction of travel, the paperwork auditors ask for is consistent even when the underlying statute differs:

• •A backup and business continuity policy referencing the relevant continuity/disaster-recovery obligation
• •An architecture diagram showing copy count, media diversity, offsite location, and the immutable/offline component
• •Restore test logs recording date, scope, systems restored, and pass/fail outcome
• •A documented risk assessment justifying the RTO/RPO set for each critical system
• •Access control records showing backup credentials are separated from production administration
• •An incident-response plan that explicitly references backup recovery procedures

Consequences: why 'we have backups' no longer passes

The operational trigger regulators and customers actually test against isn't whether a backup exists — it's whether it can be restored inside the recovery objective an organisation committed to, under adversarial conditions such as ransomware that specifically targets backup infrastructure. That's the practical reason immutability has become a de facto expectation even though neither the NIS2 text nor the emerging UK Bill names it directly.

The commercial consequences of failing this test show up before any formal enforcement action: lost EU contracts when a questionnaire can't be answered, failed supplier audits, and reputational damage when an incident reveals backups were present but unusable. Given the direction both regimes are heading, building a defensible, tested, immutable backup layer now is the lower-cost route compared with reconstructing evidence retrospectively after an incident or a lost tender.

Sources

Every figure in this article traces to the sources below.

• •EUR-Lex — NIS2 Directive text, Article 21(2)(c) and transposition deadline
• •EUR-Lex — Commission Implementing Regulation (EU) 2024/2690
• •ENISA — NIS2 technical implementation guidance status
• •Pasquale Pillitteri — 3-2-1-1-0 practical backup model
• •NIS2Certify — why a successful backup job doesn't prove recoverability
• •Mindtime — restore testing, offsite storage, and UK cross-border exposure
• •Commsec — immutability as a ransomware resilience measure, not a literal directive term
• •ViVeSec — NIS2 doesn't literally require 'immutable' but practically expects it
• •OpenEmpower — recoverability, not copy creation, is the compliance test
• •Secjur — 3-2-1 plus an immutable fourth dimension for ransomware protection