Does NIS2 Require a Secondary Data Centre? ‘Secondary’ Appears 0 Times in the CIR — What 4.2.4 and ‘Sufficient Distance’ Require Instead

Short answer: no clause in NIS2 says “secondary data centre”. Neither the Directive nor Commission Implementing Regulation (EU) 2024/2690 (the CIR) uses the words “secondary data centre” or “disaster recovery site”, and neither gives a distance in kilometres. Two Annex points do the work instead. Point 4.2.4 requires “at least partial redundancy” of four resource classes, and facilities are one of them. Point 4.2.2(c) requires backup copies stored “at sufficient distance to escape any damage from a disaster at the main site”.

Read together, they require somewhere you can recover to that one disaster can’t take out along with your main site. That might be a second data centre you own, a colocation cage, a cloud region or a contracted hot site. Your risk assessment decides which, and how far away it has to be.

We ran a term count across the CIR’s Official Journal text: “secondary”, “geographic”, “failover”, “region” and “kilometre” each appear 0 times, and “distance” appears once, in 4.2.2(c). That silence is why auditors borrow an outside benchmark, usually the German BSI’s data-centre siting criteria: about 200 km between georedundant sites, never less than 100 km. This spoke of our NIS2 business continuity guide explains both clauses, the BSI numbers and the evidence that settles the question.

Who these clauses bind directly

In plain terms: the CIR Annex binds a defined list of digital providers. Every other entity in NIS2 scope meets the same topic through Article 21(2)(c) of the Directive and its national transposition. For them, the CIR is the most detailed reference available, but it isn’t binding.

Entity type	What applies	Secondary site written into the text?
DNS service providers, TLD registries, cloud, data centre service providers, CDNs, MSPs, MSSPs, online marketplaces, search engines, social networks, trust service providers (CIR Article 1)	CIR Annex points 4.2 and 13.1, directly	No. Redundancy and distance are risk-based
All other essential and important entities (energy, manufacturing, health, transport and the rest)	NIS2 Article 21(2)(c), “business continuity, such as backup management and disaster recovery, and crisis management”, as transposed into national law	No. The CIR is the benchmark
Financial entities under DORA (other than microenterprises)	DORA Article 12(4): “redundant ICT capacities”	No
Central securities depositories	DORA Article 12(5)	Yes: “at least one secondary processing site”

The NIS2 Directive uses “redundant” once, for national CSIRTs (Article 11(1)(f)), not for you. If you aren’t sure which row describes you, run our NIS2 scope test first.

The three clauses, word for word

In plain terms: one clause moves your backup copies away from the main site, one makes your resources redundant, and one asks you to consider redundant utilities. Only the first mentions distance, and none of them names a site.

CIR point	Verbatim text	Qualifier	What it does not say
4.2.2(c)	“storing backup copies (online or offline) in a safe location or locations, which are not in the same network as the system, and are at sufficient distance to escape any damage from a disaster at the main site”	None. The backup plan is “based on the results of the risk assessment” and the business continuity plan	No distance figure. It covers copies of data, not running systems
4.2.4	“ensure sufficient availability of resources by at least partial redundancy of the following: (a) network and information systems; (b) assets, including facilities, equipment and supplies; (c) personnel with the necessary responsibility, authority and competence; (d) appropriate communication channels”	No “where appropriate”. Scope is set by the risk assessment and the business continuity plan	No site, no distance, and not “full” redundancy
13.1.2(b)	“consider the use of redundancy in utilities services”	“where appropriate”, plus the verb “consider”	A duty to consider, not to install

The modal verbs matter. CIR Article 2(2) lets an entity skip a requirement marked “where appropriate” if it documents its reasoning “in a comprehensible manner”. That route exists for 13.1.2 but not for 4.2.4, which is a plain “shall”. You can’t document your way out of redundancy. What you can do is size it. “At least partial” sets a low floor: something in each of the four classes has to be redundant, not everything. Point 4.2.6 then requires “regular testing of the recovery of backup copies and redundancies”, with the results documented. Redundancy you have never tested won’t count as evidence.

Why distant backups alone don’t satisfy 4.2.4

In plain terms: a backup 300 km away keeps your data alive. It doesn’t keep your service alive unless something at that distance can run it within your recovery time.

Point 4.2.2(c) protects copies. Point 4.2.4(b) names “facilities, equipment and supplies”. Point 4.2.2(a) adds “recovery times”. If a fire destroys your only server room, your data survives in a distant backup, but recovery now depends on finding hardware, a room, power and network links. That can take weeks. If your business impact analysis sets an 8-hour recovery time objective, the risk assessment behind 4.2.4 has to show where those systems will run within 8 hours. That’s the real secondary-site test. The question isn’t whether you own one. It’s whether your stated recovery time still holds when the main site is gone.

ENISA’s Technical Implementation Guidance (v1.0, June 2025) lists mechanisms for each class, all marked “indicative, non-exhaustive”:

4.2.4 class	ENISA examples	“Partial” in practice	Evidence to keep
(a) Network and information systems	Multiple internet service providers, load balancing, mirrored servers, virtualisation, RAID	Mirror only the systems your BIA rates critical	Architecture diagram, failover test record
(b) Assets, including facilities	Shared workspaces, backup locations, spare equipment, multiple suppliers for the same product categories	A standby room, colocation contract or cloud landing zone for critical workloads only	Contract or SLA, asset inventory entry
(c) Personnel	Job rotation, backup assignments, emergency drills	A named deputy for each critical role (our personnel redundancy guide covers 4.2.4(c) in depth)	Deputy register, drill records
(d) Communication channels	Multiple platforms such as social media, messaging apps and email. ENISA also lists multiple power providers or generators here	One channel that doesn’t depend on your main site	Contact tree, channel test log

ENISA’s evidence bar for 4.2.4 is short: “One or more of the above mechanisms are in place.” Its continuity-plan guidance (4.1.2) is more revealing: “full redundancy”, “failover mechanisms” and an “alternative site” are “advanced measures” for “where appropriate”, alongside third-party services such as a “hot site”. So ENISA puts an alternative site at the advanced end, not the baseline. Field (g) of your disaster recovery plan, “required resources, including backups and redundancies”, is where you record what you chose.

How far is “sufficient distance”? The BSI benchmark

In plain terms: no EU text gives a number. The most-cited one, 200 km, comes from Germany’s federal cybersecurity agency. It’s a recommendation for high-availability data centres, not a NIS2 rule.

The BSI’s data-centre siting criteria (RZ-Standortkriterien, first published December 2018, version 2.1 December 2024) separate two kinds of site redundancy. “Operational redundancy” means sites close enough to share some risks. “Georedundancy” means sites far enough apart that large regional events are unlikely to hit both. Combined with ENISA’s separation guidance for critical components (under point 6.8.2), they give a distance ladder:

Separation	Distance	Survives	Doesn’t survive	Source
Separate racks or rooms	Same building	Component failure, a fire in one room	Loss of the building	ENISA guidance, 6.8.2
Separate structures on one campus	Same site	Loss of one building	A site-wide evacuation	BSI ch. 3: the “absolute minimum”, and only if events destroying a whole building can be ruled out
Operational redundancy	At least about 5 km, ideally 10 to 15 km	Cordons of up to 1,500 m (hazardous-goods accidents, major fires, unexploded WWII bombs) and local traffic disruption	Regional floods, storms, a shared grid segment	BSI ch. 3
Georedundancy	About 200 km recommended, never under 100 km	Large-scale events. BSI cites the 2005 Münsterland snow disaster and the 2013 Elbe and Danube floods	Continental-scale events	BSI ch. 4

Distance is only one BSI test. Georedundant sites also shouldn’t share a river system (unless at least 5 m above the highest flood since 1960) or a segment of the high-voltage transmission grid.

Check the status before quoting 200 km. The BSI says the document expressly does not aim to make any redundancy model generally mandatory, that the choice rests on a risk analysis, and that it mainly targets data centres with high or very high availability needs. Germany’s standards committee for EN 50600, DKE/GK 719, criticised the first version’s figure as underived. It noted that the authors the BSI cites name distances from 3.5 km to over 5,000 km, and argued that a risk assessment beats fixed distances.

So use 200 km to anchor your reasoning, not as a pass mark. If your sites are 30 km apart, write down which disasters you considered and why 30 km escapes them. The BSI’s own deviation clause asks for exactly that.

There’s also a physics trade-off. The BSI warns that cable routes over 100 km can cause problems for synchronous replication as round-trip times rise, and cable routes always run longer than the straight-line distance. A zero recovery point objective pulls your sites together, and disaster protection pushes them apart. The common answer is a synchronous pair nearby plus an asynchronous copy far away. The BSI says the trade-off you pick must be justified in the security concept.

What an explicit mandate looks like: DORA Article 12(5)

In plain terms: EU law can require a secondary site when it wants to. DORA does, but only for central securities depositories, and even there it gives no kilometre figure.

DORA Article 12(5) requires central securities depositories to “maintain at least one secondary processing site”. It must be “located at a geographical distance from the primary processing site to ensure that it bears a distinct risk profile”, able to keep critical functions running, and “immediately accessible” to staff. All other financial entities except microenterprises get the softer Article 12(4): “redundant ICT capacities”. DORA and NIS2 were adopted on the same day, 14 December 2022. The most reasonable reading is that the legislator knew how to write a secondary-site mandate and chose not to write one into NIS2. Our NIS2 vs DORA comparison covers the wider overlap.

DORA’s “distinct risk profile” still makes a good test for 4.2.2(c): if the backup location shares a flood plain, grid segment, internet provider or admin account with the main site, its distance doesn’t buy much. Our same-network guide covers the admin-account side.

Do you need a second site? A decision path

In plain terms: work back from your recovery time objective. If you can rebuild inside it after losing the main site, distant backups and a tested rebuild plan may be enough. If not, you need standby capacity.

1. Check whether the CIR binds you. If you’re on the Article 1 list, 4.2.4 applies directly. Otherwise, apply your national law and use the CIR as the benchmark.
2. Take the recovery time objective for your most critical service from your business impact analysis (CIR 4.1.3).
3. Test the main-site-loss scenario on paper. Could you restore from backup onto procured or cloud resources within that time? If yes, offsite backups at a documented distance plus a rebuild runbook can cover 4.2.4(b) for that service. If no, you need warm or hot standby capacity: owned, colocated, contracted or in the cloud.
4. Name the hazards. Use the disasters listed in your risk assessment (2.1 and 13.2.1) to set the distance, with the ladder above as your yardstick.
5. Test it under 4.2.6, record the result and fix what fails.

ENISA’s guidance on 4.2.1 explicitly allows the outsourced route: “Consider whether to invest in own redundancy or to engage third parties, for example cloud providers”. One caution: availability zones inside a single cloud region are generally built close together for low latency, so check your provider’s documentation before counting two zones as distance. Our cloud shared-responsibility guide explains which side of that line you’re on.

Role	What to do this quarter
CISO / IT manager	Map each critical service to a recovery location and a measured failover time, and test it under 4.2.6
SME owner	Ask your hosting or cloud provider where backup copies are stored and how far that is from production. A second cloud region is usually cheaper than a second server room
Compliance officer	File a written rationale for the distance, plus Article 2(2) reasoning for any 13.1.2 utility measure you don’t adopt
Board	If you decide against standby capacity, formally accept the residual risk of a longer outage after main-site loss

Energy operators face the same question for backup control centres. The Energy Policy Pack includes an energy-sector Business Continuity & Backup policy.

Evidence that settles the question in an audit

In plain terms: nobody can fault you for lacking a site the law never names. An auditor can fault you for having no written answer to “where do you recover to, and why there?”

• A risk-assessment scenario for “loss of main site” that names its hazards (points 2.1 and 13.2.1)
• Recovery time and recovery point objectives for each critical service (4.1.3)
• A backup plan stating storage locations, network separation and the distance rationale (4.2.2(c)). Our backup requirements guide covers the other five sub-points
• A redundancy register covering all four 4.2.4 classes, showing what is redundant and what deliberately isn’t
• Results from recovery and failover tests, with corrective actions (4.2.6)
• Documented reasoning for any 13.1.2 utility measure you didn’t apply (facility operators: see our data centre compliance guide)
• If you’re certified to ISO 27001, the same evidence serves controls 8.14 “Redundancy of information processing facilities” and 8.13 “Information backup” in ISO/IEC 27002:2022

Under Article 34(4) and (5), maximum fines for Article 21 infringements must be at least €10 million or 2% of worldwide annual turnover for essential entities, and €7 million or 1.4% for important entities, whichever is higher (see our NIS2 penalties guide).

Frequently asked questions

Does NIS2 require a disaster recovery site?

Not by name. CIR 4.2.4 requires at least partial redundancy of facilities and other resources, scaled to your risk assessment and business continuity plan. Whether that means a dedicated site depends on whether you can meet your recovery times without one.

Does a second site in the same city count?

It can count as redundancy under 4.2.4. Whether it gives “sufficient distance” under 4.2.2(c) depends on your hazards: a citywide flood or grid outage would hit both sites. The 200 km figure is a BSI recommendation, not law.

Is cloud backup enough?

It can meet 4.2.2(c) if the copies are outside your production network and far enough from your main site. It meets 4.2.4(b) only if you can also run your critical systems somewhere within your recovery time.

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.

Sources

1. Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024. EUR-Lex, Official Journal text. Articles 1 and 2(2); Annex points 4.1.2, 4.1.3, 4.2.1–4.2.6, 13.1.2 and 13.2.1.
2. Directive (EU) 2022/2555 (NIS2 Directive). EUR-Lex. Articles 11(1)(f), 21(2)(c) and 34(4)–(5).
3. Technical Implementation Guidance on cybersecurity risk-management measures, version 1.0. ENISA, June 2025. Guidance under Annex points 4.1.2, 4.2.1, 4.2.2, 4.2.4 and 6.8.2.
4. Kriterien für die Standortwahl von Rechenzentren (RZ-Standortkriterien), version 2.1. Bundesamt für Sicherheit in der Informationstechnik (BSI), December 2024. Sections 1.1, 1.3, 1.4, 2.2, 3 and 4.
5. Regulation (EU) 2022/2554 (Digital Operational Resilience Act). EUR-Lex. Article 12(4)–(5).
6. Mitteilung des DKE/GK 719 zum BSI-Dokument „Kriterien für die Standortwahl höchstverfügbarer und georedundanter Rechenzentren“. DKE, 20 March 2019.
7. ISO/IEC 27002:2022, Information security, cybersecurity and privacy protection: Information security controls. Preview edition (table of contents), controls 8.13 and 8.14.