NIS 2 backup strategy under Article 21(2)(c)
NIS 2 says you have to keep the business running through and after an incident. Article 21(2)(c) names backup management, disaster recovery and crisis management. CIR (EU) 2024/2690 §4.2 turns that into a documented backup plan, regular recovery tests, and redundancy.
The short version
Backup under NIS 2 is not 'do we have backups'. Every Mittelstand IT shop has nightly tape or snapshot jobs. The question the directive and the CIR actually ask is whether you have a documented plan, with recovery times, off-site storage, access controls, retention periods, and a tested ability to bring the systems back.
CIR §4.2 has six pieces. A backup plan with six named points. Regular integrity tests. Redundancy of network, assets, personnel and communications. Resource monitoring. And regular recovery tests with documented results. All six sit in one Annex section. None of them is optional.
Germany puts the same rule into national law through §30(2)(3) BSIG. The wording transposes Article 21(2)(c) almost word for word. This page walks the directive, the EU follow-up regulation, and the German transposition in that order.
Article 21(2)(c) NIS 2 Directive (2022/2555)
Business continuity, such as backup management and disaster recovery, and crisis management.
This is point (c) on the list of ten cybersecurity measures every essential and important entity has to put in place. Backup management is named directly in the directive text, not just buried in implementing regulation.
CIR (EU) 2024/2690, Annex §4.2
Backup, safeguarding and redundancy management. For the purposes of Article 21(2)(c) of Directive (EU) 2022/2555, the relevant entities shall make backups and provide for sufficient resources, including facilities, network and information systems, and personnel, to ensure an appropriate level of redundancy.
Because this is a regulation (not a directive), it is directly binding EU law. No national transposition needed. §4.2 has six numbered subsections covering the backup plan, integrity tests, redundancy, resource monitoring and recovery tests. It applies to DNS providers, cloud providers, data centres, MSPs, trust services and the other sectors listed in the CIR Annex.
§30(2)(3) BSIG (Germany)
Aufrechterhaltung des Betriebs, wie Backup-Management und Wiederherstellung nach einem Notfall, und Krisenmanagement.
Germany copies the EU text word for word. The German transposition points at IT-Grundschutz building blocks CON.3 (Datensicherungskonzept) and DER.2.3 (Wiederherstellung) as the practical route to implementation.
Write the six-point backup plan
Based on your risk assessment and BCP, write down: (a) recovery times, (b) how you ensure backups are complete and accurate including configuration data and cloud-stored data, (c) where backups sit (online or offline) at one or more secure locations, not in the same network as the primary system, far enough away that a primary-site incident does not take them down, (d) physical and logical access controls scaled to the asset's classification, (e) how recovery from backups actually runs, (f) retention periods per business and regulatory requirements.
Test integrity and recovery on a cadence
§4.2.3 requires regular integrity tests of the backups themselves. §4.2.6 goes further: regular tests of the actual recovery process. Verify that recovery is reliable, that all copies and procedures work, and that the people who would run the recovery still have the knowledge to do it. Document the results. Take corrective action when a test fails.
Build redundancy across four resources
Based on your risk assessment and BCP, ensure at least partial redundancy of: (a) network and information systems, (b) assets and values including sites, equipment and consumables, (c) personnel with the required responsibility, authority and competence, (d) communications channels. Backup is about data. Redundancy is about everything else you need to keep operating.
Backups and redundancy together
CIR §4.2 names both in the same section title: 'Backup, safeguarding and redundancy management'. Backups protect data so you can rebuild from a known-good copy. Redundancy protects operations so you do not stop in the first place. Both belong in the plan. A team that has backups but no redundancy gets back the data and still cannot operate.
Tested, not just taken
§4.2.6 specifically requires regular recovery tests, not just regular backups. A backup nobody has restored from is not a recovery capability, it is a hope. The auditor will ask when you last did a full restore, who ran it, what failed, and what you fixed afterwards. If the answer is 'at setup, three years ago', you have a finding.
BSI / IT-Grundschutz CON.3 + DER.2.3
The BSI's IT-Grundschutz has two building blocks that map directly onto CIR §4.2. CON.3 'Datensicherungskonzept' covers the backup concept itself (what gets backed up, how often, where the copies sit, retention). DER.2.3 'Notfallwiederherstellung der IT' covers the recovery side (procedures, roles, restoration testing). Together they give you the §4.2 evidence package in language a German auditor reads every day.
ENISA Technical Implementation Guidance
ENISA's TIG takes the abstract §4.2 text and shows you what to do in practice for each subsection. It also maps the requirement onto ISO/IEC 27001:2022 Annex A.8.13 (information backup) and A.8.14 (redundancy of information processing facilities). Existing ISO 27001 controls give you a head start on §4.2 evidence.
National transposition laws
Every member state transposes Article 21(2)(c) into its own law (Netherlands: Cyberbeveiligingswet, Austria: NISG, Belgium: NIS2-Wet). The duties are the same because the directive sets one EU-wide standard. What differs: which national agency you answer to and how they run inspections.
We run nightly backups, so we are covered.
Nightly backups are necessary, not sufficient. §4.2.2(c) wants them stored off-site, not on the same network as the primary system, and far enough away that a single incident cannot take both out. §4.2.2(f) wants documented retention periods, not 'we keep them until the disk fills up'. §4.2.6 wants a regular recovery-test cadence with documented results. The auditor will ask for all three. 'We have backups' answers one of them.
We tested recovery once when we set up the system.
§4.2.6 says regular tests, not one-time tests. A test from three years ago does not prove that today's backup format, today's restore procedure, and today's people still work together. Pick a cadence (quarterly or biannually for critical systems, annually for the rest), write it into the plan, run it, document each test.
We back up the data; the configs we can rebuild from scratch.
No. §4.2.2(b) explicitly requires the backup to be complete and accurate, 'including configuration data, including data stored in cloud computing environments'. A database without the application configuration, firewall rules and identity provider settings is not a recoverable system, it is a pile of records you cannot get to. The plan has to cover configs and cloud-stored data, not just the production tables.
What we see in practice: most Mittelstand has backups. Most has nightly jobs running to a NAS or to a cloud bucket. What they typically lack is the documented §4.2.2 plan with recovery times per system, the named off-site storage location, the physical and logical access controls in writing, the retention periods per system and regulator, and the recovery-test schedule. The backup job exists; the plan around it does not.
The fix is small. Write the §4.2.2 six-point plan once, sign it off, and put a recovery test on the calendar (quarterly for critical systems, biannually or annually for the rest). After the first test cycle, you have the evidence package the regulation asks for. The hard part is not the technology. The hard part is having the plan on paper and the test on the calendar.
The BCP module captures the §4.2.2 six-point backup plan, the recovery test schedule, the redundancy register for network, assets, personnel and communications, and the recovery-test results with sign-off. One module covers §4.2.2 through §4.2.6.
Tests are scheduled tasks, not free-text reminders. When a recovery test runs, the result, the gaps, and the corrective actions are captured against the same record. The audit trail then answers 'when did you last test recovery, what failed, what did you do about it' in one click. No separate test log to maintain.
- Directive (EU) 2022/2555 (NIS 2), Article 21(2)(c) — eur-lex.europa.eu/eli/dir/2022/2555/oj
- Commission Implementing Regulation (EU) 2024/2690 (CIR), Annex §4.2 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- BSI Act (BSIG), §30(2)(3) as amended by the NIS2 Implementation and Cybersecurity Strengthening Act
- BSI IT-Grundschutz Baustein CON.3 'Datensicherungskonzept' — bsi.bund.de/grundschutz
- BSI IT-Grundschutz Baustein DER.2.3 'Notfallwiederherstellung der IT' — bsi.bund.de/grundschutz
- ENISA Technical Implementation Guidance for CIR (EU) 2024/2690 (as of May 2026)