NIS2 Directive Requirements and Reporting Obligations

The NIS2 Directive (Directive (EU) 2022/2555) is the second EU directive on the security of network and information systems. It significantly extends and revises the original NIS Directive. Its aim is to raise the level of cybersecurity across the European Union and to make organizations more resilient against cyber threats. This page explains its scope, its specific requirements, and its reporting obligations.

Contents
  1. Who NIS2 applies to
  2. NIS2 requirements under Article 21
  3. Reporting obligations under Article 23
  4. Penalties and enforcement
  5. NIS2 and the Cyber Resilience Act compared
  6. Transposition and timeline

Who NIS2 applies to

NIS2 covers far more sectors and entities than the directive it replaced. The sectors are listed in two annexes:

Sectors of high criticality (Annex I)
  • Energy (electricity, district heating and cooling, oil, gas, hydrogen)
  • Transport (air, rail, water, road)
  • Banking
  • Financial market infrastructures
  • Health
  • Drinking water and waste water
  • Digital infrastructure
  • ICT service management (business-to-business)
  • Public administration
  • Space
Other critical sectors (Annex II)
  • Postal and courier services
  • Waste management
  • Chemicals (manufacture, production, distribution)
  • Food (production, processing, distribution)
  • Manufacturing (medical devices, electrical equipment and electronics, machinery, vehicles)
  • Digital providers (online marketplaces, online search engines, social networking platforms)
  • Research

The directive applies to medium-sized and large companies in these sectors, based on defined size thresholds.

NIS2 requirements under Article 21

Article 21 of NIS2 sets out specific requirements for the entities concerned. They aim at a high common level of cybersecurity across the EU. The main requirements in detail:

Risk management (Article 21(1) and (2)(a))

Appropriate and proportionate technical, operational, and organizational measures to manage cybersecurity risks, including policies on risk analysis and information system security. Examples: regular risk analyses, creating and updating a risk register, a formal risk management process.

Supply chain security (Article 21(2)(d) and (3))

Cybersecurity risks across the whole supply chain must be taken into account, including security aspects of the relationship between the company and its direct suppliers or service providers. Examples: security audits of suppliers, cybersecurity clauses in contracts, a supplier risk management system.

Incident handling (Article 21(2)(b))

Measures to handle security incidents effectively. Examples: setting up a Computer Emergency Response Team (CERT), developing incident response plans and testing them regularly, automated detection and response systems.

Business continuity and crisis management (Article 21(2)(c))

Measures to keep operations running, including backup management, disaster recovery, and crisis management. Examples: business continuity and disaster recovery plans with regular tests, a crisis team for cyber incidents, redundant systems and data backups.

Security in acquisition, development, and maintenance (Article 21(2)(e))

Security measures in the acquisition, development, and maintenance of network and information systems, including vulnerability handling and disclosure. Examples: security by design in the development process, regular security updates and patches, a vulnerability management program.

Assessing effectiveness (Article 21(2)(f))

Policies and procedures to assess the effectiveness of cybersecurity risk-management measures. Examples: regular internal and external security audits, key performance indicators (KPIs) for cybersecurity, penetration tests and red team exercises.

Cyber hygiene and training (Article 21(2)(g))

Basic cyber hygiene practices and cybersecurity training. Examples: regular phishing simulations, mandatory annual cybersecurity awareness training for all employees, good-practice rules for passwords and device use.

Cryptography and encryption (Article 21(2)(h))

Policies and procedures for the use of cryptography and, where appropriate, encryption. Examples: AES-256 for data encryption, TLS for data in transit, end-to-end encryption for sensitive communication.

Human resources security, access control, and asset management (Article 21(2)(i))

Measures for the security of personnel, access control policies, and asset management. Examples: background checks when hiring new employees, role-based access control, physical access control systems for critical infrastructure.

Multi-factor authentication and secure communication (Article 21(2)(j))

Multi-factor authentication or continuous authentication, secured communication systems and, where appropriate, secured emergency communication systems. Examples: two-factor authentication for all critical systems, VPNs for remote access, a secured emergency communication system.

State of the art (Article 21(1), second subparagraph)

Security measures must take into account the state of the art and, where applicable, relevant European and international standards. Examples: regular review and updating of security measures based on current good practice and frameworks such as ISO/IEC 27001 or the NIST Cybersecurity Framework. National frameworks can also help, such as IT-Grundschutz from Germany's Federal Office for Information Security (BSI).

Proportionality of measures (Article 21(1), second subparagraph)

The proportionality of measures is assessed against factors such as exposure to risk, the size of the entity, and the potential impact of incidents. Examples: a cost-benefit analysis of security measures, security controls matched to the criticality of systems and data, security investments prioritized by risk analysis.

These requirements cover technical, operational, and organizational aspects together, so no single department can implement them alone. Companies must adapt them to their specific situation and review and improve them continuously.

Reporting obligations under Article 23

Article 23 of NIS2 sets clear reporting obligations for significant incidents:

Early warning within 24 hours

Essential and important entities must send an early warning to the CSIRT (computer security incident response team) or, where applicable, the competent authority. They must do so without undue delay and in any event within 24 hours of becoming aware of a significant incident.

Incident notification within 72 hours

Within 72 hours of becoming aware of the significant incident, entities must submit an incident notification. It updates the early warning and gives an initial assessment of the incident, its severity and impact and, where available, the indicators of compromise.

Final report within one month

No later than one month after the incident notification, entities must submit a final report. It contains:

  • a detailed description of the incident, including its severity and impact
  • the type of threat or root cause that is likely to have triggered the incident
  • applied and ongoing mitigation measures
  • where applicable, the cross-border impact of the incident

Penalties and enforcement

NIS2 requires effective, proportionate, and dissuasive penalties for infringements:

Administrative fines

For infringements of Article 21 or 23, Member States must provide for maximum fines of at least €10 million or 2% of total worldwide annual turnover for essential entities, whichever is higher. For important entities, the maximum must be at least €7 million or 1.4% of total worldwide annual turnover, whichever is higher.

Personal liability

Management bodies can be held liable for infringements of their obligations to approve and oversee compliance with the NIS2 risk-management measures.

Temporary bans

In essential entities, people with managerial responsibility at chief executive officer or legal representative level can be temporarily prohibited from exercising managerial functions.

NIS2 and the Cyber Resilience Act compared

NIS2 focuses on the security of network and information systems in critical sectors. The Cyber Resilience Act (CRA) addresses the cybersecurity of products with digital elements. You should understand where the two acts differ and where they complement each other:

NIS2CRA
FocusOrganizational and process aspects of cybersecurity in specific sectorsProduct security, with a focus on the whole supply chain of products with digital elements
ScopeCompanies and organizations in defined critical sectorsManufacturers, importers, and distributors of products with digital elements, regardless of sector
RequirementsRisk-management measures, reporting obligations, organizational security measuresCybersecurity in product design, conformity assessment, and continuous vulnerability handling throughout the product lifecycle
TimelineTransposition into national law by October 2024In force since December 10, 2024; reporting obligations have applied since September 11, 2026, and most other provisions apply from December 11, 2027

Many companies are affected by both acts, especially those that operate critical infrastructure and also manufacture or distribute products with digital elements. If that applies to you, plan the requirements of NIS2 and the CRA together rather than in two separate projects.

For the specific effects of NIS2 on one industry, see What the NIS2 Directive means for machinery manufacturers.

Transposition and timeline

Member States had to transpose NIS2 into national law by October 17, 2024. In Germany, for example, the national NIS2 implementation act (NIS2UmsuCG) has applied since December 6, 2025. Three points matter for companies:

  • Different speeds of transposition: Not all Member States met the deadline. In July 2026, the Commission referred Ireland, Spain, France, and the Netherlands to the Court of Justice of the EU. Transposition across the EU is therefore uneven.
  • National adjustments: Some Member States have extended or adapted the requirements of the directive. This creates differences between Member States.
  • Step-by-step implementation: Companies should expect requirements to be introduced in stages and adjusted over time.

Choosing a CRA consultant? Here is how to find the right one.

Get the guide

Book a call

Send us your request. Together we will look at where your company stands, which questions are still open, and what the sensible next steps are.

For information on how we process your data, see our privacy policy.

Guide: How to choose the right CRA consultant

CRA consulting offers are hard to compare. One provider delivers only a gap analysis, another also supports the technical implementation, and both call themselves “CRA consultants.” If you ask the wrong questions, you end up paying for services you don't need, or you find out halfway through the project that key expertise is missing.

Our guide shows manufacturers what really matters when choosing a provider, from the expertise you need to the right pricing model and the 20 questions you should ask every provider.

What the guide covers:

  • the seven areas of expertise a complete CRA implementation requires
  • four support models depending on your in-house capacity and expertise
  • 20 specific questions for your next provider meeting
  • a red flag card for spotting warning signs quickly
  • a scoring sheet with rating guidance for a structured comparison of providers

Download it for free

Newsletter

For information on how we process your data, see our privacy policy.

Free templates: CRA reporting process

Prepare your company for the reporting obligations under the Cyber Resilience Act. You get process descriptions and templates tested in practice for:

  • reporting actively exploited vulnerabilities
  • reporting severe incidents
  • the required early warning notifications, notifications, and final reports
  • clear responsibilities, escalation paths, and deadlines

Enter your contact details and we will email you the files.

Newsletter

For information on how we process your data, see our privacy policy.

Free template: Risk assessment according to EN 50742

We use this template in our consulting projects for systematic threat assessment. You get an Excel template with:

  • a structured threat assessment for your machinery
  • a systematic way to determine safety-related security levels (SRSL)
  • documentation of vulnerabilities and protective measures

Enter your contact details and you will receive the template within minutes.

Newsletter

For information on how we process your data, see our privacy policy.

Free template: SBOM

We use this template in our consulting projects to meet the CRA requirements for the software bill of materials.

Enter your contact details and you will receive the template within minutes.

Newsletter

For information on how we process your data, see our privacy policy.

Free template: Vulnerability disclosure policy

We use this template in our consulting projects to meet the CRA requirements for vulnerability handling. You get a Word template with:

  • a structure based on EN 40000-1-3
  • predefined sections for reporting channels, response times, and responsibilities
  • safe harbor clauses for security researchers

Enter your contact details and you will receive the template within minutes.

Newsletter

For information on how we process your data, see our privacy policy.