NIS2: the directive for EU cyber resilience.

What NIS2 is

NIS2, Directive (EU) 2022/2555, is the EU legal framework for network and information security across critical and important sectors. Published on 27 December 2022 and entering into force on 16 January 2023, it replaced the 2016 NIS Directive (Directive (EU) 2016/1148) with substantially expanded scope, stronger security obligations, harmonized incident reporting, and personal management liability.

NIS2 is a directive, not a regulation. That distinction matters: a regulation applies directly across the EU without national implementing measures, while a directive must be transposed into each member state's national law. The transposition deadline was 17 October 2024. In practice, not all member states met that deadline, which means the specific obligations, supervisory body, and enforcement approach differ across the EU. When your legal team assesses NIS2 exposure, they need to assess the transposed national law of the member states where you operate, not only the directive text.

What NIS2 stands for: Network and Information Security. NIS2 is the shorthand for the second-generation cybersecurity directive, succeeding NIS1.

What changed from the NIS Directive to NIS2

NIS2 is not a minor update. The 2022 version overhauled the 2016 directive on scope, obligations, accountability, and enforcement.

Who NIS2 applies to

Scope is the hardest practical question. Most compliance teams underestimate the reach. NIS2 applies to entities that: (1) are of a type listed in Annex I or Annex II, (2) provide services in or operate in the EU, and (3) meet or exceed the size threshold (medium: 50 or more employees, or 10 million EUR or more in annual turnover or balance sheet). Some entities are in scope regardless of size.

NIS2 distinguishes two entity types. Essential entities face stricter supervision: proactive, ex-ante oversight by the national competent authority, which can audit without an incident trigger. Important entities face reactive supervision: the authority acts after an incident, complaint, or evidence of non-compliance. Both are required to implement the same ten Article 21 security measures. The distinction affects supervision intensity and some penalty ceilings, not the obligation set.

NIS2 is a directive, so "in scope" means in scope under the national transposition law of the relevant member state. National laws may extend scope beyond the directive minimum, and several member states have done so.

Annex I and Annex II sectors

NIS2 covers 18 sectors split across two annexes. Annex I sectors are treated as higher criticality: large entities in these sectors are essential entities, medium entities are important entities. Annex II sectors produce important entities regardless of whether the entity is large or medium.

The sector categorization matters for self-assessment, but the definitive test is always the national transposition law. Some member states have added sectors or adjusted definitions.

The size threshold, and why supply chain matters

The baseline size threshold for NIS2 scope is the EU definition of a medium-sized enterprise: 50 or more employees, or 10 million EUR or more in annual turnover or balance sheet. Entities below this threshold in Annex I or II sectors are generally out of scope, with the exceptions below.

Size-independent inclusions: qualified trust service providers and top-level domain (TLD) name registries are essential entities regardless of size. DNS service providers and providers of public electronic communications networks or services who are at least medium-sized are essential. Public administration entities are essential regardless of size. Member states may designate additional entities.

The supply chain angle: NIS2 Article 21(d) requires covered entities to manage supply chain security, including the security practices of direct suppliers and service providers. This means a Swiss or non-EU entity that supplies software, cloud infrastructure, or managed services to an EU-covered entity will face contractual NIS2 security requirements as part of that customer relationship, even though the supplier is not itself directly subject to the directive. This is the mechanism by which NIS2 reaches beyond EU borders.

For Swiss entities specifically: Switzerland is not an EU member state and NIS2 does not apply directly. Swiss law provides for information security requirements under the ISG (Informationssicherheitsgesetz) and related legislation for federal bodies and critical infrastructure. However, Swiss companies operating EU subsidiaries, providing digital services to EU users, or supplying EU-covered entities will encounter NIS2 obligations through their EU operations or customer contracts.

NIS2 timeline and national transposition

NIS2 was published in the Official Journal of the EU on 27 December 2022 and entered into force on 16 January 2023. Member states had until 17 October 2024 to transpose it into national law and notify the Commission. Not all member states met that deadline. As of mid-2025, several had transposed late, and some transpositions were still pending.

Because NIS2 is a directive rather than a regulation, the enforceable obligations in any member state come from that state's national law, not from the directive text directly. This has practical consequences: the definitions used, the designated competent authority, the exact penalty ranges (within the directive ceilings), and the registration requirements all vary by member state. Entities operating across multiple EU countries must assess compliance against each relevant national law.

Article 21: the ten required security measures

Article 21 is the core obligations article. It requires essential and important entities to take appropriate and proportionate technical, operational, and organisational measures to manage cybersecurity risks and prevent or minimise the impact of incidents. The measures must be based on an all-hazards approach and proportionate to the level of risk, the entity's size, and the impact a potential incident would have.

The ten measure categories are specified in Article 21(2). Member states may not impose additional cybersecurity requirements on top of these unless national law specifically authorizes it.

The NIS2 incident reporting timeline

Article 23 sets the reporting obligations for significant incidents. A significant incident is one that causes or is capable of causing severe operational disruption, financial loss, or damage to other persons. The reporting clock runs from the moment the entity becomes aware of the incident, not from when the incident occurred.

Entities report to their national CSIRT (or competent authority where no CSIRT is designated). Entities that are also subject to DORA's incident reporting use the DORA regime for ICT-related incidents; see the NIS2 and DORA section below.

The practical challenge: the 24-hour clock is very tight. Many organizations find that detecting an incident, classifying it as significant, escalating to the team that can notify, and actually filing the early warning within 24 hours requires pre-built workflows, pre-approved messaging, and a clear decision tree -- all before any incident occurs. Building that workflow after an incident starts is too late.

Board and management liability under NIS2

Article 20 is one of the most operationally significant provisions in NIS2, and the one that most frequently surprises boards encountering it for the first time. It requires management bodies to approve the cybersecurity risk-management measures and to oversee their implementation. Management body members are personally liable for infringements.

The personal liability provision means that the head of the management body or, where national law provides for it, each member of the management body can be held directly responsible for violations of NIS2 obligations. The specific consequences (fines, temporary bans from management roles) depend on national transpositions, but the directive itself explicitly creates this accountability.

Article 20 also requires member states to ensure that management bodies of essential and important entities undergo cybersecurity training, and that they offer similar training to their employees regularly. This is not optional: it is a compliance obligation, not a best practice.

Where entities actually struggle: translating Article 20 into board practice. The required oversight is not a one-time approval of a security policy. It implies regular board-level reporting on the security measures, awareness of material risks, and documented evidence that the board reviewed and approved the measures. In a competent authority inspection, the board cannot simply point to a security team and say "they handle it."

NIS2 penalty framework

Articles 36 and 37 set the maximum penalty ceilings. The directive specifies minimums for what member states must make available; national transpositions may set specific penalty structures within those ceilings. Some member states have introduced administrative fines; others use criminal liability for management or civil enforcement mechanisms.

The penalty ceilings are expressed as the higher of a fixed maximum or a percentage of global annual turnover, applying to the worldwide revenue of the entity and its group where applicable. This mirrors the GDPR structure and is similarly designed to be proportionate to the size of large, global organizations.

Non-financial remedies are also available: competent authorities can issue binding instructions, require entities to implement specific security measures, publicly disclose non-compliance, and temporarily prohibit management body members from exercising managerial functions.

NIS2 and DORA: the overlap for financial entities

For entities subject to DORA (Regulation (EU) 2022/2554), the relationship between the two frameworks is governed by a lex specialis rule. DORA is the sector-specific EU law for ICT risk in financial services. Under NIS2 Article 4(2), where a sector-specific Union legal act requires essential or important entities to adopt cybersecurity risk-management measures or to notify competent authorities of incidents, and where those requirements are at least equivalent to NIS2, the sector-specific provisions apply.

In practice: financial entities subject to DORA follow DORA for ICT risk management (Chapter II), major ICT incident classification and reporting (Chapter III), digital operational resilience testing (Chapter IV), ICT third-party risk management (Chapter V), and information sharing (Chapter VI). They do not run a separate NIS2 compliance programme for those areas. Where DORA does not provide equivalent coverage (which is limited), NIS2 applies as a baseline.

The supervisory channel also differs. DORA financial entities report major ICT incidents to their national financial supervisor (central bank, financial market authority, insurance supervisor) rather than to the NIS2 national competent authority. For entities in scope for both, this means maintaining clarity on which reporting channel applies for which incident type.

The practical implication: a bank or investment firm that is already compliant with DORA is substantially compliant with the equivalent NIS2 requirements. The risk management frameworks, incident workflows, third-party risk programme, and resilience testing covered by DORA overlap closely with NIS2 Article 21. Running both in Acuna with a shared control library means the overlap is mapped once, not maintained twice.

How NIS2 maps to ISO 27001 and DORA

NIS2 and ISO 27001 overlap closely at the control level. An organization running ISO 27001 already has much of the Article 21 foundation in place: risk assessment, access control, incident management, business continuity, supplier security, cryptography, and training all map to ISO 27001 Annex A controls. NIS2 does not require ISO 27001 certification, but organizations with a mature ISMS will find their compliance effort significantly reduced.

The table maps selected NIS2 Article 21 measures to their ISO 27001 counterparts and, where DORA applies, to DORA chapters. Running all three in Acuna means the control library is built once and reused across frameworks, and the cross-framework mapping is maintained automatically.

Running NIS2 in Acuna

Acuna is designed for the way NIS2 actually lands on compliance teams: alongside ISO 27001, DORA, and GDPR, sharing controls, evidence, and risk data across frameworks rather than running each as an isolated project.

For NIS2 specifically: the Comply pane walks through essential vs important scoping, maps all ten Article 21 measures to your organizational scope, and documents the cybersecurity risk management framework. Supplier Shield manages the Article 21(d) supply chain obligations: third-party risk assessments, contractual security requirements, and continuous monitoring. The incident workflow enforces the 24-hour and 72-hour notification clocks with pre-built escalation paths and draft notification templates. The Assure pane maintains the evidence trail for competent authority review, including board-level approval and training records as required by Article 20.

For entities subject to both NIS2 and DORA: Acuna's cross-framework mapping engine identifies which controls satisfy both sets of requirements, so a single control implementation produces evidence for both frameworks. Teams already running DORA in Acuna extend into NIS2 without rebuilding the control library.

See how Acuna supports NIS2 compliance.