NIS2 DORA Backup Requirements: What Auditors Will Ask

In a 2024 Sophos survey of 2,974 organizations hit by ransomware, 94 percent said the attackers tried to compromise their backups during the attack (Sophos, 2024). The survey, run by Vanson Bourne for Sophos in early 2024, covered organizations that had been hit by ransomware in the previous twelve months. Backups are the recovery plan, so they are a prime target. EU law now treats them accordingly, and the NIS2 DORA backup requirements turn “we have backups” from a reassurance into something an organization must be able to prove.

Proving it is the hard part. NIS2 reaches essential and important entities across the sectors in its annexes, including banking, health, transport, and digital infrastructure such as cloud and data centre providers. NIS2 lists backup management among the mandatory cybersecurity risk-management measures. DORA, which has applied to financial entities since 17 January 2025, goes further and prescribes backup policy content, periodic testing, and restoration on segregated systems. Neither text asks whether a backup job reported success. Both ask whether the organization can recover, and whether it can show how it knows.

This blog reads the legal text, the NIS2 implementing rules, and ENISA’s technical guidance, then translates them into storage design decisions and the evidence an auditor or supervisor will request. It also covers the reporting clocks and penalties that raise the stakes, and the gaps that fail reviews even when every backup job reports success.

What NIS2 and DORA Say About Backup, Restoration, and Recovery Evidence

NIS2 Article 21: Backup Management Written Into the Mandatory Risk Measures

NIS2 is Directive (EU) 2022/2555. Article 21(2) lists the minimum measures that essential and important entities must take, and point (c) names “business continuity, such as backup management and disaster recovery, and crisis management” (European Union, 2022a). The same list covers policies to assess whether the measures work (point f), cryptography and encryption (point h), access control and asset management (point i), and multi-factor or continuous authentication (point j).

The directive itself is principles-based: measures must be appropriate and proportionate to the risk, and the directive text alone does not say how often to test or where to keep a copy. That detail sits in implementing acts.

Where NIS2 Gets Specific: Implementing Regulation 2024/2690 and ENISA Guidance

Commission Implementing Regulation (EU) 2024/2690 supplies that detail for DNS providers, TLD registries, cloud computing and data centre service providers, content delivery networks, managed service providers, managed security service providers, online marketplaces, search engines, social networking platforms, and trust service providers (European Commission, 2024). Point 4.2 of its annex covers backup and redundancy management. Backup plans must define recovery times and assurance that copies are complete and accurate. They must store copies, online or offline, in a safe location that is “not in the same network as the system” and at sufficient distance to escape a disaster at the main site. They must also apply physical and logical access controls and set retention periods.

Two more points matter to anyone preparing for review. Point 4.2.3 requires regular integrity checks on backup copies. Point 4.2.6 requires regular testing of recovery from backup copies, with documented results and corrective action where needed. ENISA’s June 2025 technical implementation guidance adds examples of the evidence it expects, including backup plans, backup software logs, proof of physical separation, off-site copy reports, and test reports showing that recovery times were met (ENISA, 2025). Entities outside the listed provider types answer to their national law, but this text is a sensible benchmark for them as well.

DORA Article 12: Documented Backup Policy, Periodic Testing, and Segregated Restoration

DORA is Regulation (EU) 2022/2554, and Article 12 is the most explicit backup text in EU law. Financial entities must document backup policies that specify the scope of data and the minimum backup frequency, based on the criticality or confidentiality of the data. They must set up backup systems that can be activated without jeopardizing the security of the network or the availability, authenticity, integrity, or confidentiality of data. Testing of the backup and restoration procedures “shall be undertaken periodically” (European Union, 2022b).

Article 12(3) adds the requirement with the biggest architectural consequence. When restoring from backup using their own systems, financial entities must use ICT systems that are physically and logically segregated from the source system. Article 12(4) requires entities other than microenterprises to maintain redundant ICT capacity adequate for business needs.

Which Law Applies to Whom: Scope, Entity Types, and Supplier Pull-Through

DORA applies to credit institutions, payment institutions, investment firms, insurance undertakings, central counterparties, crypto-asset service providers, and ICT third-party service providers, among others (Article 2). NIS2 covers entities in the sectors listed in its annexes, and the European Commission describes it as applying, as a rule, to medium-sized and large entities in 18 critical sectors (European Commission, NIS2 policy page). National transposition has been uneven, so confirm the status in each member state where you operate.

Supply chain security is itself an NIS2 measure under Article 21(2)(d), and Article 21(3) tells entities to weigh the cybersecurity practices of their direct suppliers. A storage or backup vendor selling into either regime should expect procurement questions about its own security posture, not just the customer’s configuration.

Reporting Clocks, Recovery Objectives, and Penalties That Make Backup Integrity a Board Issue

NIS2 Article 23: 24-Hour Early Warning, 72-Hour Notification, and One-Month Final Report

Article 23(4) sets a staged schedule for significant incidents. An early warning is due without undue delay and within 24 hours of becoming aware of the incident. An incident notification with an initial assessment of severity and impact follows within 72 hours. A final report is due not later than one month after that notification, covering the root cause, the mitigation applied, and the impact.

A significant incident is one that has caused or can cause severe operational disruption or financial loss, or considerable damage to other people or organizations (Article 23(3)). A ransomware event that encrypts production systems will usually qualify. You cannot assess impact within 72 hours if you do not know whether the last clean restore point survived. Backup integrity is therefore a reporting dependency as well as a recovery one.

Recovery Objectives and Integrity Checks Under DORA Article 12(6) and 12(7)

Article 12(6) requires recovery time and recovery point objectives for each function, set with regard to whether the function is critical or important, and capable of meeting agreed service levels in extreme scenarios. Our guide on recovery time and recovery point objectives covers how to calculate and improve those figures.

Article 12(7) is easy to overlook. When recovering from an ICT-related incident, financial entities must perform the necessary checks, including multiple checks and reconciliations, so that the highest level of data integrity is maintained. A restore that completes but returns corrupted or reinfected data does not satisfy it.

Fines Under NIS2 Article 34 and Why Evidence Matters More Than the Fine

Article 34 requires member states to allow fines for infringements of Articles 21 and 23 of at least EUR 10 million or 2 percent of worldwide annual turnover for essential entities, whichever is higher, and at least EUR 7 million or 1.4 percent for important entities. These are minimum ceilings, so national law may allow more.

Beyond the fine, the practical risk is the finding itself, because a documented gap between a stated backup policy and the running configuration is easy for a supervisor to establish and hard to explain.

Turning NIS2 DORA Backup Requirements Into Storage Architecture Decisions

Requirement-to-Design Table: What Each Provision Means for the Backup Platform

The regulations never say “buy an immutable repository”. They state outcomes. The table maps those outcomes to design properties a backup platform needs to deliver them.

Isolating the Repository From the Production Network and Its Credentials

If the repository is mounted continuously on the production network, anyone who holds production administrator credentials can reach it. Point 4.2.2(c) of the implementing rules and ENISA’s evidence examples both point to separation. ENISA lists immutable backups, offline storage, and malware scanning of backups before they are stored as ways to protect backup integrity (ENISA, 2025), and describes them as examples rather than obligations. Our guide on why air-gapped backups and immutability are necessary explains the isolation model in more depth.

Segregated Restore Targets: What Physical and Logical Segregation Means in Practice

Restoring into the same hypervisor cluster, network segment, and identity domain that was just compromised is the situation Article 12(3) is aimed at. A segregated target has its own compute, its own network path, and its own authentication, so a restore does not hand the attacker back the data. Our post on building a clean room recovery path describes how to construct it.

Encryption Keys, Access Control, and Why Keys Must Not Live With the Backups

ENISA advises that encryption keys be stored separately from the backup data, so that encrypted backups stay recoverable and protected. DORA’s technical standard on ICT risk management (Commission Delegated Regulation 2024/1774, Article 7) requires a key management policy that covers storing and backing up keys across their lifecycle. A backup that cannot be decrypted because the only key copy sat on the failed system satisfies neither text.

What Evidence Auditors and Supervisors Expect for Backup Compliance

Backup Plans, Scope, Frequency, and Retention Tied to Data Criticality

DORA Article 12(1) makes a written policy mandatory, and the implementing rules require plans that set recovery times and retention periods from the risk assessment. Expect to be asked for the document and then shown whether the live configuration matches it. A policy that promises hourly protection for a core system while the job runs nightly is a documented gap.

Recovery Test Records: Frequency, Scenarios, and Documented Corrective Action

The implementing rules require regular recovery testing with documented results. ENISA gives an example of weekly checks for high-criticality data and monthly checks for moderate and low criticality, plus a check after significant changes, and it recommends testing both full-system restores and individual file recovery (ENISA, 2025). These are examples, not mandated intervals, so set your own from the risk assessment and record the reasoning. The evidence that satisfies both regimes is a dated record of what was restored, to which environment, how long it took, and what was fixed afterward.

Integrity Checks, Immutability Configuration, and Access Logs

A reviewer can reasonably ask whether anyone, including an administrator, can alter or delete a recovery point before its retention expires. Configuration evidence of immutable retention answers that question better than assurance does. Backup software logs and off-site copy reports, both listed by ENISA as examples of evidence, make up the core of the file, and access logs for the backup platform are a sensible addition.

Backup Compliance Gaps That Fail Audits Even When Backup Jobs Succeed

Repositories Reachable From Production: The Segregation Gap

A repository that production credentials can reach fails the intent of both DORA Article 12(3) and point 4.2.2(c). This is the most common design weakness, and it is invisible in a green dashboard.

Restores Never Tested End to End: The Evidence Gap

Backup jobs prove that data was written. Only a restore proves that it can be recovered, booted, and validated. Without dated test records, the testing obligation is unsupported.

Recovery Objectives Without Capacity to Meet Them: The Resource Gap

Holding the data is not enough if there is no compute to run it. A four-hour objective becomes a procurement project when the restore target does not exist, which is the gap Article 12(4) and point 4.2.4 of the implementing rules address.

Keys and Admin Credentials Inside the Failure Domain: The Dependency Gap

If the backup console shares an identity provider with production, or the encryption keys live on the system being restored, recovery depends on the very environment that failed.

How StoneFly DR365V Supports Air-Gapped and Immutable Backup Under NIS2 and DORA

No appliance makes an organization compliant. Compliance depends on policy, governance, testing discipline, and how the whole environment is run. What a backup platform can do is remove the architectural reasons an audit would fail and produce the evidence reviewers ask for. StoneFly DR365V is a Veeam Ready air-gapped and immutable backup and disaster recovery solution built around those objectives.

Air-Gapped Vault and Always On-Air Gapping for Repository Isolation

Air-Gapped Vault® is StoneFly’s patented automated air-gapped and immutable storage technology. Through Always On-Air® Gapping, Veeam jobs trigger StoneFly controls that attach the required repository, controller, or node only for an authorized backup or restore operation, then return it to its air-gapped and immutable state. That addresses the question of repository reachability directly.

Immutable Storage, Volume-Deletion Protection, and Access Controls

Protected data is shielded against modification, overwrite, encryption, and deletion through immutable FileLock and AWS-compatible S3 Object Lock with WORM retention. Built-in volume-deletion protection blocks attempts to delete protected repository volumes, adding a storage-level safeguard beyond backup-application permissions. StoneFly’s air-gapped and immutable file-based backup repositories are DISA STIGs compliant.

Recovery Compute, Instant Multi-VM Recovery, and Sandbox Testing

DR365V includes integrated recovery compute and instant multi-VM recovery, so recovery can run on the appliance itself. Its isolated on-demand sandbox lets teams verify that protected systems boot and operate, test applications and disaster recovery plans without touching production, and run unattended tests on daily, weekly, monthly, or custom schedules with reporting. Those reports are the dated test records described above, alongside malware scanning and quarantine for validating data before it returns to production.

What the Appliance Does Not Do: Compliance Remains an Organizational Program

DR365V does not write your backup policy, classify your data, set your recovery objectives, or decide your test frequency. It gives those decisions an architecture that enforces them and a record that proves them. To discuss how this maps to your own scope and supervisor, contact StoneFly.

Conclusion: Treat NIS2 DORA Backup Requirements as a Design Brief, Not a Paperwork Exercise

NIS2 puts backup management into the mandatory baseline, and its implementing rules and ENISA guidance supply the detail on isolation, integrity checks, and recovery testing. DORA Article 12 states the equivalent obligations directly, including segregated restoration and post-recovery integrity checks. The two regimes differ in scope and in precision, but they converge on the same four questions: is the backup isolated, is it protected from alteration, can you restore it somewhere safe, and can you prove that you tested it.

The path is the same under both regimes. Write the policy from your data classification, isolate the repository and the restore environment from production, enforce immutability at the storage layer, and test recovery on a schedule so the proof accumulates before anyone asks for it. Treated that way, NIS2 DORA backup requirements shape a better recovery architecture and not only a better audit file.

For related reading, see our guides on data sovereignty versus data residency, CMMC compliance, volume-deletion protection, and ransomware-resilient backup architecture.

Note: