NIS2 and storage are rarely mentioned in the same sentence of the directive, yet much of what the directive requires ends up being implemented in the storage layer. NIS2 is the European Union's directive on a high common level of cybersecurity, Directive (EU) 2022/2555. It obliges organizations in a long list of sectors to manage cyber risk through a defined set of measures, to report significant incidents on a fixed timetable and to hold their management accountable for both. Backup, recovery, encryption, access control and supplier security all appear in that set of measures.
This post looks at who is covered, which of the required measures touch storage and what evidence a storage team should expect to be asked for. It is a general overview and not legal advice. The directive is implemented through national laws that differ in detail.
The directive sorts organizations into essential and important entities, mainly by sector and size. Sectors include energy, transport, banking, health, drinking water, digital infrastructure, public administration, manufacturing of certain goods, postal services, waste management and digital providers. Medium and large organizations in those sectors are generally in scope without any designation step, which is the main change from the first NIS directive.
Member states had until 17 October 2024 to transpose the directive. Progress was uneven: by late May 2026, 23 of the 27 member states had done so. Germany's implementation law entered into force on 6 December 2025 and brings more than 30,000 companies into scope there. An organization operating in several countries therefore has to check the national law in each, not only the directive.
Article 21 of the directive lists the minimum risk management measures. They are written at a high level, and national laws and guidance add detail, but the mapping to storage is direct for several of them.
| NIS2 measure | What it asks for | Storage consequence |
|---|---|---|
| Business continuity | Backup management, disaster recovery and crisis management | Protected backup copies, tested restores, a second site |
| Incident handling | Detecting, containing and recovering from incidents | Logs that survive the incident, clean recovery points |
| Supply chain security | Security of relationships with direct suppliers | Questions to storage vendors on support access and updates |
| Cryptography | Policies on encryption where appropriate | Encryption at rest and in transit, key custody |
| Access control | Control of who can reach systems and data | Separate administrative accounts, least privilege |
| Multi-factor authentication | Stronger authentication where appropriate | MFA on storage and backup administration |
| Effectiveness assessment | Procedures to test whether measures work | Restore tests and isolation tests with records |
The directive names backup management and disaster recovery explicitly as part of business continuity. That turns backup from an operational practice into something a supervisory authority can ask about. The questions follow a predictable line: is there a backup policy, does it cover the systems that deliver the regulated service, are copies protected from the same incident that hits production, and has recovery been demonstrated.
Protection from the incident is where storage design matters most. A backup that an attacker with administrative credentials can delete does not support continuity. Immutability enforced by the storage platform, described in the post on backup deletion protection, addresses that, and backup isolation testing shows how to demonstrate it instead of asserting it. Demonstrated recovery means exercises with results, covered in ransomware recovery exercises.
A significant incident triggers a three-stage report: an early warning within 24 hours of becoming aware, an incident notification within 72 hours and a final report within one month. Those deadlines assume the organization can establish what happened quickly. Storage contributes two things. The first is evidence: access logs and audit logs from the storage platform, kept where an intruder cannot erase them. The post on S3 access logging at scale covers how to keep them usable. The second is a recovery estimate. The notification is expected to describe impact and mitigation, and an honest answer depends on knowing how long a restore of the affected service takes.
Supply chain security covers the organization's direct suppliers and service providers. For storage, the relevant questions are about the supplier's access and influence: can the vendor reach the system remotely and under what controls, where does telemetry go, how are software updates verified, and what happens to support if the relationship ends. The post on data sovereignty in procurement lists questions of this kind for tender documents. Storage operated by a service provider raises the same questions with more weight, because the provider's administrators hold the access.
The directive asks for policies on cryptography and, where appropriate, encryption. It does not prescribe algorithms. In practice a storage team is expected to show that data is encrypted in transit and at rest where the risk justifies it and that keys are managed deliberately. Who holds the keys matters as much as the encryption itself, which is the subject of the post on backup encryption keys. Access control and multi-factor authentication apply to the storage administration plane as to any privileged system.
Management bodies must approve the risk management measures and oversee their implementation, and they can be held liable for failures. Fines for essential entities reach up to 10 million euros or 2 percent of worldwide annual turnover, and for important entities up to 7 million euros or 1.4 percent. The practical effect is that backup and recovery status is now something boards ask to see, in language they can sign.
Scality RING is software-defined object and file storage that runs on standard x86 servers in the organization's own facilities. It exposes an S3 interface and supports versioning and S3 Object Lock, so backup copies and records can be held under retention that administrative credentials cannot shorten. RING is multi-tenant, with accounts, buckets and policy-based isolation, which supports separating the people who administer production from those who control protected copies.
RING can span multiple sites, with erasure coding and replication selectable per policy, and self-healing runs as a background task. Metrics and logs are kept locally, which keeps operational evidence inside the organization's boundary. Because the system is operated by the organization on its own hardware, the answers to supply chain questions about access and location are in its own hands.
NIS2 does not tell an organization which storage to buy. It asks for outcomes: continuity, recoverability, controlled access and proof. A storage layer that enforces immutability, records what happens to it and can be restored on a known timescale covers a large share of what the directive expects.