NIS2
The NIS2 Directive's management-body duties, its Article 21 cybersecurity risk-management measures and its Article 23 incident reporting stages, for essential and important entities in the EU.
What NIS2 is
The NIS2 Directive, Directive (EU) 2022/2555, replaced the original NIS Directive and widened EU cybersecurity obligations from a narrow set of operators of essential services to essential and important entities across eighteen sectors, from energy, transport, health and digital infrastructure to manufacturing, food, postal services and digital providers. Member States had to transpose it by 17 October 2024, and an entity's binding obligations come from the national law that transposes it.
Three articles carry most of what an in-scope entity has to show. Article 20 makes the management body approve and oversee the cybersecurity risk-management measures, be accountable for them and take training. Article 21 requires appropriate and proportionate measures on an all-hazards basis and lists ten that every entity must at least cover, from risk analysis and incident handling to supply chain security, cryptography and multi-factor authentication. Article 23 sets the reporting clock for a significant incident: an early warning within 24 hours, an incident notification within 72 hours and a final report within one month.
The supply chain measure reaches suppliers too. An in-scope entity has to manage the security of its relationships with its direct suppliers and service providers, so a supplier that is not itself covered by NIS2 is still asked to evidence its practices through its customers' due diligence and contracts.
Who it applies to
- Medium-sized and larger entities in the sectors listed in Annexes I and II of the Directive, and smaller entities a Member State designates, such as a sole provider of an essential service.
- Digital infrastructure and ICT service management providers, including cloud, data center, DNS, managed service and managed security service providers.
- Suppliers and service providers to in-scope entities, through the supply chain security measures their customers have to apply.
- Groups operating in several Member States, which have to work from each national transposing law rather than the Directive text alone.
How it is structured in CMDash
CMDash seeds Article 20, Article 21 and Article 23 with one row per paragraph, and one row for each point of Article 21(2) and of Article 23(4), so each of the ten minimum measures and each reporting stage carries its own owner, status and evidence. Control ids are the Directive's own article references (for example Art.21(2)(d)); the statements and evidence lines are CMDash's paraphrase.
| Governance | 2 |
| Cybersecurity Risk-Management Measures | 13 |
| Reporting Obligations | 8 |
Control rows ready to assign, track, and evidence from your first sign-in.
Scope: Articles 20, 21 and 23 only, in CMDash's own words rather than the Directive's text. National transposing laws and the Commission implementing acts under Article 21(5) set the binding detail and are not seeded.
The control text
Controls carry their identifier, title, and CMDash’s own evidence-requirement guidance. No verbatim source text is bundled for this framework. If you hold the official document, you can load its text through the framework CSV import.
What CMDash does for NIS2
- Each obligation is a tracked row with an owner, a status, reviewer notes and dated evidence, grouped as governance, risk-management measures and reporting obligations.
- A seeded crosswalk to ISO/IEC 27001:2022 Annex A and to NIST CSF 2.0, so a program already tracked against either shows which NIS2 measures it already speaks to. Most edges are marked as partial, because most NIS2 measures bundle several practices.
- One connector rule reaches NIS2 through that crosswalk: the Okta multi-factor coverage rule on ISO 27001 A.8.5 also applies to the multi-factor authentication measure, Art.21(2)(j), and is labeled as derived.
- The supply chain measures sit next to CMDash's vendor register, questionnaires and continuous monitoring, and the reporting stages next to incident records, so the evidence for each comes from where the work is done.
- Every control is a tracked row with an owner, a status (not started, in progress, implemented, not applicable, at risk, failing), reviewer notes, and its own evidence requirements — not a checkbox on a spreadsheet.
- Evidence is uploaded against a specific control, dated, and kept on that control, so an assessor can see what was true when.
- Gaps export to a POA&M CSV — every control that is not implemented and not marked out of scope, with owner, status and evidence requirements.
- Policies you author in CMDash link to the controls they govern, so each control row shows which living policies stand behind it.
- A time-boxed, read-only external assessor seat can be scoped to just this framework, with an expiry date you set and a record of every page they opened.
What it shares with your other frameworks
CMDash seeds control-to-control crosswalk mappings, each with a confidence score. They are what stops the same artifact being gathered twice, and they are how a second framework costs a fraction of the first.
Where the evidence comes from
CMDash reads from the security tools you already run and turns what they report into control evidence. These are the integrations whose data lands closest to NIS2’s control groups — you decide which control each signal evidences, and CMDash keeps it current from then on.
Where CMDash stops
Know the boundaries before you plan the work.
- National transposing laws set the binding obligations, deadlines, competent authorities and penalties, and they differ between Member States. They are not seeded, and neither is Commission Implementing Regulation (EU) 2024/2690, which details the Article 21 measures for digital-infrastructure and digital-service entities.
- The wording is CMDash's paraphrase of the Directive, not its text. Scope and classification (Articles 2 and 3), registration, supervision and penalties are not seeded as controls.
- CMDash tracks the reporting obligations and holds the evidence; it does not submit early warnings, notifications or reports to a CSIRT or competent authority.
- The regulatory radar's NIS2 entry still reads its readiness figure from NIST CSF 2.0 and ISO 27001 controls rather than from this framework.
- Nothing here is legal advice. Whether NIS2 applies to an entity, and whether it is essential or important, is a legal determination under national law.
Common questions
What are the NIS2 reporting deadlines?
For a significant incident, Article 23(4) sets an early warning within 24 hours of becoming aware of it, an incident notification within 72 hours, an intermediate report if the CSIRT or authority asks for one, and a final report no later than one month after the notification. If the incident is still ongoing then, a progress report is due and the final report follows within one month of handling it. National law can add detail, so check the transposing law that applies to you.
We already hold ISO 27001 certification. Are we NIS2 compliant?
Not automatically. An ISO 27001 program covers much of the ground in Article 21, and the seeded crosswalk shows where, but NIS2 adds obligations ISO 27001 does not have, such as management-body accountability and the timed reporting to a CSIRT or competent authority. Your certification is evidence toward the measures, not a substitute for them.
Does CMDash decide whether NIS2 applies to us?
No. Whether an entity is in scope, and whether it is essential or important, depends on its sector, size and the national law of each Member State it operates in. CMDash tracks the obligations once you have scoped the framework.
Also in Privacy & Sector Regulation
Paid plans cap how many frameworks you run at once, never which ones — NIS2 is available on every paid plan.
View pricingReady to see your posture?
Start a 30-day free trial of any paid plan — a card is required, and it converts unless you cancel — or sign up for Free with no card at all.