NIS2 backup and business continuity requirements: what Article 21(2)(c) asks for, point by point

NIS2 backup requirements: what Article 21(2)(c) says

NIS2 covers backups in Article 21(2)(c) of Directive (EU) 2022/2555. The provision lists “business continuity, such as backup management and disaster recovery, and crisis management” among the measures that essential and important entities must take as a minimum. The directive names these measures and sets no number of copies, backup frequency or test interval. The technical detail is in section 4 of the Annex to Commission Implementing Regulation (EU) 2024/2690. That section covers a business continuity and disaster recovery plan (point 4.1), backup and redundancy management (point 4.2) and crisis management (point 4.3). Section 13, on environmental and physical security, also refers to point (c).

Article 21(1) asks for “appropriate and proportionate” measures, weighed against the entity’s exposure to risks, its size and the likelihood and severity of incidents. Article 21(2) bases the measures on an “all-hazards approach”. ENISA’s guidance on point 4.1.1 names fire, flooding and human error among the events to plan for. Point (f) requires “policies and procedures to assess the effectiveness” of the measures. For backups, in our reading, that assessment rests on documented restore tests. Our overview of the ten security measures of NIS2 Article 21 covers the other points.

Who the implementing regulation binds, and who can use it

The Regulation binds the “relevant entities” of its Article 1: DNS service providers, TLD name registries, cloud computing service providers, data centre service providers and content delivery network providers. The list also includes managed service providers, managed security service providers, providers of online marketplaces, online search engines and social networking services platforms, and trust service providers. For them, Article 2(2) adds a documentation rule. Where the Annex says “where appropriate”, “where applicable” or “to the extent feasible” and the entity does not apply an item, it has to document its reasoning “in a comprehensible manner”.

For other essential and important entities the Regulation is not binding. ENISA’s Technical Implementation Guidance, version 1.0 of June 2025, was written for the relevant entities. The guidance says that beyond them its indications on the NIS2 measures “may be considered useful by other public or private bodies for improving their cybersecurity”. For other organisations, the Annex and ENISA’s examples of evidence can serve as a detailed EU-level reference. Whether your company is an essential or important entity, and which text binds it, is a legal assessment for your legal department.

Point 4.1: the business continuity and disaster recovery plan

Point 4.1.1 requires a business continuity and disaster recovery plan “to apply in the case of incidents”. Point 4.1.2 bases the plan on the risk assessment and lists eight contents to include where appropriate. Our article on why backup is not disaster recovery checks a plan against them. For item (e), the order of recovery, ENISA names criteria such as asset classification, recovery objectives, resource availability and dependencies, where “services or assets that are essential for others are restored first”.

Under point 4.1.3, the entity carries out a business impact analysis and derives continuity requirements from it. ENISA’s guidance lists recovery time objectives (RTO), recovery point objectives (RPO), service delivery objectives and the maximum tolerable period of disruption. The guidance notes that “RTOs, RPOs and SDOs may be used to determine backup and redundancy procedures”. It names a “Documented BIA with specific recovery objectives” as evidence. For the IT team the result is a tier list with an RTO and an RPO per system. The RPO sets how often each system is backed up or replicated, the RTO how fast it has to come back.

Point 4.1.4 requires the plans to be “tested, reviewed and, where appropriate, updated at planned intervals” and after significant incidents or changes, with lessons learnt built in. ENISA’s guidance on this point advises testing, reviewing and, if necessary, updating the plans “at least annually”. Its examples of evidence include “Documented plans or schedules for future tests”, records of previous tests and logs of plan activation with “decisions taken, steps followed and final recovery time”. It also recommends keeping the plans “easily accessible during a system outage”, for example as physical copies. A plan kept only on the file server it describes is unavailable when that server is down.

Point 4.2: backup and redundancy management, item by item

Point 4.2.1 requires backup copies of data and “sufficient available resources, including facilities, network and information systems and staff”. Point 4.2.2 requires backup plans based on the risk assessment and the continuity plan. The table pairs each item with a technical control and the evidence ENISA lists.

Implementing Regulation (EU) 2024/2690, Annex points 4.2 and 11.2.2(e) (register of access rights); ENISA Technical Implementation Guidance v1.0 (June 2025), examples of evidence for section 4.2. The control column, and which example goes with which item, are our reading.

Item (b) covers more than VM backups. Its wording “configuration data and data stored in cloud computing service environment” brings firewall and switch configurations, the hypervisor management appliance, the backup server’s own configuration and SaaS mailboxes and file shares into the plan. Item (c) accepts copies “(online or offline)” and gives no distance in kilometres. For point 4.2.4, ENISA’s examples include multiple internet service providers, spare equipment, job rotation and backup assignments for staff. A backup administrator without a trained deputy is a single point of failure.

Our cyber resilience assessment reviews infrastructure, access and backups, including compliance with NIS2 requirements, and ends with a risk map and a prioritised action plan. Send us your backup plan and where each copy is stored through the form below.

Copies outside the production network: access, immutability and logs

Outside section 4, point 6.8.2(h) on network segmentation asks entities to “separate the production systems for the relevant entities’ services from systems used in development and testing, including backups”. Point 3.2.3(f) lists “access or changes to critical configuration and backup files” among the events to log where appropriate. Point 3.2.5 requires logs to be backed up for a predefined period and protected “from unauthorised access or changes”. ENISA ties their retention and access control to items (f) and (d) of point 4.2.2.

In a backup design these points lead to three controls. The repository sits in its own network zone, reachable from production only on the ports the backup traffic needs. Backup servers and repositories do not accept production directory accounts, so a stolen domain administrator password does not open them. Administration uses separate accounts with multi-factor authentication, in line with point 11.3.2 on privileged accounts. Deleting a restore point, shortening retention or disabling a job is logged to a store the backup administrators cannot edit.

Section 4 does not use the word immutable. A copy that no account can delete or alter until its lock expires covers the case items (c) and (d) leave open, an attacker with valid backup administrator credentials. Our article on what immutable backup protects against covers the mechanics and the lock window. In the 3-2-1-1-0 backup rule such a copy can serve as the second 1. The tips at the end of ENISA’s section 4.2 add “Protect backup and restoration hardware and software” and advise keeping encryption keys apart from the backup data.

Restore tests: point 4.2.6 and the effectiveness check of Article 21(2)(f)

Point 4.2.6 requires “regular testing of the recovery of backup copies and redundancies”, covering “the copies, processes and knowledge to perform an effective recovery”, with the results documented and corrective action taken where needed. A restore that only the backup administrator can perform tests the copies. A deputy following the written runbook also tests the process and the knowledge. In its guidance on integrity checks (point 4.2.3), ENISA advises having restored data “validated by business users” and testing scenarios from full system restores to individual file recoveries. Its example frequency for point 4.2.6 reads “Data with high criticality might be checked on a weekly basis”, with monthly checks for moderate and low criticality and a check right after significant changes.

Section 7 of the Annex details Article 21(2)(f). Point 7.2 asks the entity to determine what is measured, how, when and by whom, and when and by whom the results are analysed. For restore tests, the measurements are the restore time against the RTO and the age of the restored data against the RPO. The method is a timed restore into an isolated network on a calendar per tier. Someone outside the backup team, such as the security lead, evaluates. For a failed test the evidence is the corrective action with its owner, date and retest. Article 21(4) asks for corrective measures “without undue delay” where an entity finds that it does not comply. Our guide to disaster recovery testing covers the test types.

Our disaster recovery service runs failover tests in an isolated environment and reports after each test what came up, how fast and what to fix. Tell us which systems you would restore first and how you test them today.

Point 4.3: crisis management

Point 4.3 requires a crisis management process with roles and responsibilities “for personnel and, where appropriate, suppliers and service providers”. The process also includes communication means with the competent authorities, covering obligatory communications “such as incident reports and related timelines” and non-obligatory ones, and measures that keep systems secure in a crisis. Point 4.3.3 adds a process for using information from CSIRTs or competent authorities. Point 4.3.4 requires the crisis management plan to be tested, reviewed and, where appropriate, updated on a regular basis or following significant incidents or changes.

As controls, that means a named deputy for each crisis role and a contact list kept on paper and on a device outside the production directory. The list includes the CSIRT or competent authority and the backup and recovery-site providers. A second communication channel keeps the crisis team reachable when mail and chat are down, in line with the “multiple communication platforms” ENISA lists for point 4.2.4. The obligatory communications include the early warning within 24 hours and the incident notification within 72 hours of becoming aware of a significant incident under Article 23(4). The plan therefore names who drafts and approves them. For point 4.3.2(c), emergency accounts are sealed, use a second factor that still works when the production directory is down, and are logged when used.

When a provider runs the backup or the recovery site

A provider may run the off-site copy or the recovery site. For that case, ENISA’s guidance on point 4.2.2 says “it should be clearly decided whether it is the entity’s responsibility to compile the backup plans or if the third parties have any involvement in the process”. It also advises reviewing dependent third parties’ recovery plans and involving suppliers in tests (points 4.1.4 and 4.2.6). It lists the provider’s service level agreements as evidence. The contract should therefore state the recovery targets, the tests and who writes which part of the plan. The provider’s test reports go into your evidence file.

General information on EU law as of October 2026, not legal advice for an individual case.

What we do

Under our cyber resilience service, our engineering partner Vixen.UNO reviews security and backup, including compliance with NIS2 requirements. Vixen.UNO delivers a NIS2 compliance map, a technical assessment that lists the gaps and a plan to close them. Backup is Veeam-based, with regular test restores to verify backup integrity and a recovery site in Baltneta’s Tier-3 data centres in Lithuania. Under our disaster recovery service we define critical systems, target RPO and RTO per tier and the disaster scenarios with you. The output is a continuity plan, with RPO and RTO fixed in the SLA. The first call is free of charge; the price of the technical assessment is fixed before work begins.

FAQ