NIS2 Backup Policy: CIR Annex 4.2, the 3-2-1-1-0 Rule, and How to Set Defensible RPO/RTO Targets

Search for “NIS2 backup requirements” and most results tell you the same thing: Commission Implementing Regulation (EU) 2024/2690 requires air-gapped, immutable backup copies. Read the actual Annex text and neither word appears. What CIR 2024/2690 requires is an outcome — a backup copy stored somewhere an attacker or a disaster at your main site cannot reach — and it leaves the mechanism up to you. That distinction matters, because a backup policy document that mirrors marketing language instead of the regulation’s own wording is exactly the kind of gap an auditor catches in the first ten minutes.

This article works from the primary text: Article 21(2)(c) of the NIS2 Directive [1][2], the six sub-points of CIR Annex 4.2 [3], and how German national cybersecurity authority BSI frames implementation via BSI-Standard 200-4 [4]. It covers what the law actually says, how to calculate Recovery Point Objective (RPO) and Recovery Time Objective (RTO) for your own systems, how the widely-used 3-2-1-1-0 backup rule maps onto the CIR’s six sub-points, and what documentation an auditor expects to see. For the full list of all ten Article 21(2) risk-management measures beyond backup, see our Article 21 breakdown.

Who This Applies To: Direct Obligation vs. Benchmark

In short: Article 21(2)(c)’s backup and disaster recovery requirement applies to every essential and important entity under NIS2. CIR 2024/2690’s detailed Annex 4.2 sub-points formally bind only a narrower set of digital-infrastructure and digital-service-provider entity types — but auditors and consultants across sectors now use it as the working technical benchmark, because it’s the only document-level detail the regulatory framework provides.

Entity type	Backup obligation source	Applies directly?
DNS providers, cloud/CDN/MSP/MSSP, online marketplaces, search engines, social platforms, trust service providers	CIR 2024/2690 Annex 4.2	Yes — direct obligation
Manufacturing, energy, transport, health, water, public administration, and all other essential/important entities outside the CIR’s digital-service-provider list	NIS2 Art.21(2)(c), via national transposition	Indirect — Art.21(2)(c) binds you; CIR 4.2 is the de facto technical benchmark auditors reference, not a direct legal requirement

If your organisation isn’t a DNS registry, cloud provider, CDN, MSP/MSSP, marketplace, search engine, social platform, or trust service provider, CIR Annex 4.2 doesn’t name you directly. Your national competent authority still expects a backup and disaster recovery capability under Article 21(2)(c), and in the absence of sector-specific technical guidance, CIR 4.2’s structure is what most auditors and consultants reach for as a working standard. Treat the sub-points below as the benchmark you’ll be measured against even if the regulation’s text doesn’t cite your sector by name. This backup requirement sits inside the broader Article 21(2)(c) business continuity obligation — our business continuity guide covers the full picture: BIA, crisis management, and exercise cadence beyond backups alone.

What Article 21(2)(c) and CIR Annex 4.2 Actually Require

Article 21(2)(c) of the NIS2 Directive requires measures covering “business continuity, such as backup management and disaster recovery, and crisis management” [1][2]. That’s the entire operative text — three concepts introduced by “such as,” meaning these are examples of business continuity measures, not an exhaustive checklist. The technical detail lives in CIR 2024/2690’s Annex, Section 4.2, “Backup and redundancy management.”

Here is what the six sub-points actually say, not what the marketing copy around them claims:

CIR point	Requirement	What it actually says
4.2.1	General obligation	Maintain backup copies and “sufficient available resources … to ensure an appropriate level of redundancy”
4.2.2	Backup plan content	Must define recovery times; assurance backups are “complete and accurate,” including cloud-hosted configuration data; storage “at sufficient distance to escape any damage from a disaster at the main site,” not on the same network; access controls; retention periods
4.2.3	Integrity checks	Regular integrity checks on the backup copies themselves
4.2.4–4.2.5	Redundancy of resources	At least partial redundancy of network/information systems, physical assets and facilities, trained personnel, and communication channels; resource monitoring informed by backup and redundancy needs
4.2.6	Recovery testing	“Regular testing of the recovery of backup copies,” with documented results and corrective action where the test fails

Notice what’s missing from that list: the words “air-gap,” “air-gapped,” “immutable,” or “offline” [3]. The regulation asks for an outcome — a copy that isn’t reachable from the same network and sits far enough away to survive whatever destroyed the primary site — and stays silent on the specific technology that gets you there. Air-gapping (physical or network isolation) and immutability (software-enforced write protection) are both accepted ways of satisfying “not on the same network” and “sufficient distance,” and most mature implementations use both together [5]. If a vendor tells you the regulation “requires” one specific technology, that’s their interpretation, not the Annex’s wording — worth knowing before you pay a premium for a feature the law doesn’t actually name.

RPO and RTO: Definitions and How to Actually Calculate Them

Recovery Point Objective (RPO) is the maximum amount of data loss your organisation can tolerate, measured in time. Recovery Time Objective (RTO) is how long you can be down before the disruption becomes unacceptable [6]. They sound similar and get confused constantly, so here’s the distinction that matters operationally: RPO sets your backup frequency; RTO sets your recovery infrastructure spend.

Your Business Impact Analysis (BIA) is where these targets originate — our guide to building a NIS2-compliant BIA covers how to derive RTO and RPO from business impact severity, including the relationship to Maximum Tolerable Period of Disruption (MTPD). This section covers the other half: once you know your target RPO, how do you actually hit it?

RPO is a direct function of backup frequency. An RPO of 4 hours means your most recent backup can be no more than 4 hours old when failure occurs — which means backups running at least every 4 hours, not once a night [6]. Three architecture tiers, in order of cost and RPO tightness:

• Nightly full/incremental backup — typical RPO: up to 24 hours. Lowest cost, suitable where a day of data loss is tolerable (internal reporting tools, low-change reference data).
• Hourly snapshot or log-shipping — typical RPO: 15 minutes to 1 hour. Mid-cost, standard for transactional systems (order processing, CRM, ticketing).
• Continuous replication / synchronous mirroring — typical RPO: seconds to near-zero. Highest cost, reserved for systems where any data loss is unacceptable (payment processing, safety-critical OT).

RTO works the other direction: it’s a target you engineer toward by choosing recovery infrastructure. Restoring from cold storage kept offsite might take 12–24 hours; a warm standby environment you can fail over to might take 30–60 minutes; a hot active-active setup can fail over in minutes. An organisation that sets a 2-hour RTO but backs up to cold offsite storage has set a target its own architecture cannot meet — a mismatch that an audit, and a real ransomware incident, will both expose. Manufacturing environments with legacy OT systems face a particularly sharp version of this problem; see our guide to setting OT-realistic RTO/RPO windows for a sector-specific worked example.

The 3-2-1-1-0 Rule Mapped to CIR Annex 4.2

The 3-2-1-1-0 rule is not itself a NIS2 requirement — it’s an industry practice, an extension of photographer Peter Krogh’s original 2005 “3-2-1” rule, now the framework backup vendors such as Veeam recommend for ransomware resilience [5]. It happens to map cleanly onto what CIR 4.2 asks for, which is why it’s worth using as an implementation checklist even though the regulation never names it.

Rule element	What it means	CIR 4.2 sub-point it satisfies
3 copies	Production data + primary backup + backup copy	4.2.1 — “appropriate level of redundancy”
2 media types	e.g. disk + cloud, or disk + tape	4.2.2 — reduces the single-point-of-failure risk implicit in the “complete and accurate” backup assurance
1 offsite	At least one copy stored away from the primary site	4.2.2 — “sufficient distance to escape any damage from a disaster at the main site”
1 immutable/air-gapped	At least one copy that cannot be modified, deleted, or reached over the production network	4.2.2 — “not in the same network as the system”
0 errors	Verified via test restores, zero recovery errors	4.2.6 — “regular testing of the recovery of backup copies … documented results”

Veeam’s guidance is explicit that immutability and air-gapping are different mechanisms, not synonyms: immutability is a software or storage-layer control against modification or deletion, while air-gapping is physical or network isolation against access in the first place [5]. Using both is stronger than either alone — immutability protects against a compromised admin account issuing a delete command; air-gapping protects against an attacker with full network access who simply can’t reach the isolated copy.

A practical gap-analysis view, from a typical starting point to CIR-4.2-aligned:

Current state	Required state	Effort to close
Single onsite backup, no offsite copy	At least one copy at sufficient distance from the main site (4.2.2)	Medium — cloud storage or a second site; budget and provisioning time
Backups on the same network/domain as production	At least one copy isolated from the production network (4.2.2)	Medium-High — an architecture change, not just a policy update
No immutability or air-gap on any copy	At least one immutable or air-gapped copy	Low-Medium — most backup platforms and cloud object storage offer this as a configuration toggle
Restore tests run ad hoc, undocumented	Regular, documented restore tests with corrective-action tracking (4.2.6)	Low — a process and documentation change, minimal new spend
No integrity checks on the backup copies themselves	Scheduled integrity verification (4.2.3)	Low — usually a built-in backup-platform feature that just needs enabling and scheduling

Testing Cadence and Audit Evidence

CIR 2024/2690 requires two distinct, ongoing checks: regular integrity checks on the backup copies (4.2.3), and regular testing of the recovery of those copies, with documented results and corrective action where a test fails (4.2.6) [3]. Neither sub-point specifies an exact interval — “regular” is left to the entity’s own risk assessment; BSI’s own materials point entities toward BSI-Standard 200-4 for a structured approach rather than naming a fixed cadence [4]. As a general guideline, German compliance practitioners commonly recommend quarterly restore tests for critical systems and semi-annual tests for non-critical systems [7] — useful as a starting benchmark, though it’s professional guidance rather than a BSI or CIR mandate. Whatever interval you choose, document every test’s results and any corrective actions taken [3].

In reviewing backup policies for compliance readiness, the gap that comes up most often isn’t a missing backup — it’s a missing test log. A policy that states “we test restores quarterly” with no dated evidence reads, to an auditor, identically to a policy that never tests at all. What you need on file for each test cycle:

• Date and scope of the test (which systems, which backup copy generation)
• Whether the restore succeeded within the defined RTO
• Data integrity confirmation post-restore, including configuration data for cloud-hosted systems
• Any failures identified, the corrective action taken, and its completion date
• Sign-off from the responsible owner

Building Your Backup Policy Document

A CIR-4.2-mapped backup policy document needs to answer, in writing, everything the sub-points ask for: what gets backed up and how often (tied to your RPO), where copies are stored and how that satisfies the distance and network-isolation requirement, who can access backup infrastructure and how that access is logged, how long backups are retained, and how restore testing is scheduled and documented [3]. Splitting ownership across roles keeps the document from becoming an IT-only artefact that Compliance can’t defend in an audit:

Role	Owns
IT / Infrastructure	Backup architecture, media selection, encryption, restore execution
CISO / Security	Access-control policy for backup systems, immutability/air-gap configuration, integrity-check scheduling
Compliance / Legal	Retention periods against legal/regulatory need, documentation completeness, mapping to CIR 4.2 sub-points for audit
Board / Management	Budget for the RPO/RTO targets the business actually needs; sign-off on residual risk where targets aren’t fully met

Article 20(1) requires that the management body “approve the cybersecurity risk-management measures” taken to comply with Article 21 and “oversee its implementation,” and members “can be held liable for infringements” [8]. Backup architecture decisions aren’t purely a technical sign-off — under NIS2, they’re one the board is formally on the hook for.

Conclusion

CIR 2024/2690 Annex 4.2 asks for an outcome, not a shopping list of named technologies: backup copies that are complete, isolated from the production network, tested on a documented schedule, and stored far enough away to survive whatever took out the main site. The 3-2-1-1-0 rule is a reliable way to get there, and RPO/RTO targets calibrated to your actual backup architecture — not just business-impact theory — are what keep those targets honest.

Start by matching your current backup setup against the CIR 4.2 sub-point table above. Most gaps close with configuration changes — enabling immutability, scheduling integrity checks — rather than new infrastructure. The exception is usually the offsite/network-isolation requirement, which takes budget and lead time to fix if it’s missing.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Frequently Asked Questions

Does NIS2 require air-gapped backups?
Not by that name. Article 21(2)(c) and CIR 2024/2690 Annex 4.2 require that at least one backup copy sit outside the production network and far enough away to survive a disaster at the main site [1][2][3]. Air-gapping is one accepted way to meet that requirement; software-enforced immutability is another, and using both together is common industry practice [5].

What’s the actual difference between RPO and RTO?
RPO is how much data you can afford to lose, measured in time before the failure. RTO is how long you can afford to be down after the failure. RPO drives your backup frequency; RTO drives your recovery infrastructure investment [6].

How often does CIR 2024/2690 require backup restore testing?
The regulation says “regular” testing without a fixed interval, leaving the exact cadence to your own risk assessment [3]. A commonly cited practitioner benchmark is quarterly testing for critical systems and semi-annual for non-critical systems [7] — useful as a starting point, but it’s professional guidance, not a BSI or CIR mandate.

Does CIR 2024/2690 Annex 4.2 apply to my organisation directly?
Only if you’re a DNS provider, cloud/CDN/MSP/MSSP, online marketplace, search engine, social platform, or trust service provider — the entity types CIR 2024/2690 formally covers. Everyone else is bound by Article 21(2)(c)’s general backup and disaster-recovery requirement, with CIR 4.2 serving as the de facto technical benchmark auditors reference [1][2][3].

Sources

1. Directive (EU) 2022/2555 (NIS2 Directive) — EUR-Lex
2. NIS 2 Directive, Article 21: Cybersecurity risk-management measures — nis-2-directive.com
3. Commission Implementing Regulation (EU) 2024/2690 — EUR-Lex
4. #nis2know: BCM — BSI (Bundesamt für Sicherheit in der Informationstechnik)
5. Protect the Backups — the 3-2-1-1-0 Rule — Veeam Best Practices Guide
6. What Is the Difference Between RTO and RPO? — Advisera / ISO 27001 Academy
7. NIS2 Backup: Datensicherung nach §30 BSIG — secjur.com (practitioner guidance)
8. NIS 2 Directive, Article 20: Governance — nis-2-directive.com