NIS2 vs NIS1: Requirements, Scope, and How to Comply

• Map the organisation’s services to Annex I or Annex II of Directive (EU) 2022/2555.
• Apply the size-cap rule and check any targeted small-entity inclusions.
• Classify the entity as essential or important under the national implementing law.
• Build evidence for Article 21 risk management, governance oversight, and incident reporting.
• Confirm local reporting procedures with the competent authority or national CSIRT.

Directive (EU) 2022/2555 is better known as NIS2: the European Union law that sets cybersecurity obligations for many organisations providing important or essential services across the EU. It replaced the first NIS Directive by widening the sectors in scope, strengthening management accountability, clarifying incident reporting duties, and giving national authorities broader enforcement powers.

The primary legal source remains Directive (EU) 2022/2555 as published in the Official Journal of the European Union, with ENISA guidance providing useful interpretation for implementation. National law still matters because each Member State transposes the directive into its own legal framework, so organisations should treat EU-level requirements as the baseline and then verify local thresholds, registration duties, reporting portals, and supervisory procedures. Current as of 2026, many compliance programmes are moving from interpretation into operating evidence: policies, risk registers, incident records, supplier assurance, and board-level oversight.

NIS2 vs NIS1: what changed

NIS1 focused on operators of essential services and a narrower group of digital service providers. NIS2 keeps the goal of improving cyber resilience across the internal market, but it applies to a broader set of sectors and uses a more structured distinction between essential entities and important entities.

The most practical change is that NIS2 is less dependent on each country identifying individual operators one by one. In many cases, an organisation is in scope by default if it operates in a listed sector and meets the size-cap rule. That shifts the burden toward organisations to assess their own status, document the reasoning, and be ready to explain it to customers, regulators, auditors, and insurers.

NIS2 also makes governance more explicit. Management bodies are expected to approve cybersecurity risk-management measures, oversee implementation, and receive training so they can understand the risks being accepted on behalf of the organisation. This is a significant change for organisations where cybersecurity has historically been treated as a technical function rather than a board-level risk discipline.

Who is in scope under NIS2?

The scope assessment starts with the directive’s sector annexes. Annex I covers sectors of high criticality, including energy, transport, banking, financial market infrastructures, health, drinking water, waste water, digital infrastructure, ICT service management, public administration, and space. Annex II covers other critical sectors, including postal and courier services, waste management, chemicals, food, certain manufacturing activities, digital providers, and research organisations.

The next step is the size-cap rule. Medium and large entities operating in those listed sectors are generally in scope by default, while certain micro and small entities can still be included where the directive or national law treats their services as particularly important. Examples can include some providers connected to electronic communications, domain name systems, trust services, or other functions where a small operator may still create systemic risk.

A practical decision framework is to identify the services being provided, map those services to Annex I or Annex II, apply the size-cap rule, check Member State add-ons or derogations, and then determine the supervisory regime and immediate compliance steps. This approach reflects Article 2 and Annexes I and II of Directive (EU) 2022/2555 and avoids a common mistake: assessing scope only by company size while ignoring the nature of the service.

Essential entities and important entities are both subject to cybersecurity and reporting obligations, but they are supervised differently. Essential entities generally face more proactive supervision, including the possibility of audits, inspections, and requests for evidence before a major incident occurs. Important entities are more commonly supervised after evidence of non-compliance or following an incident, although national authorities retain meaningful enforcement powers over both categories.

Risk management requirements under Article 21

Article 21 is the operational centre of NIS2 compliance. It requires appropriate and proportionate technical, operational, and organisational measures to manage risks to network and information systems and to minimise the impact of incidents on service recipients and connected services.

In practice, this means the organisation needs a functioning cybersecurity management system rather than isolated documents. Policies should connect to risk assessment, asset visibility, access control, vulnerability handling, incident response, backup and recovery, business continuity, encryption or cryptography where appropriate, secure development or acquisition practices, and regular testing. Evidence matters because regulators and customers will usually want to see how controls work, not just whether a policy exists.

Supply-chain security deserves particular attention. NIS2 expressly brings supplier and service-provider dependencies into the risk conversation, which is important for organisations relying on managed service providers, cloud platforms, software vendors, outsourced SOCs, and critical maintenance partners. A weak supplier assurance process can become a compliance gap even where internal security controls appear mature.

Many organisations use ISO/IEC 27001, NIST CSF, CIS Controls, or sector-specific regulations to structure the control environment. Those frameworks do not automatically equal NIS2 compliance, but they can make the work easier by giving security teams a familiar way to organise policies, risks, controls, evidence, and continual improvement. Where an organisation is building an implementation plan, structured training such as the NIS2 Directive Lead Implementer course can help translate the directive into governance, risk, and control activities without treating the course itself as a substitute for legal or regulatory work.

Incident reporting under NIS2

NIS2 requires reporting of significant incidents, meaning incidents that cause or are capable of causing substantial operational disruption, financial loss, or material or non-material damage to natural or legal persons. This is not the same as GDPR personal data breach reporting, although the same incident may trigger obligations under both regimes. Security, legal, privacy, communications, and service-owner teams therefore need a shared triage process rather than separate reporting tracks that only meet at the end.

The reporting workflow under Article 23 is staged. The purpose is to give authorities early visibility without forcing organisations to provide complete root-cause analysis before the facts are known. A reusable playbook should define who can declare a potentially significant incident, who contacts the competent authority or CSIRT, who approves submissions, and how evidence is preserved while technical containment continues.

The practical challenge is that the first report may be due while the incident is still uncertain. Organisations should therefore pre-agree severity criteria, maintain current contact details, prepare templates, and rehearse escalation with legal and operational teams. Member States may specify portals, formats, language requirements, and additional steps, so the local CSIRT or competent authority process should be built into the playbook before an incident occurs.

Management accountability and training

NIS2 makes cybersecurity oversight a management responsibility. Management bodies must approve the cybersecurity risk-management measures used by the organisation and oversee their implementation. They can also be held accountable where failures occur, depending on the national implementing law and the facts of the case.

This does not mean every board member needs to become a security engineer. It does mean management should understand the organisation’s critical services, material cyber risks, major dependencies, incident readiness, investment decisions, and unresolved control weaknesses. Training is part of that duty because directors and senior leaders cannot meaningfully approve a risk posture they do not understand.

One common implementation mistake is to present NIS2 as a one-off compliance project ending with a policy pack. A more defensible approach is to build a governance cycle: regular risk review, control testing, supplier assurance, incident exercises, management reporting, and documented decisions about accepted risk. That cycle is what turns regulatory text into operational resilience.

Penalties and enforcement

NIS2 gives national authorities stronger enforcement tools than NIS1. These may include information requests, security audits, binding instructions, orders to remedy deficiencies, administrative fines, and measures affecting management responsibility. The exact process and authority structure depend on the Member State’s implementing law.

The directive distinguishes between essential and important entities when setting the enforcement model. Essential entities are subject to more proactive supervision and face a higher penalty ceiling. Important entities can still face significant enforcement, especially after incidents, complaints, or evidence of non-compliance, but supervision is generally more reactive.

National variation is a real operational issue. A group operating in several EU Member States may need to register or report through more than one channel, align local legal interpretations, and maintain evidence that satisfies different authorities. Suppliers serving in-scope customers should also expect contract clauses requiring NIS2-related security commitments, incident notification support, audit cooperation, and resilience evidence.

Building a practical compliance plan

A useful NIS2 programme begins with scope and ownership. The organisation should document why it is, or is not, an essential or important entity, identify the legal entity or entities affected, and assign accountability across security, risk, legal, procurement, operations, and executive management. Without that foundation, control work can drift into generic cybersecurity improvement without a clear regulatory target.

The next step is a gap assessment against Article 21 and Article 23. This should test whether risk management, incident response, business continuity, supplier assurance, access control, vulnerability management, backup, encryption, and governance reporting are operating in practice. Where existing ISO/IEC 27001, DORA, CER Directive, sector regulation, or customer assurance work already exists, teams should reuse evidence rather than create duplicate control sets.

Implementation should then prioritise the controls that reduce both operational risk and reporting risk. Incident classification, supplier dependency mapping, executive reporting, backup recoverability, privileged access, and crisis communications often reveal gaps quickly because they cut across multiple teams. In addition, evidence should be designed from the start: meeting minutes, risk decisions, test results, supplier reviews, incident exercises, and remediation tracking are often as important as the written policy.

Where NIS2 work fits next

NIS2 compliance is part of a wider resilience programme, not a separate legal exercise. The organisations that handle it most effectively tend to combine regulatory interpretation with practical security operations, supplier governance, incident readiness, and management oversight. That approach also makes it easier to respond when national authorities refine procedures or when customers ask for evidence of compliance.

Readynez provides security training options for teams building these capabilities, including related ISACA governance and security courses and Unlimited Security Training for organisations planning a broader upskilling path. To discuss which learning route fits an organisation’s current NIS2 responsibilities, contact the team.

FAQ

What are the main NIS2 requirements?

NIS2 requires in-scope entities to manage cybersecurity risk, report significant incidents, maintain business continuity and crisis management capabilities, address supply-chain security, and ensure management oversight. The detail sits mainly in Directive (EU) 2022/2555 and the relevant Member State implementing law.

Does NIS2 apply to all organisations?

No. NIS2 generally applies to medium and large entities operating in the sectors listed in Annex I and Annex II, with some targeted inclusions for smaller entities where the service is especially important. Organisations should assess both the sector mapping and the national implementation rules before deciding they are out of scope.

What is the difference between essential and important entities?

Essential entities usually operate in sectors of high criticality and face more proactive supervision by authorities. Important entities are also subject to NIS2 duties, but supervision is generally more reactive, often following an incident or evidence of non-compliance.

What are the NIS2 incident reporting deadlines?

For significant incidents, NIS2 uses a staged reporting model: an early warning within 24 hours, an incident notification within 72 hours, and a final report within one month of the incident notification. Local authorities may specify the reporting portal, format, and additional procedural requirements.

Can ISO/IEC 27001 help with NIS2 compliance?

ISO/IEC 27001 can help structure risk management, controls, governance, and evidence, but certification to ISO/IEC 27001 does not automatically prove NIS2 compliance. The organisation still needs to map its controls and reporting process to the directive and the relevant national implementing law.

What happens if an organisation does not comply with NIS2?

Non-compliance can lead to regulatory action such as information requests, audits, binding instructions, remediation orders, administrative fines, and management-related measures. The exact consequences depend on whether the entity is essential or important and how the Member State has implemented the directive.