What Is the NIS2 Directive?

NIS2 — Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union — is the European Union's modernized cybersecurity framework. It replaces the 2016 NIS Directive and expands cybersecurity obligations to a much broader set of organizations: roughly 160,000 entities across 18 sectors of the EU economy. NIS2 entered into force on January 16, 2023 with a transposition deadline of October 17, 2024, after which national NIS2 laws began applying across member states.

Where the original NIS Directive treated cybersecurity as a sectoral issue for a small group of critical infrastructure operators, NIS2 treats it as a horizontal economic risk. Every "essential" or "important" entity in the regulation's scope — from energy and transport to manufacturing, food production, postal services, and digital infrastructure — must now meet a harmonized baseline of cybersecurity controls, incident reporting, and management accountability, with sanctions designed to be felt at board level.

NIS2 Defined

NIS2 is a Directive, not a Regulation. That distinction matters. A Directive sets binding outcomes but leaves member states to transpose them into national law, which means the operational text NIS2-regulated entities follow is the national act in each country they operate in — Germany's NIS2UmsuCG, Czechia's Act on Cybersecurity, Spain's Royal Decree, and so on. Cross-border groups must reconcile multiple national transpositions with sometimes meaningful differences in fine ranges, sector lists, and registration procedures, even though the underlying directive is shared.

The directive is supervised by national Computer Security Incident Response Teams (CSIRTs) and competent authorities designated by each member state, with EU-level coordination through the NIS Cooperation Group and ENISA (the European Union Agency for Cybersecurity). Cross-border incidents and supervisory cases are coordinated through CyCLONe, the EU's Cyber Crisis Liaison Organisation Network.

Who NIS2 Applies To

NIS2 covers two categories of regulated entities — essential and important — distinguished by sector criticality, size, and impact potential. Both categories share the same core obligations; the difference is supervisory intensity (essential entities are subject to ex-ante and ex-post supervision; important entities mostly to ex-post supervision) and penalty ceilings.

Sectors of high criticality (essential entities by default if above size thresholds):

• Energy (electricity, gas, oil, district heating, hydrogen)
• Transport (air, rail, water, road)
• Banking and financial market infrastructures
• Health (healthcare providers, EU reference labs, medical device manufacturers of critical devices, pharmaceutical companies)
• Drinking water and waste water
• Digital infrastructure (DNS, TLD registries, cloud, data centers, CDNs, trust services, public electronic communications)
• ICT service management (managed service providers, managed security service providers)
• Public administration entities
• Space

Other critical sectors (important entities by default):

• Postal and courier services
• Waste management
• Manufacture, production and distribution of chemicals
• Production, processing and distribution of food
• Manufacturing of medical devices, computers and electronics, machinery, motor vehicles, and other transport equipment
• Digital providers (online marketplaces, search engines, social platforms)
• Research organizations

Size thresholds matter. The default rule is that medium and large entities (50+ employees or €10M+ turnover) in scoped sectors are covered. Member states can extend scope downward to smaller entities deemed critical. The result is much wider coverage than the original NIS Directive — pulling in companies that have not historically been treated as critical infrastructure.

Core Obligations

NIS2 imposes a comprehensive set of cybersecurity risk management obligations. Article 21 lists ten minimum measures that essential and important entities must implement and document:

1. Policies on risk analysis and information system security — Formal, board-approved policies covering the entity's cyber risk posture.
2. Incident handling — Documented procedures for detection, containment, eradication, recovery, and post-incident learning.
3. Business continuity — Backup management, disaster recovery, crisis management, and tested resumption procedures.
4. Supply chain security — Risk assessment and contractual controls covering ICT suppliers and service providers, considering both technical vulnerabilities and the cybersecurity maturity of providers.
5. Security in network and information system acquisition, development, and maintenance — Secure development lifecycle, vulnerability handling and disclosure processes.
6. Policies and procedures to assess effectiveness — Periodic audits and assessments of cyber risk management measures.
7. Basic cyber hygiene practices and cybersecurity training — For all personnel, including management bodies.
8. Cryptography and encryption — Policies governing the use of cryptography to protect data and communications.
9. Human resources security, access control policies, and asset management — Including documented inventories of network and information assets.
10. Multi-factor authentication, secured voice/video/text communications, and secured emergency communications — Where appropriate to the risk.

Several of these obligations — supply chain security, secure development, asset management, access control — are explicitly governance and inventory problems. They cannot be satisfied by purchasing endpoint protection software. They require an organization to know what systems and data it has, who manages them, and how they are connected to suppliers and customers.

Incident Reporting Timeline

NIS2 imposes one of the strictest incident reporting cadences in EU regulatory practice. For any significant incident — one with substantial operational disruption, material loss, or significant impact on others — entities must follow a four-stage reporting process:

1. Early warning — within 24 hours of becoming aware of the incident, with an initial assessment of whether the incident is unlawful or malicious, and its possible cross-border impact.
2. Incident notification — within 72 hours, updating the early warning with an indication of severity, impact, and indicators of compromise.
3. Intermediate report — at the request of the CSIRT or competent authority, providing relevant status updates.
4. Final report — within one month of the incident notification, including detailed description of the incident, severity, likely cause, mitigation measures applied or ongoing, and any cross-border impact.

Hitting these deadlines is operationally demanding. Within 24 hours of detecting an incident, the entity must already understand what was affected and whether the impact spreads to other parties — a capability that depends entirely on having an accurate picture of systems, data flows, and dependencies before the incident, not constructed under fire.

Penalties and Management Liability

NIS2 substantially raises the financial and personal stakes of cybersecurity non-compliance:

• Essential entities — administrative pecuniary penalties up to €10 million or 2% of total worldwide annual turnover in the preceding financial year, whichever is higher.
• Important entities — up to €7 million or 1.4% of total worldwide annual turnover, whichever is higher.
• Personal liability for senior management — competent authorities can suspend certifications and authorizations, and impose temporary bans on individuals in management roles from exercising managerial functions, in cases of serious or repeated non-compliance.

The personal liability provisions are a notable departure from prior EU cybersecurity regimes. NIS2 makes management bodies accountable for approving cyber risk management measures, overseeing their implementation, and receiving training. Failure to meet these obligations is not a delegable IT failure — it is a board-level governance failure with consequences for the individuals on the board.

NIS2 and Data Governance

It is tempting to read NIS2 as a pure cybersecurity regulation — endpoint protection, MFA, encryption, incident response. That reading misses the structural dependency NIS2 has on data and asset governance. The Article 21 measures are operable only if the entity can answer foundational questions about its own digital estate:

• What network and information assets do we have? Article 21(2)(i) explicitly requires asset management — and Articles 21(2)(d) and (e) require supply chain and acquisition controls that presume an inventory exists. A data catalog covering systems, datasets, and integrations is the operational answer.
• What data flows where, and through whom? Supply chain security obligations require visibility into how data moves to and from third parties. Data lineage across systems and suppliers turns this from a documentation project into a queryable view.
• Who owns each asset? Incident response within 24-hour deadlines requires immediate accountable parties for each affected system. Documented data ownership turns "who knows about this?" into a lookup rather than a meeting.
• What is sensitive or critical? Risk-based controls and incident classification require classification metadata — distinguishing systems supporting essential services from supporting workloads, and personal data from non-personal.
• What suppliers process what data? NIS2 supply chain provisions echo DORA's third-party register obligations. A maintained supplier register tied to the data and systems each supplier touches is the substrate for both.
• How can we prove what we knew and when? Audit trails on catalog and classification changes are the evidence supervisors will ask for during inspections.

Organizations that have built data governance for analytics, AI readiness, or GDPR compliance find that the same infrastructure largely satisfies NIS2's inventory and supplier-related obligations. Organizations that have not are now building it under deadline pressure, often duplicating effort across cyber and data teams.

NIS2 vs DORA vs GDPR

NIS2 sits in a dense overlapping field of EU regulation. Understanding the relationships avoids both gaps and duplication:

• NIS2 vs DORA — DORA is lex specialis for financial entities. Where DORA and NIS2 would apply to the same entity, DORA's more specific requirements prevail and the entity is treated as DORA-regulated. Financial entities in DORA scope therefore are not separately NIS2-regulated for the same obligations, though they may still be relevant to NIS2's cross-sector coordination provisions.
• NIS2 vs GDPR — GDPR governs personal data protection; NIS2 governs cybersecurity and operational resilience. They overlap when an incident affects personal data — in which case both regimes' incident reporting obligations apply in parallel. The 72-hour GDPR breach notification and the 72-hour NIS2 incident notification run on the same clock but to different authorities and with different content. Mature incident response procedures must serve both.
• NIS2 vs CRA (Cyber Resilience Act) — CRA imposes cybersecurity requirements on products with digital elements placed on the EU market. NIS2 governs the entities that operate digital systems. A NIS2-regulated entity buying CRA-regulated products is the typical configuration.

The practical implication is the same as for DORA: build the data governance and asset management infrastructure once, with a multi-regime model in mind, and serve each regulator with the right view of the same underlying truth.

Conclusion

NIS2 is the most consequential EU cybersecurity regulation in a decade — both because of who it applies to and because of how it treats management accountability. The organizations that struggle most under NIS2 are those that try to satisfy it from inside the security team alone: buying tools, writing policies, and treating cyber risk as a technology problem. The organizations that handle it well treat NIS2 as a governance challenge that runs across security, data, supplier management, and the board itself. The data governance infrastructure — catalog, lineage, classification, ownership, audit trail — is the same in either case. The difference is whether it exists before NIS2 comes asking, or is built in parallel with the next incident response.