GRC

THE NIS2 DIRECTIVE - A Complete Article-by-Article Reference and Explanation

By Clateway Technology Council · 29 April 2026 · 44 min read

THE NIS2 DIRECTIVE

Directive (EU) 2022/2555

A Complete Article-by-Article Reference and Explanation

Measures for a high common level of cybersecurity across the Union

Adopted 14 December 2022 · Entered into force 16 January 2023 · Transposition deadline 17 October 2024

Clateway Insights

Regulatory Reference Series

The NIS2 Directive (Directive (EU) 2022/2555) is the European Union's flagship cybersecurity law. It replaces the original NIS Directive of 2016 and substantially expands both the population of regulated entities and the depth of obligations placed upon them. NIS2 was adopted on 14 December 2022, entered into force on 16 January 2023, and Member States were required to transpose it into national law by 17 October 2024, with national measures applying from 18 October 2024.

NIS2 pursues a single objective: to achieve a high common level of cybersecurity across the Union, thereby improving the functioning of the internal market. To do this, the Directive sets minimum rules covering national cybersecurity strategies, designation of competent authorities and CSIRTs, cooperation at Union level, cybersecurity risk-management and incident-reporting obligations for in-scope entities, supervision, and enforcement — including administrative fines that can reach EUR 10 million or 2% of worldwide annual turnover for essential entities.

This document provides a structured, article-by-article walkthrough of the entire Directive. For each article, the reader will find both a description of what the article says and an explanation of what it means in practice — for Member States, for management bodies, and for the security, risk and compliance functions inside in-scope organisations. It is written to be used as an internal reference: a single, navigable source of truth that translates the Official Journal text into operational understanding.

How to read this document

The Directive is organised into nine chapters and 46 articles, plus three annexes. This document follows that structure exactly. Each article block contains a Description (a faithful summary of the legal text) and an Explanation (the practical meaning, intent, and impact). Defined terms — essential entity, important entity, significant incident, near miss, CSIRT — carry specific legal meaning under the Directive and are used consistently throughout.

Chapter I — General Provisions

Chapter I sets the foundations: the subject matter and scope of the Directive, the relationship to sector-specific Union law, the principle of minimum harmonisation, and the definitions used throughout. These provisions determine who is in scope, who is out, and what key terms mean — questions every compliance project must answer before any control implementation begins.

Article 1 — Subject matter

Description

Article 1 states that the Directive lays down measures to achieve a high common level of cybersecurity across the Union, with the aim of improving the functioning of the internal market. It does so by requiring Member States to adopt national cybersecurity strategies and designate competent authorities, cyber crisis management authorities, single points of contact, and CSIRTs; by imposing cybersecurity risk-management measures and reporting obligations on entities listed in Annexes I and II as well as critical entities under Directive (EU) 2022/2557; by laying down rules on cybersecurity information sharing; and by setting supervisory and enforcement obligations on Member States.

Explanation

Article 1 frames NIS2 as an internal-market measure: cybersecurity is treated as a precondition for the free movement of digital services across the EU, not as a national-security carve-out. The four pillars introduced here — national capability, entity-level obligations, information sharing, and supervision/enforcement — recur throughout the rest of the text and should be used as the top-level structure for any NIS2 readiness programme.

Article 2 — Scope

Description

Article 2 defines who falls within the Directive. It applies to public or private entities of a type listed in Annex I or II that qualify as medium-sized enterprises under Recommendation 2003/361/EC, or that exceed those ceilings (the size-cap rule). Regardless of size, the Directive also applies to providers of public electronic communications networks or services, trust service providers, TLD name registries, DNS service providers, sole providers of an essential service in a Member State, entities whose disruption would significantly impact public safety/security/health or induce systemic risk, entities critical at national or regional level, central-government public administration entities, entities providing domain name registration services, and entities identified as critical under Directive (EU) 2022/2557. Member States may extend scope to local public administration and education institutions carrying out critical research.

Article 2 also lists carve-outs: it does not apply to public administration entities operating in national security, public security, defence or law enforcement; Member States may exempt specific entities active in those areas from Articles 21 and 23; financial entities exempted from Regulation (EU) 2022/2554 (DORA) by Member States are out of scope. Information disclosure that would harm essential national-security interests is not required, and the Directive applies without prejudice to GDPR, the ePrivacy Directive, and other listed instruments.

Explanation

This is the most consequential single article for scoping. The size-cap rule means that any organisation in an Annex I or II sector with 50+ employees or more than EUR 10 million turnover and balance sheet total is in scope by default — a vast expansion compared with NIS1's identification-driven approach. The 'regardless of size' triggers (sole provider, systemic risk, critical at regional level, central government, DNS/TLD/trust services) catch small but strategically important organisations that the size cap would otherwise miss. Compliance projects should produce a formal scoping memo that walks each criterion in turn and that documents reasons for inclusion or exclusion, because supervisory authorities will expect this trail.

Article 3 — Essential and important entities

Description

Article 3 establishes the two-tier classification. Essential entities include: Annex I entities exceeding the medium-sized enterprise ceilings; qualified trust service providers, TLD name registries and DNS service providers regardless of size; medium-sized providers of public electronic communications networks or services; central-government public administration entities; any entity identified by a Member State under Article 2(2)(b)–(e); entities identified as critical under CER; and, optionally, operators of essential services previously identified under NIS1. All other in-scope entities are important entities. By 17 April 2025, Member States must establish a list of essential and important entities (and entities providing domain name registration services), reviewed at least every two years, and entities must submit identifying information (name, address, contact details, sector, list of Member States served). Member States must notify aggregate numbers to the Commission and Cooperation Group.

Explanation

The essential/important distinction governs the supervisory regime (Articles 32 vs 33), the maximum administrative fine (EUR 10m / 2% vs EUR 7m / 1.4%), and the level of attention the entity should expect from regulators. Entities should determine their classification early because it changes the cost and shape of the compliance programme. Registration with the competent authority is itself an obligation — failure to register is itself a breach — and contact details must be kept current within two weeks of any change.

Article 4 — Sector-specific Union legal acts

Description

Where a sector-specific Union legal act imposes cybersecurity risk-management or incident-reporting obligations that are at least equivalent in effect to those in NIS2, those sectoral provisions apply instead, including their supervision and enforcement framework. Equivalence requires that risk-management measures be at least equivalent to Article 21(1) and (2), and that reporting requirements be at least equivalent to Article 23(1)–(6) with immediate (and where appropriate automatic and direct) access to notifications by the NIS2 competent authority. The Commission was required to publish guidelines clarifying application by 17 July 2023.

Explanation

Article 4 is the lex specialis bridge. Its most prominent application is DORA (Regulation (EU) 2022/2554) for financial entities: NIS2 obligations on risk management, reporting, supervision and enforcement do not apply to DORA-covered financial entities; DORA's equivalents do. Aviation entities likewise interact with Regulations (EC) 300/2008 and (EU) 2018/1139. Mapping which legal regime applies to which entity inside a financial group is itself a non-trivial exercise and is best resolved before risk-management programmes are designed.

Article 5 — Minimum harmonisation

Description

Member States may adopt or maintain provisions ensuring a higher level of cybersecurity than NIS2 prescribes, provided they are consistent with Union law.

Explanation

NIS2 sets a floor, not a ceiling. National transposition will diverge in detail — some Member States set lower fine thresholds, narrower or wider scope extensions to local public administration and education, additional reporting channels, or additional sector inclusions. Multinationals must build a comparison matrix of national transposition laws across the Member States in which they operate, rather than relying on the Directive text alone.

Article 6 — Definitions

Description

Article 6 sets out 41 numbered definitions used throughout the Directive. Key terms include: network and information system; security of network and information systems; cybersecurity (cross-referencing the Cybersecurity Act); near miss (an event that could have compromised availability, authenticity, integrity or confidentiality but did not); incident (an event that did compromise these properties); large-scale cybersecurity incident (one that exceeds a Member State's response capacity or significantly impacts at least two Member States); incident handling; risk; cyber threat; significant cyber threat; ICT product, service and process; vulnerability; standard; technical specification; internet exchange point; DNS, DNS service provider, TLD name registry, entity providing domain name registration services; trust service and provider, qualified trust service and provider; online marketplace; online search engine; cloud computing service; data centre service; content delivery network; social networking services platform; representative; public administration entity; public electronic communications network; electronic communications service; entity; managed service provider; managed security service provider; research organisation.

Explanation

The definitions deserve close reading because they operationalise scope. The introduction of 'near miss' is particularly important: NIS2 expects entities to recognise events that could have caused harm even when they did not, which raises the bar on detection and root-cause analysis. The cloud computing service definition deliberately captures IaaS, PaaS, SaaS and NaaS across private, community, public and hybrid models, and the data centre service definition captures non-cloud colocation. Managed service provider and managed security service provider are formally defined and brought directly within scope, anchoring supply-chain accountability. Where a definition cross-references another instrument (e.g. trust service to eIDAS, or cybersecurity to the Cybersecurity Act), the cross-referenced text is binding.

Chapter II — Coordinated Cybersecurity Frameworks

Chapter II places obligations on Member States to build the institutional infrastructure that NIS2 depends on: a national strategy, competent authorities, a single point of contact, a cyber crisis management authority, CSIRTs, a coordinated vulnerability disclosure framework, and national-level cooperation between all of the above.

Article 7 — National cybersecurity strategy

Description

Each Member State must adopt a national cybersecurity strategy setting out strategic objectives, resources required, and policy and regulatory measures. The strategy must address: objectives and priorities (covering the Annex I and II sectors), governance frameworks, asset identification and risk assessment mechanisms, preparedness/response/recovery measures, the list of authorities and stakeholders, coordination with the CER framework, and a plan to raise general cybersecurity awareness. It must include policies on supply-chain cybersecurity, public procurement cybersecurity requirements, vulnerability management and coordinated disclosure, sustaining the public core of the open internet (including undersea cables), advanced technologies, education and skills, support for academia and research, voluntary information sharing, support for SMEs excluded from NIS2 scope, and active cyber protection. National strategies must be notified to the Commission within three months of adoption and reassessed at least every five years.

Explanation

Article 7 elevates national cybersecurity from a policy aspiration to a structured deliverable. For multinationals it is a useful map: it tells you, per Member State, which authorities you will be dealing with, how supply-chain expectations are framed nationally, what active-cyber-protection services may be available for free, and what the SME baseline guidance looks like. National strategies are also where national choices on local public administration scope, education-sector inclusion, and undersea-cable mapping become explicit.

Article 8 — Competent authorities and single points of contact

Description

Each Member State must designate or establish one or more competent authorities responsible for cybersecurity and the supervisory tasks under Chapter VII, and a single point of contact (SPOC) for cross-border cooperation. Where there is only one competent authority, it doubles as the SPOC. Member States must give competent authorities and SPOCs adequate resources, notify the Commission of their identities and tasks, make the competent authority public, and the Commission publishes the SPOC list.

Explanation

The SPOC is the entity's primary cross-border interface. For organisations operating in several Member States, knowing each SPOC and each competent authority is essential — particularly because Article 26 establishes that DNS providers, TLD registries, cloud, data centre, CDN, MSP, MSSP, online marketplace, search engine, and social networking entities fall under a single jurisdiction (the main establishment), while most other entities are subject to concurrent jurisdiction in each Member State where they operate.

Article 9 — National cyber crisis management frameworks

Description

Each Member State must designate one or more cyber crisis management authorities to handle large-scale cybersecurity incidents and crises, with a designated coordinator if there is more than one. Member States must identify deployable capabilities, assets and procedures, and adopt a national large-scale cybersecurity incident and crisis response plan setting out objectives, responsibilities, procedures (including integration with general national crisis management and information exchange channels), preparedness measures, stakeholders, and arrangements for participating in coordinated EU-level response. The Commission and EU-CyCLONe must be notified within three months.

Explanation

Article 9 connects national capability with EU-CyCLONe (Article 16). For entities, it matters because an incident that triggers national crisis-management procedures will sit alongside the entity's own incident response — entities should know in advance who their crisis-management counterpart is and how the national plan envisages industry cooperation.

Article 10 — Computer Security Incident Response Teams (CSIRTs)

Description

Each Member State must designate or establish one or more CSIRTs covering at least the Annex I and II sectors. CSIRTs may sit within a competent authority. They must comply with the requirements in Article 11(1), be responsible for incident handling under a well-defined process, and have adequate resources and a secure, resilient communication infrastructure. CSIRTs cooperate with sectoral or cross-sectoral communities of essential and important entities, participate in peer reviews, cooperate effectively in the CSIRTs network, and may establish relationships with third-country teams (subject to GDPR for personal data).

Explanation

The CSIRT is the operational counterpart for entities during incidents — it receives notifications under Article 23, provides initial feedback within 24 hours, can offer technical assistance, and can perform proactive scans on request. Building a working relationship with the relevant national CSIRT before an incident is sound practice.

Article 11 — Requirements, technical capabilities and tasks of CSIRTs

Description

CSIRTs must ensure high-availability communication channels, secure premises and supporting systems, request-management systems, confidential and trustworthy operations, adequate trained staff, redundancy and continuity. They must monitor and analyse threats, vulnerabilities and incidents at national level; provide early warnings, alerts and information dissemination; respond to incidents and assist entities; collect and analyse forensic data; perform proactive scanning at the entity's request; participate in the CSIRTs network; act as coordinator for coordinated vulnerability disclosure where applicable; and contribute to deploying secure information-sharing tools. They may carry out non-intrusive proactive scans of publicly accessible systems of essential and important entities, prioritising tasks via a risk-based approach.

Explanation

The proactive scanning provisions are a meaningful capability shift: CSIRTs can scan publicly accessible perimeter for misconfigurations and vulnerabilities and notify the entity. Entities should anticipate this by ensuring that their external attack-surface inventory is current and that intake processes for CSIRT findings are defined.

Article 12 — Coordinated vulnerability disclosure and a European vulnerability database

Description

Each Member State designates one of its CSIRTs as coordinator for coordinated vulnerability disclosure (CVD). The coordinator acts as trusted intermediary between vulnerability reporters and the manufacturer/provider of the affected ICT product or service: identifying and contacting affected entities, assisting reporters, and negotiating disclosure timelines (including multi-party CVD across Member States via the CSIRTs network). Reporters may report anonymously. ENISA develops and maintains a European vulnerability database where entities and their suppliers can voluntarily register and disclose publicly known vulnerabilities, including a description, affected products/services and severity, and the availability of patches or mitigation guidance.

Explanation

Article 12 establishes a European backbone for CVD. For software vendors and component manufacturers it formalises a process that many already follow voluntarily under ISO/IEC 30111 and 29147, and creates a central EU-managed database alongside the established CVE system. For entities, it creates a trusted route for receiving vulnerability reports from external researchers.

Article 13 — Cooperation at national level

Description

Where they are separate, the competent authority, SPOC and CSIRT of the same Member State must cooperate. Member States must ensure that CSIRTs (or competent authorities) receive significant-incident notifications under Article 23 and voluntary notifications under Article 30, and inform the SPOC of these. Cooperation must also extend to law enforcement, data protection authorities, aviation authorities, eIDAS supervisory bodies, DORA competent authorities, EECC national regulatory authorities, CER competent authorities, and other sectoral authorities. CER and NIS2 competent authorities must regularly exchange information on critical-entity identification, risks, threats, incidents and response measures. Reporting must be simplified through technical means.

Explanation

Article 13 prevents the regulatory landscape from fragmenting at national level. For entities, it means that information given to one authority is likely to be shared with others where lawful, including data protection authorities when an incident has personal-data implications — which directly affects how the GDPR Article 33 and NIS2 Article 23 notifications are coordinated.

Chapter III — Cooperation at Union and International Level

Chapter III creates the EU-level cooperation architecture: the Cooperation Group (strategy), the CSIRTs network (operations), and EU-CyCLONe (crisis), as well as the framework for international cooperation, the biennial state-of-cybersecurity report, and peer reviews.

Article 14 — Cooperation Group

Description

The Cooperation Group is established to support strategic cooperation, exchange of information, and trust-building among Member States. It is composed of representatives of Member States, the Commission and ENISA, with the EEAS as observer and the ESAs and DORA competent authorities able to participate. It works on biennial work programmes (first by 1 February 2024). Its tasks span guidance to competent authorities; sharing best practices; exchanging advice with the Commission on emerging policy and on draft delegated/implementing acts; coordinated security risk assessments of critical supply chains (Article 22); discussion of mutual-assistance cases; strategic guidance to the CSIRTs network and EU-CyCLONe; methodology for peer reviews and self-assessment; reporting for the periodic Commission review (Article 40); regular threat-landscape assessments such as ransomware. The Commission may adopt implementing acts on procedural arrangements. The Group meets at least annually with the Critical Entities Resilience Group under CER.

Explanation

The Cooperation Group is where the strategic shape of NIS2 implementation is set. Its work programmes, guidance and supply-chain risk assessments materially affect what 'state of the art' means under Article 21. Tracking its outputs — particularly NIS Cooperation Group publications such as the EU 5G toolbox and successor documents — is part of staying current.

Article 15 — CSIRTs network

Description

The CSIRTs network connects national CSIRTs and CERT-EU, with ENISA providing the secretariat and the Commission as observer. Tasks include exchanging CSIRT capability information, sharing technology, tools, best practices and frameworks; exchanging information on incidents, near misses, threats, risks and vulnerabilities; supporting interoperability; discussing and implementing coordinated cross-border incident responses on member request; providing assistance with cross-border incidents; supporting CVD coordinator CSIRTs in multi-Member-State cases; cooperating with regional and Union-level Security Operations Centres; and providing biennial reports on operational cooperation progress for Article 40 reviews.

Explanation

The CSIRTs network is the operational engine. For entities, it is what makes cross-border incident handling work: when an incident in one Member State affects entities or infrastructure in another, the network is the channel through which information moves between national CSIRTs.

Article 16 — European cyber crisis liaison organisation network (EU-CyCLONe)

Description

EU-CyCLONe is established to coordinate the management of large-scale cybersecurity incidents and crises at operational level. It is composed of Member States' cyber crisis management authorities, with the Commission as participant in cases with significant impact on services and activities in NIS2 scope and as observer otherwise. ENISA provides the secretariat. Tasks include preparedness, shared situational awareness, impact assessment and mitigation proposals, coordination of crisis management, and supporting political-level decision-making. EU-CyCLONe reports to the Cooperation Group and submits an assessment of its work to the European Parliament and Council every 18 months from 17 July 2024.

Explanation

EU-CyCLONe sits between the technical CSIRTs network and the political IPCR arrangements, providing the operational layer for crisis decision-making. Its existence is the EU's institutional answer to the lessons of major cross-border incidents (NotPetya, SolarWinds, Log4j) where coordination across Member States lagged the speed of the threat.

Article 17 — International cooperation

Description

The Union may conclude international agreements with third countries or international organisations, in accordance with Article 218 TFEU, allowing them to participate in particular activities of the Cooperation Group, the CSIRTs network and EU-CyCLONe. Such agreements must comply with Union data protection law.

Explanation

Article 17 keeps the door open for structured cooperation with non-EU partners — relevant for EEA neighbours, NATO partners, and like-minded third countries — while subordinating any data exchange to GDPR/EUDPR transfer rules.

Article 18 — Report on the state of cybersecurity in the Union

Description

ENISA, with the Commission and Cooperation Group, must adopt a biennial report on the state of cybersecurity in the Union and present it to the European Parliament. The report must include a Union-level cybersecurity risk assessment, an assessment of public and private cybersecurity capabilities, an assessment of cyber awareness and hygiene among citizens and entities (including SMEs), an aggregated assessment of peer-review outcomes, and an aggregated assessment of cybersecurity maturity at Union and sectoral level (including alignment of national strategies). It must contain policy recommendations and a summary of ENISA's EU Cybersecurity Technical Situation Reports.

Explanation

The biennial report is the most authoritative public picture of how NIS2 implementation is going across the Union. For boards, it is a useful external benchmark for internal cybersecurity maturity discussions.

Article 19 — Peer reviews

Description

By 17 January 2025 the Cooperation Group had to establish a methodology and organisational arrangements for peer reviews. Participation is voluntary. Peer reviews are carried out by cybersecurity experts designated by at least two other Member States and may cover: implementation of risk-management measures and reporting obligations under Articles 21 and 23; the capabilities and effectiveness of competent authorities; CSIRT operational capabilities; mutual-assistance implementation; information-sharing arrangements implementation; or specific cross-border or cross-sector issues. The methodology covers expert designation criteria, self-assessment, on-site or virtual visits and off-site exchanges, conflict-of-interest management, codes of conduct, confidentiality, and reports with recommendations (which the reviewed Member State may publish in full or redacted form).

Explanation

Peer reviews introduce a soft accountability mechanism between Member States, building on the OECD-style approach of structured mutual evaluation. They are voluntary, but the resulting reports — when published — provide useful evidence of national maturity that entities can use in jurisdictional risk decisions.

Chapter IV — Cybersecurity Risk-Management Measures and Reporting Obligations

Chapter IV is the operational heart of the Directive for in-scope entities. It defines management-body accountability (Article 20), the catalogue of risk-management measures (Article 21), Union-level coordinated supply-chain risk assessments (Article 22), the multi-stage incident reporting regime (Article 23), the use of cybersecurity certification schemes (Article 24), and the role of standardisation (Article 25).

Article 20 — Governance

Description

Member States must ensure that the management bodies of essential and important entities approve the cybersecurity risk-management measures taken by the entity to comply with Article 21, oversee implementation, and can be held liable for infringements of Article 21 by the entity. Members of management bodies must follow training, and entities are encouraged to offer similar training to employees, sufficient to identify risks, assess risk-management practices, and understand their impact on services.

Explanation

Article 20 is a structural change in cybersecurity governance: it pushes accountability up to the board. The text refers to liability for infringements 'by the entity' of Article 21, which national transpositions translate into different forms of director liability — administrative, civil, or in some cases personal. Boards must approve the cybersecurity risk-management programme, oversee it (which means receiving meaningful reporting against it), and undergo training. In practice this means a documented governance structure: who approves the policies, how often, what the reporting cadence is, what training the board has had and when. This connects directly to RCEC's Commit and Control disciplines.

Article 21 — Cybersecurity risk-management measures

Description

Essential and important entities must take appropriate and proportionate technical, operational and organisational measures to manage the risks posed to network and information systems used in their operations or service provision, and to prevent or minimise the impact of incidents on service recipients and other services. Measures must reflect the state of the art, relevant European and international standards, and the cost of implementation, with proportionality assessed against exposure to risk, entity size, and likelihood and severity of incidents. Measures must follow an all-hazards approach and include at minimum: (a) policies on risk analysis and information system security; (b) incident handling; (c) business continuity, including backup management, disaster recovery and crisis management; (d) supply-chain security, including direct supplier and service-provider relationships; (e) security in network and information system acquisition, development and maintenance, including vulnerability handling and disclosure; (f) policies and procedures to assess effectiveness; (g) basic cyber hygiene practices and cybersecurity training; (h) cryptography and, where appropriate, encryption; (i) human-resources security, access-control policies and asset management; (j) multi-factor or continuous authentication, secured voice/video/text and emergency communication, where appropriate.

When considering supply-chain measures, entities must take into account vulnerabilities specific to each direct supplier and service provider, the overall quality of products and cybersecurity practices of suppliers (including secure-development procedures), and the results of any Article 22 coordinated security risk assessment. Where an entity finds non-compliance, it must take corrective measures without undue delay. By 17 October 2024 the Commission had to adopt implementing acts laying down technical and methodological requirements for DNS providers, TLD registries, cloud, data centre, CDN, MSP, MSSP, online marketplaces, online search engines, social networking platforms, and trust service providers; further sectoral implementing acts may follow.

Explanation

Article 21 is the operative control set. The ten domains are deliberately framed in outcome terms rather than as a checklist of specific controls — entities are expected to map them to a recognised framework (ISO/IEC 27001, IEC 62443, NIST CSF, sector standards) and demonstrate appropriate, proportionate and state-of-the-art implementation. The all-hazards framing is important: physical, environmental, human-error and natural-phenomena risks are inside scope alongside cyberattacks. Supply-chain security under (d) explicitly captures direct supplier and service-provider risk and connects to Article 22 coordinated assessments — meaning supplier-tier-1 cybersecurity due diligence and contracting are mandatory, not optional.

The Commission's implementing act of October 2024 ((EU) 2024/2690) operationalises these requirements for the digital-infrastructure and digital-providers categories with substantially more concrete requirements. Entities in those categories should treat that implementing act, not Article 21 alone, as the relevant control specification.

Article 22 — Union-level coordinated security risk assessments of critical supply chains

Description

The Cooperation Group, with the Commission and ENISA, may carry out coordinated security risk assessments of specific critical ICT services, ICT systems or ICT product supply chains, taking into account technical and where relevant non-technical risk factors. The Commission, after consulting the Cooperation Group, ENISA and stakeholders, identifies the specific items eligible for such assessment.

Explanation

Article 22 generalises the model used in the EU 5G coordinated risk assessment to other critical ICT supply chains. The output of any such assessment becomes a mandatory input for entity-level supply-chain risk decisions under Article 21(3). Procurement, vendor risk management and architecture decisions should anticipate that designated technologies may carry mandatory mitigating measures (e.g. restrictions on use in sensitive functions) once the assessment process concludes.

Article 23 — Reporting obligations

Description

Essential and important entities must notify their CSIRT (or competent authority) of any incident having a significant impact on the provision of their services — a 'significant incident'. An incident is significant if it has caused or is capable of causing severe operational disruption of services or financial loss to the entity, or has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage. Where appropriate, entities must also notify recipients of services likely to be adversely affected, and where likely to materialise, must inform recipients of significant cyber threats and remedies.

Reporting follows a multi-stage timeline: (a) early warning within 24 hours of becoming aware of the incident — indicating, where applicable, suspicion of unlawful or malicious cause and possible cross-border impact; (b) incident notification within 72 hours, updating the early warning and providing initial severity, impact and indicators of compromise; (c) intermediate report on relevant status updates upon CSIRT/competent-authority request; (d) final report no later than one month after the incident notification, including detailed description, type of threat or root cause, applied and ongoing mitigation measures, and any cross-border impact; (e) progress report instead of final report if the incident is ongoing at the one-month mark, with a final report one month after handling concludes. Trust service providers must, by derogation, notify within 24 hours.

CSIRTs/competent authorities must respond — where possible within 24 hours of the early warning — with initial feedback and, on request, mitigation guidance and additional technical support; they must also signpost law-enforcement reporting where criminal nature is suspected. Cross-border incidents must be communicated to other affected Member States and ENISA. The CSIRT or competent authority may, after consulting the entity, inform the public when public awareness is needed. SPOCs submit quarterly anonymised aggregated summary reports to ENISA, which informs the Cooperation Group and CSIRTs network every six months. CSIRTs share information with CER competent authorities about critical entities. The Commission may adopt implementing acts further specifying the form and procedure of notifications, and by 17 October 2024 had to specify when an incident is significant for the digital-infrastructure and digital-providers categories.

Explanation

Article 23 is the most operationally demanding provision in the Directive. The 24/72-hour cadence requires a rehearsed, role-based incident-reporting playbook with templates for each stage, clarity about what counts as 'becoming aware', and a triage process for significance. Many entities will need to redesign their incident classification and SLA frameworks so that significance assessment can be reliably made early in an incident, often before root cause is known. The recipient-notification obligation is separate from GDPR Article 34 — the trigger is impact on the service, not breach of personal data, although they often coincide.

Implementing Regulation (EU) 2024/2690 sets concrete significance thresholds for digital-infrastructure and digital-provider entities. For other sectors, national transposition typically supplies guidance. Build the playbook against both the Directive text and the relevant implementing acts.

Article 24 — Use of European cybersecurity certification schemes

Description

Member States may require essential and important entities to use particular ICT products, services and processes — developed in-house or procured — that are certified under European cybersecurity certification schemes adopted under the Cybersecurity Act (Regulation (EU) 2019/881). Member States must also encourage the use of qualified trust services. The Commission is empowered to adopt delegated acts (under Article 38) specifying which categories of essential and important entities must use such certified products, services or processes, where insufficient cybersecurity levels have been identified, including an implementation period; an impact assessment and consultations under the Cybersecurity Act are required first. Where no appropriate scheme exists, the Commission may request ENISA to prepare a candidate scheme.

Explanation

Article 24 ties NIS2 to the EU's growing certification ecosystem (EUCC for ICT products, EUCS for cloud, EU5G, etc.). For now, certification under these schemes is voluntary by default, but the delegated-act mechanism means specific entity categories may be required to use certified components in the future. Procurement strategies should anticipate that EU-certified options will progressively become the default, with cost and lead-time implications.

Article 25 — Standardisation

Description

To promote convergent implementation of Article 21(1) and (2), Member States must encourage the use of European and international standards and technical specifications relevant to network and information system security, without imposing or discriminating in favour of any particular technology. ENISA, with Member States and stakeholders, draws up advice and guidelines on the technical areas and existing standards (including national ones).

Explanation

Article 25 enshrines technology neutrality while pulling implementations toward recognised standards — ISO/IEC 27001, ISO/IEC 27005, ISO/IEC 22301, IEC 62443, ETSI EN 303 645, and others. Choosing a recognised standard as the operating framework simplifies audit and supervisory dialogue.

Chapter V — Jurisdiction and Registration

Chapter V resolves the cross-border question — which Member State regulates which entity — and creates registration obligations, including the dedicated WHOIS-style domain-name registration data regime.

Article 26 — Jurisdiction and territoriality

Description

Entities fall under the jurisdiction of the Member State in which they are established, except: (a) providers of public electronic communications networks or services fall under the jurisdiction of the Member State in which they provide their services; (b) DNS service providers, TLD name registries, entities providing domain name registration services, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers, managed security service providers, providers of online marketplaces, online search engines and social networking services platforms fall under the jurisdiction of the Member State of their main establishment in the Union; (c) public administration entities fall under the jurisdiction of the Member State that established them. Main establishment is determined by where decisions on cybersecurity risk-management measures are predominantly taken; failing that, where cybersecurity operations are carried out; failing that, where the entity has the highest number of employees in the Union. Entities under (b) not established in the Union but offering services in the Union must designate a representative in a Member State where services are offered.

Explanation

Article 26 introduces a single-jurisdiction model for the digital-infrastructure and digital-provider categories, mirroring the GDPR's one-stop-shop logic. For most other entities, jurisdiction is concurrent: an entity providing services across multiple Member States is subject to each of those Member States' competent authorities. The 'main establishment' analysis must be documented — particularly the location of decision-making on cybersecurity risk management — because it directly determines the competent authority and applicable national transposition law. For non-EU providers in category (b), designating a Union representative is mandatory and the representative's location determines jurisdiction.

Article 27 — Registry of entities

Description

ENISA creates and maintains a registry of DNS service providers, TLD registries, entities providing domain name registration services, cloud, data centre, CDN, MSP, MSSP, online marketplace, online search engine and social networking services platform providers, based on information received from SPOCs. By 17 January 2025, Member States must require those entities to submit name; relevant sector, subsector and type of entity; address of main establishment and other Union legal establishments (or representative if not Union-established); contact details (email, phone) of entity and representative; Member States in which the entity provides services; and the entity's IP ranges. Changes must be notified within three months. SPOCs forward this information to ENISA except IP ranges.

Explanation

Article 27 creates a central registry that allows ENISA and competent authorities to track the digital-infrastructure population of NIS2. For entities in scope of Article 27, the obligation is administrative but non-trivial: it requires accurate inventories of legal entities, IP ranges, and Member-State coverage that some organisations do not currently maintain in a single place.

Article 28 — Database of domain name registration data

Description

TLD name registries and entities providing domain name registration services must collect and maintain accurate and complete domain-name registration data in a dedicated database, with due diligence and in compliance with Union data protection law. The database must contain at minimum: domain name; registration date; registrant name, contact email and telephone; and contact email and telephone of the point of contact administering the domain (if different from the registrant). Registries and providers must have publicly available verification policies and procedures; must without undue delay publish non-personal registration data; must provide access to specific personal registration data to legitimate access seekers on lawful and substantiated requests within 72 hours; and must publish disclosure policies. Duplication of collection is not required; cooperation between registries and providers is mandatory.

Explanation

Article 28 is the EU's answer to the post-GDPR collapse of the public WHOIS. It rebalances DNS transparency against data protection by establishing a structured access regime: non-personal data are public, personal data are accessible to legitimate access seekers (law enforcement, CERT/CSIRTs, cybersecurity researchers in some interpretations) on substantiated request, with a 72-hour SLA. Implementation has been the subject of significant ICANN, registrar and registry attention and remains an evolving area of practice.

Chapter VI — Information Sharing

Chapter VI sets the rules for voluntary cybersecurity information sharing — both peer-to-peer between entities and from entities (and non-NIS2 organisations) to the authorities.

Article 29 — Cybersecurity information-sharing arrangements

Description

Member States must ensure that NIS2 entities — and where relevant, non-NIS2 entities — can voluntarily exchange relevant cybersecurity information among themselves, including threat information, near misses, vulnerabilities, TTPs, IoCs, threat-actor information, alerts and tooling configuration recommendations. Such sharing must aim to prevent, detect, respond to or recover from incidents or mitigate their impact, or to enhance overall cybersecurity. Sharing must take place within communities of essential and important entities and where relevant their suppliers and service providers, through cybersecurity information-sharing arrangements that respect the sensitivity of shared information. Member States must facilitate the establishment of such arrangements (including through dedicated ICT platforms and automation tools), and may impose conditions on information made available by competent authorities or CSIRTs. Entities must notify competent authorities of their participation, and of any withdrawal. ENISA supports the establishment of such arrangements.

Explanation

Article 29 legitimises and structures private-sector ISAC-style cooperation. Many sectors (financial services, energy, automotive) already have mature ISACs; Article 29 brings them under a recognised legal umbrella, addresses competition-law and liability concerns that have historically inhibited sharing, and formalises the role of competent authorities and ENISA in facilitating it. Joining or forming a relevant ISAC or sectoral CTI community is a defensible and increasingly expected element of an Article 21 programme.

Article 30 — Voluntary notification of relevant information

Description

In addition to mandatory notifications under Article 23, voluntary notifications may be submitted to CSIRTs (or competent authorities) by: (a) essential and important entities, regarding incidents, cyber threats and near misses; (b) other entities (whether or not in NIS2 scope), regarding significant incidents, cyber threats and near misses. Such notifications are processed under the Article 23 procedure and may be deprioritised relative to mandatory notifications. Voluntary reporting must not result in additional obligations the notifying entity would not otherwise have.

Explanation

Article 30 creates a safe harbour for voluntary disclosure that encourages early sharing of weak signals — near misses, threat observations, supply-chain compromises affecting non-NIS2 entities — without penalising the reporter. For mature security operations, building voluntary CSIRT engagement into the standard playbook (especially around near misses and threats observed but not yet materialised) increases the value of the relationship before a mandatory-reporting incident arrives.

Chapter VII — Supervision and Enforcement

Chapter VII defines the supervisory toolkit, the differentiated regimes for essential vs important entities, the enforcement powers of competent authorities, the framework for administrative fines, the relationship with GDPR enforcement, mutual assistance, and the cross-cutting principle that all measures must be effective, proportionate and dissuasive.

Article 31 — General aspects concerning supervision and enforcement

Description

Member States must ensure that competent authorities effectively supervise and take measures necessary to ensure compliance. Authorities may prioritise supervisory tasks based on a risk-based approach, including establishing supervisory methodologies. Authorities must cooperate closely with GDPR supervisory authorities for incidents resulting in personal-data breaches. For public administration entities, supervisory powers must be exercised with operational independence, in line with national legislative and institutional frameworks; appropriate, proportionate and effective measures may be imposed.

Explanation

Article 31 sets the supervisory tone: risk-based, cooperative across regulators, and adapted to the public sector. The risk-based prioritisation language is significant — competent authorities are not expected to audit everyone every year, but to focus their resources on the highest-risk entities and questions.

Article 32 — Supervisory and enforcement measures in relation to essential entities

Description

Supervisory measures applicable to essential entities include: on-site inspections and off-site supervision (including random checks); regular and targeted security audits by an independent body or competent authority; ad-hoc audits; security scans on objective non-discriminatory criteria; requests for information necessary to assess risk-management measures (including documented policies); requests for data, documents and information needed for supervision; requests for evidence of cybersecurity policy implementation (e.g. audit results). Costs of targeted independent audits are borne by the audited entity unless duly substantiated otherwise.

Enforcement powers include: warnings; binding instructions or remediation orders, including time limits; cease-and-desist orders; orders to bring risk-management or reporting into compliance; orders to inform affected service recipients of significant cyber threats and remedies; orders to implement audit recommendations within a reasonable deadline; designation of a monitoring officer with defined tasks and duration; orders to publish aspects of infringements; and administrative fines under Article 34.

Where measures (a)–(d) and (f) are ineffective, competent authorities may set a remediation deadline and, on failure, (i) suspend (or request the suspension of) certifications or authorisations covering part or all of the relevant services or activities; or (ii) request that bodies, courts or tribunals temporarily prohibit any natural person responsible at CEO or legal-representative level from exercising managerial functions in the entity. Suspensions and prohibitions apply only until remediation is complete, with appropriate procedural safeguards. These last-resort measures do not apply to public administration entities.

Natural persons responsible for or representing an essential entity have the power and duty to ensure compliance and may be held liable for breach of those duties. Enforcement measures must be motivated and preceded by notification of preliminary findings, with reasonable time to submit observations. Authorities must inform CER competent authorities, and where DORA-relevant, the Oversight Forum, when exercising powers over critical entities or critical ICT third-party service providers.

Explanation

Article 32 is unusually muscular for a sectoral cybersecurity instrument. The combination of mandatory audits, binding instructions, monitoring-officer designation, public disclosure of infringements, suspension of authorisations, and temporary CEO/legal-representative prohibitions gives competent authorities the means to compel remediation in a way NIS1 lacked. The temporary management ban is particularly notable and is a meaningful personal-liability mechanism — it does not require criminal conviction, only administrative determination after due process and other measures having failed.

Article 33 — Supervisory and enforcement measures in relation to important entities

Description

Important entities are subject to ex post supervision: when authorities receive evidence, indication or information that they may not be complying with the Directive, they must take action through ex post supervisory measures that are effective, proportionate and dissuasive. Supervisory powers include on-site inspections and ex post off-site supervision; targeted security audits by independent body or authority; security scans; requests for information to assess ex post risk-management compliance; requests for data, documents and information for supervision; requests for evidence of policy implementation. Enforcement powers parallel essential-entity measures (warnings, binding instructions, cease-and-desist, compliance orders, recipient-notification orders, audit-recommendation implementation orders, public-disclosure orders, administrative fines). The last-resort suspension and management-ban measures of Article 32(5) do not apply to important entities.

Explanation

The essential vs important distinction has direct supervisory consequences: important entities face a lighter, reactive regime. They are not required to systematically document compliance in advance. But they remain subject to the full Article 21 obligations and to administrative fines (capped lower at EUR 7m / 1.4%). The pragmatic implication: important entities still need a mature programme; they simply face less proactive examination of it unless something flags.

Article 34 — General conditions for imposing administrative fines on essential and important entities

Description

Administrative fines must be effective, proportionate and dissuasive, taking the circumstances of each case into account. They are imposed in addition to other enforcement measures and decided based on the elements in Article 32(7) (gravity, duration, recidivism, damage, intent or negligence, mitigation, codes of conduct, cooperation). For essential entities, infringements of Article 21 or 23 attract fines of up to at least EUR 10 million or up to at least 2% of total worldwide annual turnover of the undertaking in the preceding financial year, whichever is higher. For important entities the cap is up to at least EUR 7 million or up to at least 1.4% of total worldwide annual turnover, whichever is higher. Periodic penalty payments may be provided for. Member States may decide whether and to what extent fines apply to public administration entities. Where a Member State's legal system does not provide for administrative fines, fines must be imposed by courts or tribunals on the competent authority's initiative, with effective, proportionate and dissuasive equivalent effect.

Explanation

Article 34 brings GDPR-scale fining to cybersecurity. The EUR 10m / 2% (essential) and EUR 7m / 1.4% (important) caps are minimum maximums — Member States may set higher caps. The 'undertaking' concept is the EU competition-law concept, meaning fines can be calculated against a parent group's worldwide turnover, not just the legal entity that breached. This is a meaningful change in financial risk and should drive boards to revisit cybersecurity in the same way GDPR did in 2018.

Article 35 — Infringements entailing a personal data breach

Description

Where competent authorities become aware that a NIS2 infringement under Articles 21 or 23 may entail a notifiable personal-data breach under GDPR Article 33, they must inform the relevant GDPR supervisory authority without undue delay. If the GDPR authority imposes a fine under GDPR Article 58(2)(i), the NIS2 competent authority cannot impose an Article 34 fine for an infringement arising from the same conduct, but may impose other Article 32(4)/(5) or 33(4) enforcement measures. Cross-border GDPR cases require notification to the GDPR authority in the Member State concerned.

Explanation

Article 35 prevents double-fining for the same conduct under GDPR and NIS2. Practically, an entity facing a major incident with personal-data implications will deal with both authorities; coordination between them is presumed, but the entity should structure its notifications and remediation evidence to satisfy both regimes simultaneously.

Article 36 — Penalties

Description

Member States must lay down rules on penalties applicable to infringements of national measures adopted under the Directive, ensuring they are effective, proportionate and dissuasive. Member States had to notify these rules to the Commission by 17 January 2025.

Explanation

Article 36 leaves Member States to fill in the framework with national criminal or administrative penalties beyond Article 34 fines. National variation should be expected and must be reviewed in each operating jurisdiction.

Article 37 — Mutual assistance

Description

Where an entity provides services in more than one Member State, or where its network and information systems are located in another Member State, competent authorities must cooperate and assist each other. Cooperation must include informing other Member States via the SPOC of supervisory or enforcement measures taken; requesting other competent authorities to take such measures; and providing assistance proportionate to the receiving authority's resources on substantiated request, including information requests and supervisory measures (on-site inspections, off-site supervision, targeted security audits). Refusal is permitted only if the requested authority lacks competence, the assistance would be disproportionate, or the request concerns information whose disclosure would be contrary to essential national-security interests. Joint supervisory actions may be carried out by mutual agreement.

Explanation

Article 37 makes cross-border supervision workable. For multinational entities, a supervisory action initiated in one Member State can prompt coordinated action across the others where the entity operates. Centralised cybersecurity governance helps not just for compliance but for orderly response to multi-authority engagement.

Chapter VIII — Delegated and Implementing Acts

Chapter VIII sets the procedural rules under which the Commission may adopt the secondary legislation that fleshes out NIS2.

Article 38 — Exercise of the delegation

Description

Delegated powers under Article 24(2) (mandatory certification) are conferred on the Commission for five years from 16 January 2023. The European Parliament or Council may revoke the delegation. Before adopting a delegated act the Commission consults experts designated by Member States. Delegated acts enter into force only if neither the Parliament nor the Council objects within two months (extendable by a further two months) of notification.

Explanation

Article 38 is standard EU lawmaking machinery. Its practical importance is in the consultative process: certification mandates will not be sprung on industry without an evidence-based impact assessment and stakeholder consultation, and entities have a structured opportunity to engage.

Article 39 — Committee procedure

Description

The Commission is assisted by a committee within the meaning of Regulation (EU) No 182/2011, with the examination procedure applying.

Explanation

Article 39 governs the comitology for implementing acts (Articles 14, 21, 23). Implementing Regulation (EU) 2024/2690 was adopted under this procedure and is now binding for the digital-infrastructure and digital-providers categories.

Chapter IX — Final Provisions

Article 40 — Review

Description

By 17 October 2027, and every 36 months thereafter, the Commission must review the functioning of the Directive and report to the European Parliament and Council. The review must in particular assess the relevance of the size of entities concerned and the sectors, subsectors and types of entity in Annexes I and II for the functioning of the economy and society in relation to cybersecurity. Cooperation Group and CSIRTs network reports feed the review. A legislative proposal may accompany the report.

Explanation

The review clause anticipates that NIS2's scope will need adjustment as technology and threats evolve. Sectors not currently in Annex I or II — and in particular entities sometimes designated as Very Large Online Platforms under the DSA — are explicit candidates for future inclusion. Entities should treat their NIS2 scoping as a living conclusion rather than a one-time exercise.

Article 41 — Transposition

Description

Member States had to adopt and publish the measures necessary to comply with the Directive by 17 October 2024 and apply them from 18 October 2024. National measures must reference the Directive at official publication.

Explanation

In practice, transposition has been uneven across Member States. As of the date of this document, several Member States have completed transposition; others have draft or partial transposition; the Commission has issued infringement letters to those significantly behind. Operating organisations should track each relevant national transposition timeline and not rely on the Directive text alone for operational planning.

Article 42 — Amendment of Regulation (EU) No 910/2014

Description

Article 19 of eIDAS is deleted with effect from 18 October 2024.

Explanation

eIDAS Article 19 contained the security and notification regime for trust service providers. NIS2 absorbs that regime so trust service providers fall under a single coherent cybersecurity framework rather than two parallel ones.

Article 43 — Amendment of Directive (EU) 2018/1972

Description

Articles 40 and 41 of the European Electronic Communications Code (EECC) are deleted with effect from 18 October 2024.

Explanation

The deleted EECC articles were the security and incident-notification provisions for electronic communications providers. Like eIDAS Article 19, they are replaced by NIS2 obligations, unifying the legal regime for telecoms cybersecurity.

Article 44 — Repeal

Description

Directive (EU) 2016/1148 (NIS1) is repealed with effect from 18 October 2024. References to NIS1 are construed as references to NIS2 in accordance with the correlation table in Annex III.

Explanation

NIS2 fully replaces NIS1. National laws built on NIS1 had to be replaced or substantially rewritten. The correlation table in Annex III is the definitive cross-reference.

Article 45 — Entry into force

Description

The Directive entered into force on the twentieth day following its publication in the Official Journal — i.e. 16 January 2023.

Explanation

Entry into force is the legal start of the transposition clock; application via national law began 18 October 2024.

Article 46 — Addressees

Description

The Directive is addressed to the Member States.

Explanation

As a directive — not a regulation — NIS2 binds Member States as to the result to be achieved while leaving form and method to national law. Entities therefore comply with their relevant national transposition act, not directly with the Directive, although the Directive remains the interpretive baseline.

Annexes

Annex I — Sectors of high criticality

Annex I lists the sectors and entity types whose entities are essential entities (when the size threshold is met or 'regardless of size' criteria apply). The Annex I sectors are:

• Energy: electricity (undertakings, DSOs, TSOs, producers, NEMOs, energy storage market participants, recharging-point operators); district heating and cooling; oil (transmission pipelines, production/refining/treatment/storage facilities, central stockholding entities); gas (supply, DSO, TSO, storage, LNG, natural gas undertakings, refining/treatment); hydrogen (production, storage, transmission).
• Transport: air (commercial air carriers, airport managing bodies of core network airports and entities operating ancillary installations, ATC operators); rail (infrastructure managers, railway undertakings including those operating service facilities); water (inland/sea/coastal passenger and freight transport companies, port managing bodies and port facilities, VTS operators); road (road authorities responsible for traffic-management control, ITS operators).
• Banking: credit institutions.
• Financial market infrastructures: trading-venue operators and central counterparties (CCPs).
• Health: healthcare providers, EU reference laboratories, R&D entities for medicinal products, basic pharmaceutical and pharmaceutical-preparations manufacturers, manufacturers of medical devices on the public-health-emergency critical list.
• Drinking water: suppliers and distributors (excluding non-essential distribution).
• Waste water: undertakings collecting, disposing of or treating urban, domestic or industrial waste water (excluding non-essential cases).
• Digital infrastructure: IXP providers; DNS service providers (excluding root name servers); TLD name registries; cloud computing service providers; data centre service providers; content delivery network providers; trust service providers; providers of public electronic communications networks; providers of publicly available electronic communications services.
• ICT service management (B2B): managed service providers; managed security service providers.
• Public administration: central-government public administration entities; regional-level public administration entities (where Member States so determine after risk assessment).
• Space: operators of ground-based infrastructure for the provision of space-based services (excluding providers of public electronic communications networks).

Explanation: Annex I covers the sectors whose disruption would have the deepest societal and economic impact, and the entities in those sectors that are most central to service continuity. The expanded scope compared with NIS1 is most visible here — district heating/cooling, hydrogen, waste water, space ground infrastructure, MSPs/MSSPs, and public administration are notable additions.

Annex II — Other critical sectors

Annex II lists sectors whose entities are important entities (when the size threshold is met). The Annex II sectors are:

• Postal and courier services.
• Waste management (where waste management is the principal economic activity).
• Manufacture, production and distribution of chemicals (manufacture or distribution of substances or mixtures under the REACH framework).
• Production, processing and distribution of food (food businesses engaged in wholesale distribution and industrial production and processing).
• Manufacturing: medical devices and in vitro diagnostic medical devices; computer, electronic and optical products (NACE Rev. 2 division 26); electrical equipment (27); machinery and equipment n.e.c. (28); motor vehicles, trailers and semi-trailers (29); other transport equipment (30).
• Digital providers: providers of online marketplaces, online search engines, social networking services platforms.
• Research: research organisations.

Explanation: Annex II captures sectors that are critical but where entities typically face less prescriptive ex ante supervision. It also brings discrete-manufacturing categories under cybersecurity oversight for the first time at EU level — a meaningful change for industrial CIOs who historically operated outside the cybersecurity-regulation perimeter.

Annex III — Correlation table

Annex III is a one-to-one correlation table mapping NIS1 articles to their NIS2 successors. It is intended to make legal continuity workable for legacy references and existing case law. It is not reproduced here in full because it is a structural cross-reference rather than substantive text; readers needing it should consult the Official Journal version. The high-level continuities are: NIS1 Articles 14 and 16 (security and incident-reporting obligations) become NIS2 Article 21 (risk management) and Article 23 (reporting); NIS1 Articles 7 and 8 (national strategy and competent authorities) become NIS2 Articles 7 and 8; NIS1 Article 9 (CSIRTs) becomes NIS2 Articles 10 and 11; NIS1 Article 18 (jurisdiction) becomes NIS2 Article 26; NIS1 Annex II (sectors) becomes NIS2 Annex I; NIS1 Annex III (digital service providers) is largely absorbed into NIS2 Annex II point 6 and Annex I point 8.

Impact and Scope: A Practical Synthesis

What changed compared with NIS1

• Scope is uniformly defined by a size-cap rule rather than national identification of operators of essential services — eliminating divergence and dramatically expanding the regulated population.
• Sectors and entity types are broader: hydrogen, waste water, space ground infrastructure, MSP/MSSP, food, chemicals, manufacturing categories, postal, research, public administration, and others are now in scope.
• Two-tier classification (essential vs important) replaces the operator/digital-service-provider distinction and drives differentiated supervisory regimes.
• Risk-management measures are codified as a ten-domain catalogue with an explicit all-hazards approach and explicit supply-chain obligations.
• Reporting follows a 24/72/30 cadence with mandatory early warning, notification, intermediate progress reporting, and final report — a step-change from NIS1's looser regime.
• Management bodies must approve and oversee the cybersecurity programme and may be held personally liable for the entity's infringements; senior individuals can be temporarily prohibited from managerial functions in essential entities as a last resort.
• Administrative fines reach EUR 10m or 2% (essential) and EUR 7m or 1.4% (important) of worldwide annual turnover of the undertaking, with GDPR-style scope and severity.
• Cross-border enforcement is structured through SPOCs, the Cooperation Group, the CSIRTs network, EU-CyCLONe, and a clear jurisdictional regime.

Where the work concentrates for in-scope organisations

Across diverse sectors, programme effort tends to concentrate in five areas. First, governance: getting the management body informed, trained, engaged, and on the record approving the programme; rebuilding cybersecurity reporting to the board so that liability is exercised against meaningful information. Second, control programme: mapping the ten Article 21 domains to a recognised standard, running a gap assessment, prioritising remediation against state-of-the-art and proportionality criteria, and maintaining defensible evidence. Third, supply chain: building or reinforcing third-party cybersecurity due diligence, contract clauses, ongoing assurance, and monitoring against Article 22 coordinated assessments. Fourth, incident reporting: rebuilding the playbook around 24/72/30, including a robust significance-assessment process and templates for each notification stage. Fifth, registration and jurisdiction: documenting main establishment, registering with the relevant SPOC/competent authority, maintaining contact information, and tracking national transposition variation across operating jurisdictions.

How the regulatory ecosystem fits together

NIS2 does not stand alone. It is part of an EU regulatory stack that includes the GDPR (data protection), the eIDAS Regulation (trust services, with Article 19 absorbed into NIS2), the Cybersecurity Act (ENISA mandate and certification), DORA (financial sector), the CER Directive (physical resilience of critical entities), the EECC (electronic communications, with Articles 40 and 41 absorbed into NIS2), the Cyber Resilience Act (product cybersecurity), the Digital Services Act and Digital Markets Act, and the AI Act. Compliance programmes that treat NIS2 in isolation will repeatedly rediscover that the same control or process is required by another instrument; integrated programmes that treat the stack as one architecture are materially more efficient.

How to use this document

This reference is structured to be read end-to-end as an onboarding piece, or sampled article-by-article when a specific question arises. The Description sections are deliberately faithful to the legal text so that they can be quoted in internal documents; the Explanation sections are interpretive and should be read alongside, not in place of, the relevant national transposition law. For operational decisions — reporting thresholds, certification mandates, sectoral risk-management specifics — the relevant Commission implementing acts (notably (EU) 2024/2690 for digital infrastructure and digital providers) and national transposition acts must be consulted.

— End of document —

Topics: GRC

Related articles

• NIS2 - Executive Implementation Brief – A board-level guide to scope, obligations, timelines, and the work programme required to comply with the EU's NIS2 Directive.
• The Technology Leadership Platform: a working guide for digital leadership teams – How the platform's four core base modules — Baseline, Technology Management, Strategy Execution and GRC — fit together, and how a digital leadership team uses them in practice.

How Clateway can help

• GRC and compliance software with AI – AI-powered GRC software: generate ISO 27001, NIS2, DORA and GDPR policies, run your Statement of Applicability, controls, audit findings and management review…
• Fractional CIO services – Hire an experienced fractional CIO: senior IT leadership two days a week that owns strategy, roadmap, budget, suppliers, cyber and compliance (NIS2, DORA, ISO…
• Technology and cyber board advisory – Independent technology and cyber expertise for boards and supervisory boards: advice on management's plans, NIS2 accountability, AI governance and director…