NIS2 Compliance Scope Does Your Organization Fall Under Annexes I II and Article 21 Rules
NIS2 is not only a cybersecurity law. It is a board-level governance test. Before an organisation can decide what controls to improve, who must report incidents, or which suppliers need extra checks, it must answer a simpler question: does NIS2 apply to us?
That scope assessment matters because the Directive has widened the range of covered sectors, introduced clearer size thresholds, and set strict incident reporting duties. For organisations operating in the EU, or serving EU markets through covered services, the wrong answer can lead to missed legal duties, weak incident handling, and avoidable disruption.
The NIS2 Directive, formally Directive (EU) 2022/2555, should be verified against its legal text, especially Annexes I and II, Article 21, and Article 23. The threat context is also clear. The ENISA Threat Landscape 2023 identifies major threats such as ransomware, malware, social engineering, threats against data, availability attacks, and supply-chain compromise. These are exactly the types of risks NIS2 expects organisations to manage.
Why the NIS2 scope assessment comes first
A NIS2 programme that starts with tools, policies, or training can waste time if the organisation has not first mapped its legal position. The Directive does not apply to every business in the same way. It looks at:
The sector the organisation operates in
The size of the organisation
The type of service provided
Whether the organisation is classed as an essential or important entity
National rules introduced by each EU Member State
This is why a practical NIS2 compliance checklist should begin with scope. If the organisation is in scope, the next steps include risk management measures, supply-chain checks, incident reporting procedures, governance accountability, and evidence that these measures work.
For senior leadership, this is not a narrow legal exercise. Scope affects budgets, roles, reporting lines, supplier contracts, insurance discussions, and resilience planning. If a key service interruption would affect customers, public services, healthcare, transport, finance, energy, or digital infrastructure, NIS2 should be reviewed carefully.
The Directive also uses two main categories of covered organisations: essential entities and important entities. These categories affect supervision and enforcement, but both groups must take cybersecurity risk management seriously.
Annexes I and II expanded the sectors covered by NIS2
The earlier EU framework covered a smaller set of operators of essential services and digital service providers. NIS2 goes further. Its Annexes I and II broaden the scope to reflect how dependent society has become on connected systems, digital services, and third-party providers.
Annex I covers sectors of high criticality
Annex I lists sectors that the Directive treats as highly critical. These include:
Energy
Transport
Banking
Financial market infrastructure
Health
Drinking water
Waste water
Digital infrastructure
Information and communication technology service management, business-to-business
Public administration
Space
These sectors are central to public safety, economic stability, and continuity of services. A disruption in one can spread quickly. For example, a cyber incident at a managed information technology provider can affect many clients at once. A ransomware incident in healthcare can delay patient services. A transport system outage can interrupt deliveries and passenger movement.
This is why Annex I should be one of the first documents checked during any NIS2 scope review.
Annex II adds other critical sectors
Annex II extends coverage to sectors that may not always look “essential” at first glance but still carry serious risk. These include:
Postal and courier services
Waste management
Manufacture, production, and distribution of chemicals
Production, processing, and distribution of food
Manufacturing of certain critical products
Digital providers
Research organisations
This expansion is important. Many organisations that were outside earlier rules may now fall within NIS2. A food processor, a chemical distributor, a cloud-based marketplace, or a manufacturer of medical devices may need to assess whether the Directive applies.
The key point is simple: NIS2 scope cannot be assessed by looking only at traditional critical infrastructure. Annex II brings a wider group of organisations into view.
Size thresholds decide many NIS2 cases
NIS2 generally applies to medium-sized and large organisations in the sectors listed in Annexes I and II. The Directive links this approach to the EU definition of business size.
As a practical guide:
Category | Typical threshold used for scope review | Why it matters |
Medium-sized organisation | At least 50 employees, or annual turnover and balance sheet figures above the small business level | Many medium organisations in listed sectors are now likely to be in scope |
Large organisation | 250 or more employees, or higher financial thresholds | Large organisations in listed sectors should expect closer scrutiny |
Smaller organisation | Below medium size | May still be in scope in specific cases |
Smaller organisations should not assume they are outside NIS2 automatically. The Directive includes certain cases where size is not the deciding factor. For example, some digital infrastructure, trust services, domain name services, public electronic communications services, and public administration bodies may require separate review. Member State implementation can also add detail.
For organisations with several legal entities, shared services, or cross-border operations, the scope assessment should not stop at the group name. It should examine each legal entity, each service line, and each country where regulated services are provided.
A reliable review should ask:
Which Annex I or Annex II sectors match our services?
Which legal entities provide those services?
Do we meet the medium or large size thresholds?
Do any special rules apply regardless of size?
Which EU Member State rules apply to our operations?
Are we likely to be treated as essential or important?
This is where many organisations make their first mistake. They treat NIS2 as a cybersecurity department issue rather than a business classification issue. In practice, finance, legal, operations, procurement, and technology teams all hold part of the answer.
Essential and important entities have different labels but serious duties
The phrase NIS2 essential and important entities refers to the two main groups used by the Directive. Both groups must manage cybersecurity risk, report significant incidents, and maintain evidence of compliance.
The difference is mainly in supervision and enforcement. Essential entities face more direct supervisory attention. Important entities can still face checks, measures, and penalties, especially after evidence of non-compliance or incidents.
For leadership, the distinction matters, but it should not create false comfort. Important entities still need a mature approach to risk management. A serious incident can trigger reporting duties, customer scrutiny, contract issues, insurance questions, and regulator attention.
A classification review should record the reasoning clearly. That record should include the relevant Annex category, size basis, services provided, countries involved, and any assumptions made. This evidence can help if a regulator, board committee, buyer, auditor, or insurer asks why the organisation reached its conclusion.
Article 21 turns scope into operational duties
Once an organisation is in scope, Article 21 becomes central. It requires covered entities to take appropriate and proportionate measures to manage risks to network and information systems. Put simply, NIS2 expects organisations to reduce the chance of incidents and reduce the impact when incidents happen.
Article 21 refers to a range of measures, including:
Risk analysis and information system security policies
Incident handling
Business continuity, such as backup management and crisis management
Supply-chain security
Security in acquiring, developing, and maintaining systems
Assessment of how well cybersecurity measures work
Basic cyber hygiene and cybersecurity training
The use of cryptography and encryption where appropriate
Human resources security, access control, and asset management
Multi-factor authentication or secure communications where appropriate
This list is not a one-page policy exercise. It affects how the organisation runs. For example, backup arrangements must be tested, not just documented. Access rights should match job roles. Critical systems should have owners. Incident response plans should name who decides, who communicates, and who reports.
Article 21 also links technical controls to governance. Management bodies are expected to approve measures and oversee implementation. That means leaders need enough evidence to know whether controls exist, whether they work, and whether gaps are being closed.
Article 23 sets the 24-hour and 72-hour reporting clock
Article 23 deals with reporting significant incidents. This is one of the clearest areas where timing matters.
The Directive sets a staged reporting process:
Stage | Timing | Purpose |
Early warning | Without undue delay and within 24 hours of becoming aware of a significant incident | Alert the national Computer Security Incident Response Team or competent authority that a significant incident may have occurred |
Incident notification | Without undue delay and within 72 hours of becoming aware | Provide a fuller update, including severity, impact, and indicators of compromise where available |
Final report | No later than one month after the incident notification, where required by the Directive process | Explain the incident, severity, impact, cause where known, and mitigation measures |
The phrase NIS2 incident reporting 24 hours can be misleading if read too narrowly. The 24-hour step is an early warning, not the full investigation report. At that stage, the organisation may know only that a significant incident is suspected or confirmed. The 72-hour notification should contain more detail.
This creates a practical challenge. Many organisations cannot reliably report within these windows unless they prepare in advance. They need:
A clear definition of what may be significant
A route for internal escalation at any time
Named decision-makers and deputies
Pre-agreed reporting templates
Legal and communications input
Evidence capture during the incident
A record of when the organisation became aware of the incident
The “awareness” point matters because it starts the reporting clock. If teams disagree about when awareness began, the organisation may struggle to prove it acted on time.
Supply-chain security is now a core obligation
Article 21 specifically includes supply-chain security. This is not surprising. The ENISA Threat Landscape 2023 highlights threats that often enter through trusted relationships, software dependencies, service providers, and managed technology environments.
NIS2 supply chain security means organisations need to understand how third parties affect their ability to deliver critical services. Procurement can no longer focus only on cost, performance, and availability. It must also check cyber risk.
A useful supplier review should cover:
Whether the supplier supports critical services
What access the supplier has to systems or data
How the supplier reports incidents
Whether contracts include security duties
Whether the supplier uses subcontractors
How software updates and maintenance are controlled
Whether exit plans exist if the supplier fails or is compromised
This does not mean every supplier needs the same review. A catering supplier and a cloud hosting provider do not carry the same cyber risk. The work should be risk-based, with deeper checks for suppliers that can affect continuity, data, or regulated services.
Contracts should also match the reporting clock. If a supplier discovers an incident but waits several days to notify the customer, the customer may miss its own NIS2 deadline. For critical suppliers, contracts should require fast notification, cooperation during investigations, evidence preservation, and support for regulatory reporting.
How to verify your position against the Directive and ENISA guidance
A sound NIS2 scope review should combine legal classification, operational facts, and threat evidence. The legal text answers whether the Directive applies. Operational facts show where the duties land. Threat evidence helps prioritise controls.
Use the Directive text as the primary source:
Annex I to check sectors of high criticality
Annex II to check other critical sectors
Article 21 to confirm cybersecurity risk management measures
Article 23 to confirm incident reporting duties
Use the ENISA Threat Landscape 2023 to test whether your risk view reflects real-world threats. If the organisation’s risk register does not address ransomware, malware, social engineering, attacks on availability, data threats, and supply-chain compromise, it is probably incomplete.
For a practical NIS2 scope review, gather:
A list of legal entities and countries of operation
A map of products and services by sector
Employee and financial size data
A list of critical systems and services
A list of key suppliers and outsourced services
Existing incident response and reporting procedures
Current security policies, training records, and control tests
Board or management records showing oversight
The output should be a clear decision record. It should state whether the organisation is in scope, why, under which Annex category, and what immediate gaps exist under Articles 21 and 23.
The cost of waiting is higher than the cost of assessment
NIS2 compliance work takes time because it touches legal classification, supplier contracts, incident response, cyber controls, governance, and evidence. Waiting until an incident occurs is risky because Article 23 reporting windows are short, and Article 21 measures cannot be built overnight.
A focused gap review can answer the questions that matter most:
Are we in scope?
Are we essential or important?
Which services and entities are covered?
Can we meet the 24-hour and 72-hour reporting duties?
Do our supplier contracts support NIS2 obligations?
Do we have evidence that Article 21 measures are in place?
This article is for general information only and is not legal advice. Each organisation should verify its position against the Directive, national implementing rules, and its specific operating model.
If NIS2 may apply to your organisation, now is the right time to move from uncertainty to a documented position. Start with a structured assessment, confirm your scope, and identify the gaps before a regulator, customer, supplier failure, or incident forces the issue.
For a focused review of your NIS2 exposure and practical next steps, visit our Compliance Gap Review service.
