NIS2: national transposition differences that matter

NIS2 is a directive, not a regulation. Your client does not comply with NIS2; it complies with seven national statutes that each say something slightly different, commenced on seven different dates, and point at seven different authorities. The reporting clock is the part everyone quotes and the part that diverges least. Scope, aggregation of group entities and registration deadlines are where the real work is, and where an answer memorised from one country is wrong in the next.

This guide covers the seven member states in our national profile set: Germany, the Netherlands, Ireland, Belgium, Denmark, Sweden and Austria. Every country-level statement below comes from that profile data, which was checked against primary sources on 17 September 2026. National implementing acts, commencement orders and authority guidance move. Re-check the primary source before you rely on any date in a client deliverable.

Essential and important entities

The directive sets up two classes of in-scope entity — essential and important — built from a sector list plus a size test. Both classes carry risk-management and incident-reporting duties; the classes differ in how intensively the national authority supervises them. That much travels across borders. Nothing else about classification reliably does.

Start with the naming, because it affects how you read a client's own paperwork. Germany's BSIG 2025 does not use a two-way split at all: it runs besonders wichtige Einrichtungen (essential), wichtige Einrichtungen (important) and a separate category of operators of critical facilities. A German client who tells you "we're wichtig" has told you they are in the important tier, not that they matter a lot. Get that wrong in a memo and the rest of your advice points at the wrong supervisory regime.

Then the designations that bypass the size test entirely. In the Netherlands, the Cyberbeveiligingswet makes ministries, provinces, municipalities, water boards and critical entities essential by law (art. 8) — headcount and turnover never enter the analysis. Sweden's Cybersäkerhetslag brings all municipalities and regions into scope regardless of size. If your client is, or is owned by, a public body in either country, the size conversation is over before it starts.

Denmark runs the opposite move: carve-outs. The Danish NIS 2-loven does not apply where the energy preparedness law, the telecom security law or the financial sector rules in FIL §333 apply (§1(2)). A Danish energy or telecoms client is not automatically outside NIS2-equivalent obligations — it is under a different statute, with its own authority and its own deadlines, and you need to say which one in writing rather than leaving a NIS2 policy pack on the shelf that nobody is actually governed by.

A note on method that matters more in this regime than in GDPR work. Entity class is a legal qualification with supervisory and reporting consequences. It should be proposed with the trigger explained — sector, size, national designation rule — and then confirmed by the consultant who signs the file. A tool that silently assigns "essential" to a client is handing you a professional risk dressed up as a convenience.

Size-cap exceptions

The directive's default is the size-cap rule from Recommendation 2003/361/EC: the standard EU micro/small/medium definitions, including the rule that partner and linked enterprise figures are rolled into the entity's own. Most transpositions in this set keep that default. The exceptions are where multi-country clients get misclassified, because the group structure is identical in every country and the answer is not.

Denmark states its thresholds in the Act itself (§§4-5) rather than referring to the Recommendation: medium size at 50 employees and EUR 10m turnover and balance sheet total, large at 250 employees, EUR 50m turnover, EUR 43m balance sheet total. Because the Act does not incorporate the Recommendation by reference, whether partner and linked enterprise figures must be aggregated is not stated in the text. That is a genuine open question, not an oversight on your part. Flag it as unconfirmed rather than importing the Recommendation's aggregation rule by assumption.

The Netherlands aggregates. Partner and linked enterprises count toward size under the Cbw. A Dutch subsidiary of 30 people inside a 600-person group is very plausibly in scope.

Belgium and Austria both soften aggregation, on the same logic, in different words. Under the Belgian law, when counting partner and linked enterprises the CCB considers how independent the entity's network and information systems are (art. 3 §2). Austria's NISG 2026 is more directive: partner and linked enterprise data is not added where the entity's network and information systems are independent (§25(4)). For a group with genuinely separated IT per country, this is the difference between one in-scope entity and five. It is also the reason to document the separation now, while it is cheap, rather than argue it later under supervision.

Germany has a different lever. §28(3) BSIG lets negligible business activities be disregarded when classifying. A German entity with a small sideline in a listed sector is not automatically pulled in by that sideline.

The practical consequence for a portfolio: size is not a client-level attribute, it is a client-and-country attribute. Model it that way from the first intake, or you will redo the analysis every time a client opens an entity.

Registration duties by country

Registration is the obligation clients miss, because it is not incident-driven and nothing prompts it. It is also the one with the nearest hard deadline in most of these states.

Country	Law	Status	Registration	Deadline in the national text	Portal
DE	NIS2UmsuCG, BSIG 2025	In force 6 Dec 2025	Required	Within 3 months of first qualifying; changes within 2 weeks (§33 BSIG)	portal.bsi.bund.de
NL	Cyberbeveiligingswet	In force 15 Aug 2026	Required	Applies from 15 Aug 2026; the law sets no date; changes within 2 weeks	mijn.ncsc.nl
IE	National Cyber Security Bill	Not enacted	Not confirmed	Not confirmed	Not live
BE	Law of 26 Apr 2024 + RD of 9 Jun 2024	In force 18 Oct 2024	Required	By 18 Mar 2025 or within 5 months of identification (art. 13); digital infrastructure and digital providers by 18 Dec 2024 (art. 14)	atwork.safeonweb.be
DK	NIS 2-loven (Act 434/2025)	In force 1 Jul 2025	Required	Within 2 weeks of coming into scope (§10); digital providers within 3 months (§9)	samsik.dk
SE	Cybersäkerhetslag (SFS 2025:1506)	In force 15 Jan 2026	Required	As soon as possible (2 kap. 2 §); changes within 14 days	ncsc.se
AT	NISG 2026 (BGBl. I Nr. 94/2025)	Applies from 1 Oct 2026	Required	Within 3 months of entry into force, i.e. by 1 Jan 2027; later entrants within 3 months (§29(3))	usp.gv.at

Four things in that table deserve to be pulled out.

The clock starts from different events. Germany and Austria run from qualifying or from entry into force; Denmark runs two weeks from coming into scope, with three months for digital providers; Belgium ran a fixed calendar date with an alternative five-month window from identification, and an earlier fixed date for digital infrastructure and digital providers. "Register within three months" is a German sentence, not a European one.

Austria has not commenced yet. NISG 2026 applies from 1 October 2026; until then NISG 2018 governs. An Austrian client asking today what to do is asking about two regimes in sequence, and the registration deadline of 1 January 2027 is close enough to put in a plan now.

Change notifications are their own duty. Germany two weeks, the Netherlands two weeks, Sweden fourteen days. These are the ones that rot quietly: the client registers once, then changes contact person, legal name or entity structure and never updates. Put change events on the same tracker as the initial registration.

Registration is often two systems, not one. In Germany, entities authenticate through Mein Unternehmenskonto and then register in the BSI portal. In Denmark, reporting runs through virk.dk with coordination by the Danish Agency for Societal Security. Budget the client's time for the identity step, not just the form.

Incident reporting timelines and authorities

The deadlines converge. In all six transposed states in this set, the pattern is the same: early warning within 24 hours, fuller notification within 72 hours, final report within 30 days.

Country	Early warning	Full notification	Final report	Where it goes
DE	24 h	72 h	30 days (one month after the incident notification, §32 BSIG)	Federal Office for Information Security (BSI)
NL	24 h	72 h	30 days (one month after the incident notification)	NCSC via MijnNCSC, onward to the sector CSIRT and supervisor
IE	Not confirmed	Not confirmed	Not confirmed	NCSC (proposed)
BE	24 h	72 h	30 days	Centre for Cybersecurity Belgium (CCB)
DK	24 h	72 h	30 days	Competent sector authority and the national CSIRT, via virk.dk
SE	24 h	72 h	30 days	National Cyber Security Centre at FRA, via Cyberportalen
AT	24 h	72 h	30 days	Federal Office for Cybersecurity, via the sector or national CSIRT

Because the numbers agree, the value you add is not the numbers. It is these four points.

What the 30 days run from. The German and Dutch texts are explicit that the final report is due one month after the incident notification, not one month after the incident or its detection. That is a meaningfully different date in a long-running incident. For the other states the profile data records 30 days without recording the starting event — treat the counting rule as unconfirmed there and read the national text before you put a date in a procedure.

Sector-specific shorter clocks exist. Trust service providers notify within 24 hours in Belgium (art. 35 §2) and in Sweden. If your client is a trust service provider, the generic 24/72/30 procedure is not the procedure that applies to it.

The recipient is not always one body. The Dutch route sends one report through MijnNCSC which then reaches the sector CSIRT and the supervisor. Denmark names the competent sector authority and the national CSIRT. An incident procedure that says "notify the national CSIRT" is incomplete in both.

Authorities move. In Sweden, the NCSC at FRA has received registrations and reports since 1 July 2026; before that it was MCF. Any Swedish incident procedure written in the first half of 2026 names the wrong recipient today. This is the single strongest argument for holding authority names as maintained data rather than as prose typed into a Word template.

Ireland is the honest gap. NIS2 is not transposed. The National Cyber Security Bill is not enacted, there is no in-force date, and the profile records no early-warning, notification or final-report deadline, and no confirmed registration duty — because none is confirmed. The Irish NCSC's position is that registration and reporting portals open once the law is in place, and NIS1 continues to apply to existing operators of essential services. The Commission referred Ireland to the Court of Justice on 8 July 2026 for failure to transpose. Sources: ncsc.gov.ie/nis2 and the Commission's referral notice.

Do not paper over this. The correct deliverable for an Irish entity is a statement that the national obligations are not yet law, that NIS1 duties continue where they already applied, that the client should build to the directive's baseline because the eventual statute will not be gentler, and that the registration and reporting sections will be completed when the Bill is enacted. A consultant who writes "notify the Irish NCSC within 24 hours" today has invented an obligation, and the client's counsel will notice.

Management body obligations

The national profile data behind this guide carries reporting, registration, authority and threshold fields. It does not carry a country-level field for management body duties, so everything in this section is directive-level framing. Where a client needs certainty on a national variant — approval formalities, training requirements, the exact personal consequences — read the national text.

At directive level the design is unusual and worth explaining to clients in plain terms: risk-management measures are not something the security team adopts on its own authority. The management body approves them, oversees their implementation, and carries personal accountability for that approval. Cybersecurity stops being a delegated technical matter and becomes a board-minute matter.

That changes what you produce. A risk-management policy with no evidence that management saw and approved it satisfies the paperwork and misses the obligation. Two artefacts belong in every NIS2 pack:

1. A management accountability record. Who approved the measures, on what date, on the basis of which version of the risk assessment. Short, dated, signed.
2. A named notification authority list. Who inside the client is authorised to file the early warning, with a deputy. A 24-hour clock does not survive "the only person who can send this is on leave".

There is a portfolio consequence too. Approval is version-bound: when the measures change materially, the approval that covered the previous version does not cover the new one. Track approval dates against document versions, or the record quietly becomes stale evidence.

Advising multi-country clients

The operating model that works is a matrix, not a document. Rows are your client's entities; columns are country, sector, in-scope status, proposed class, registration status and deadline, notification authority, and the date each of those was last verified. One client with five entities is five rows, not one NIS2 engagement.

Four habits keep that matrix trustworthy.

Separate the confirmed from the assumed, visibly. A blank cell and a cell that says "not confirmed" are different objects. Ireland's reporting deadlines are not confirmed; Denmark's aggregation rule is not confirmed; those are findings, and a client will act correctly on an explicit "not confirmed at the time of writing" and incorrectly on a plausible guess. Never fill a gap from memory — that is the failure mode that costs a consultant a relationship.

Sequence the work by deadline, not by country. Registration deadlines are near-term and binary; risk-management maturity is long-term and gradual. For a client in Belgium, Germany and Denmark, the registrations dominate the first month. For an Austrian entity, 1 January 2027 is the date to build the plan around. Irish entities get baseline work now and the national sections later.

Write the procedure per country, generate it from data. The 24/72/30 rhythm invites a single generic procedure. The recipient, the portal, the escalation path and the sector-specific 24-hour variants are what actually differ, and those are exactly the fields that go stale. Authority names, URLs and deadline tables should be assembled from a maintained source, not retyped — Sweden's change of receiving authority in July 2026 is the worked example of why.

Date every country claim and re-verify on a schedule. The facts in this guide were checked on 17 September 2026. Put the equivalent date on your own matrix, and re-check before each client deliverable. That is also the honest line to give the client: this is current as of a stated date, and here is who watches it.

This is the kind of per-country bookkeeping that clausebench keeps as maintained data so the procedures you hand a client carry the right authority and the right deadlines — it prepares the documentation required by the regime and speeds up your work, and the qualification calls stay with you.