NIS2 backup requirements: what you actually have to do
In short: NIS2 requires essential and important entities to have backup management and disaster recovery as part of their cybersecurity risk measures (Article 21(2)(c)). For digital infrastructure and digital service providers, Implementing Regulation (EU) 2024/2690 spells it out: documented backup plans, backups stored separately from the main network, regular integrity checks, and regular tests that restores actually work, with documented results and corrective action.
This is practical guidance, not legal advice. Your national law and supervisory authority have the final word.
Who this applies to
NIS2 (Directive (EU) 2022/2555) covers "essential" and "important" entities in sectors such as energy, transport, health, banking, digital infrastructure, ICT service management, manufacturing and digital providers, generally from medium-sized companies upward. Each EU country implements it through its own law; Sweden's Cybersecurity Act (Cybersäkerhetslagen, SFS 2025:1506), for example, took effect on 15 January 2026. Check your country's law and register for which entities are in scope.
What Article 21 says about backups
Article 21(2) lists the minimum cybersecurity risk-management measures. Point (c) is business continuity, such as backup management and disaster recovery, and crisis management. The directive itself doesn't go into more detail; that comes from implementing acts and national rules.
The detailed rules: Implementing Regulation (EU) 2024/2690
For DNS providers, TLD registries, cloud computing, data centre, content delivery network, managed service and managed security service providers, online marketplaces, search engines, social networks and trust service providers, the Commission's implementing regulation sets binding technical requirements. Point 4.2 of its annex covers backup and redundancy management. Paraphrased:
| Point | Requirement |
|---|---|
| 4.2.1 | Keep backup copies of data, and enough resources (facilities, systems, staff) for appropriate redundancy. |
| 4.2.2 | Set backup plans, based on your risk assessment and business continuity plan, covering: recovery times; that backups are complete and accurate (including configuration data and data in cloud services); storing copies in a safe location separate from the main network and far enough away to survive a disaster at the main site; access controls; how data is restored; and retention periods. |
| 4.2.3 | Perform regular integrity checks on backup copies. |
| 4.2.4–4.2.5 | Ensure at least partial redundancy of systems, facilities, people and communication channels. |
| 4.2.6 | Regularly test that backups and redundancies can be relied on for recovery, document the results, and take corrective action where needed. |
Point 4.1.4 adds that business continuity and disaster recovery plans are tested, reviewed and updated at planned intervals and after significant incidents. Entities not listed above aren't bound by this regulation, but it's the clearest statement of what "backup management" means under NIS2, and auditors and national authorities use it as a reference.
What the law does not say
Plenty of vendor blogs claim NIS2 "mandates" specific setups. The regulation text doesn't require:
- Immutable or air-gapped backups. It requires separate, protected storage; immutability is one good way to achieve that, not a named requirement.
- The 3-2-1 (or 3-2-1-1-0) rule. A sensible practice, not law.
- A fixed test frequency. Tests must be "regular"; how often follows from your risk assessment. Write the frequency into your policy, then stick to it.
A practical checklist
- Backup plan: what's backed up, how often, retention, where copies are stored (separate from production), who has access. Our free backup policy generator produces a starting document mapped to NIS2.
- Recovery objectives: recovery time and recovery point targets per system, from your business continuity plan.
- Integrity checks (4.2.3): automated checks that each backup is complete and readable, not just that the job ran. See the backup verification checklist.
- Restore tests (4.2.6): regular restores of real backups into an isolated environment, with the data verified. For PostgreSQL, our restore testing guide includes a script.
- Records: keep a record of every test and every fix. That record is your evidence for the authority or auditor. See what auditors expect and a sample evidence report.
- Plan tests (4.1.4): at least yearly, a full recovery exercise following your runbook.