NIS2 Directive: what it covers, who it applies to, and how incident reporting works

NIS2, formally Directive (EU) 2022/2555, is the EU's cybersecurity law for organisations operating critical and important services, not a product law like the Cyber Resilience Act. ENISA states it entered into force on 16 January 2023, replacing the original NIS Directive, (EU) 2016/1148, and that member states had to transpose it into national law by 17 October 2024. For a device or component maker, NIS2 matters most if the business itself runs a covered service, for example as a manufacturer of medical devices, a data centre operator, or a managed service provider, rather than purely as a product vendor.

Who is in scope

NIS2 sorts in-scope organisations into two supervisory categories: essential entities and important entities. The European Commission's policy page describes the directive as reaching "medium-sized and large entities" across critical sectors, broadening coverage well beyond the original NIS Directive. The Commission's summary lists sectors carried over from NIS1, energy, transport, healthcare, finance, water management and digital infrastructure, alongside sectors newly added by NIS2:

Carried over from NIS1	Added by NIS2
Energy	Public electronic communications providers
Transport	Digital services (e.g. social platforms)
Healthcare	Waste and wastewater management
Finance	Critical product manufacturing
Water management	Postal and courier services
Digital infrastructure	Public administration (central and regional)
	Space sector

Exact size thresholds and which specific entities fall under "essential" versus "important" per sector are set out in the directive's annexes; the Commission's FAQ page checked for this guide does not itemise them, so confirm against the official text or your national transposing law before relying on a self-assessment.

Risk-management measures

The European Commission's FAQ describes NIS2 as requiring a "minimum list of 10 key elements that all companies have to address or implement." The FAQ names several of them explicitly: incident handling; supply chain security; vulnerability handling and disclosure; and the use of cryptography and encryption, where appropriate. The remaining elements of the minimum list are not itemised on the Commission page checked for this guide; to be confirmed against the directive's risk-management article before treating any list as complete.

Incident reporting: a three-stage clock

The Commission's FAQ sets out a staged reporting obligation once an entity becomes aware of a "significant incident":

Stage	Deadline	What it covers
Early warning	24 hours	Commission FAQ: notify within 24 hours of first becoming aware of the incident
Incident notification	72 hours	Commission FAQ: notify within 72 hours of becoming aware of the incident
Final report	1 month	Commission FAQ: due no later than one month after the incident notification

This table paraphrases the Commission's plain-language FAQ rather than quoting the directive's article text directly; the FAQ page checked for this guide does not state the underlying article number, so verify the exact wording and any sector-specific variations against the official directive text before building a compliance process on it.

ENISA's new role under NIS2

ENISA's own NIS2 policy page lists several tasks the directive assigns to the agency: developing and maintaining a European vulnerability registry; acting as secretariat for the European Cyber Crises Liaison Organisation Network (CyCLONe); publishing an annual report on the state of cybersecurity in the EU; supporting peer reviews between member states; and maintaining a registry for certain cross-border service providers, including DNS providers, top-level domain registries, domain registration services, cloud computing and data centre services.

NIS2 vs the Cyber Resilience Act

NIS2 and the Cyber Resilience Act are separate EU laws aimed at different things. NIS2 is an organisational law: it obliges essential and important entities in covered sectors to run a risk-management programme and report significant incidents. The Cyber Resilience Act is a product law: it sets cybersecurity requirements that hardware and software with digital elements must meet before being placed on the EU market, including its own 24-hour/72-hour reporting duty for actively exploited vulnerabilities and severe incidents in the product itself. The European Commission's NIS2 policy page describes the Cyber Resilience Act as complementing NIS2. A device maker can face both: CRA duties as a product manufacturer, and separately NIS2 duties if it also operates as an essential or important entity, for example by running its own cloud infrastructure or operating in a covered sector. See the Cyber Resilience Act guide and CRA 24h/72h vulnerability reporting for the product-level duty, which runs on a similar but legally distinct clock.

A workable starting point

1. Check whether your organisation is in scope at all. NIS2 applies to entities operating in the sectors above, above a size threshold; a pure product vendor with no covered-sector operations may be out of scope for NIS2 even while squarely in scope for the Cyber Resilience Act as a manufacturer.
2. Confirm your category and national transposition. Essential vs important status and exact obligations depend on your national transposing law, not the directive text alone, since member states had until 17 October 2024 to transpose it.
3. Build the incident-reporting clock before you need it. The 24-hour/72-hour/one-month cascade only works if someone already knows who to call and what the early-warning template looks like; rehearsing this before a real incident is the practical difference between meeting and missing the deadline.
4. Keep NIS2 and CRA evidence separate. They are different legal obligations with different triggers and timelines, even where both apply to the same organisation.

SoftWSP's passive OT and firmware vulnerability work feeds the asset and vulnerability data an incident-response and risk-management programme needs to meet NIS2 obligations; see OT Snapshot and device firmware security.

This guide is general information, not legal advice.