NIS2 Is Transposed Unevenly: Building One Control Set That Satisfies Multiple Member States

NIS2 is a directive, not a regulation, which means there is no single NIS2 to comply with. There are as many versions as there are member states that have transposed it — and a group operating across borders now has to reconcile them.

The transposition deadline for Directive (EU) 2022/2555 was 17 October 2024. It passed with most member states nowhere near ready. By mid-2026 the picture is still uneven: roughly twenty member states have transposing law in force, a couple more have adopted it with entry into force pending, and a handful — including large economies still moving their bills through parliament — had not finished at all. The European Commission opened infringement proceedings against the laggards, sending formal notices in November 2024 and escalating to reasoned opinions in May 2025. That is the environment a cross-border group has to build controls in: a moving target where the same directive bites differently, and on a different timeline, in every country you touch.

The instinct is to run this country by country — a Polish programme, a German programme, an Italian programme. That is how you end up maintaining a dozen overlapping compliance efforts that drift apart and cost a fortune to keep aligned. There is a better shape.

Why the same directive produces different rules

A directive sets an objective and binds member states to a result; the national legislature chooses the form and method. NIS2 is also explicitly a minimum-harmonisation instrument — Article 5 lets member states adopt requirements that go beyond it. So divergence is not an accident of sloppy drafting. It is designed in.

The core of the directive is common everywhere it lands. Article 21 requires cybersecurity risk-management measures on an all-hazards basis, and Article 21(2) lists ten baseline areas — risk analysis and information-system security policies, incident handling, business continuity and backup, supply-chain security, security in acquisition and development, policies to assess the effectiveness of measures, basic cyber hygiene and training, cryptography, human-resources security and access control, and multi-factor authentication. Article 23 sets the reporting cadence: an early warning within 24 hours of becoming aware of a significant incident, a fuller notification within 72 hours, and a final report within one month. Those are the fixed points.

What varies sits around them. Which entities are caught — the directive’s size-cap rule in Article 2 pulls in medium and large entities in scope sectors, but member states may designate smaller ones, and several have. The classification into essential versus important entities under Article 3, which drives whether supervision is proactive or reactive. Registration mechanics and deadlines. Sector scope at the edges. Sanction ceilings and the precise trigger points for management-body liability. Some states have layered additional documentation, audit or notification duties on top. The Netherlands and Ireland, for instance, arrived late and with their own choices baked into the transposing law — the kind of local detail I have written about in where the Cyberbeveiligingswet and the NCSD bill actually bite.

The superset baseline

The design move is to stop treating each national law as a separate universe and treat them as one baseline plus a set of deltas. Build a single control framework calibrated to the strictest position across your footprint, then record, per country, only where that country demands something the baseline does not already deliver.

Concretely, take the ten Article 21(2) areas as your control spine — they are common to every transposition, so a control that satisfies them is portable by construction. For each area, set the baseline at the highest bar any of your member states imposes. If Germany’s transposition demands MFA on a broader population than Poland’s, the baseline is the German position and Poland is satisfied automatically. If one state requires 72-hour final-report content that another does not, you write to the fuller template everywhere. You are deliberately over-complying in the lower-bar jurisdictions, because the cost of one slightly heavier control set is far below the cost of maintaining several and proving they each map correctly.

This is the same logic behind treating overlapping cyber regimes as a single build rather than a stack of separate ones — the argument I have made for running the AI Act, DORA and NIS2 as one programme. NIS2’s own internal divergence is just that problem in miniature, twenty times over.

The deltas are where the work is

A superset baseline does not make the differences disappear. It isolates them. What remains after you have set the baseline is a short, explicit list per country of the things that genuinely cannot be harmonised — and those are almost always procedural rather than technical.

Registration is the clearest example: you register with the competent authority named in each national law, to that country’s deadline and format, and no baseline control removes the obligation to do it locally. Incident notification routes to a different national CSIRT or authority in each state, on the common 24/72-hour clock but through different channels and portals — the reason a group needs a single reporting map that resolves to the right recipient per incident, which is exactly the artefact behind the board’s cyber-incident reporting map. Entity classification has to be run against each national test, because essential-versus-important status changes your supervisory exposure. And identity sits underneath most of it: access control and MFA are in the Article 21(2) baseline, so a single well-governed identity plane does a lot of the heavy lifting across every jurisdiction at once — the case for treating IAM as the control plane for DORA and NIS2.

Document each delta as a named exception with a reason and an owner. “Germany requires X; baseline already covers it” needs no action. “Country Y requires a local registration filing the baseline cannot satisfy” is a task with a deadline and a responsible person. The register of deltas is the thing you hand a supervisor, and it is the thing that keeps the framework honest as more transpositions land.

Designing for the transpositions that have not happened yet

The states still finishing their bills are the reason this architecture earns its keep. When a late transposition finally enters force, you do not stand up a new programme. You run its final text against the baseline and ask one question: does it demand anything the baseline does not already deliver. Usually the answer is a handful of procedural deltas — a registration route, a national authority, a sanction ceiling — and the technical controls are already in place because you built to the strictest position months earlier.

That is the payoff. Country-by-country compliance treats every new transposition as another programme to build. A superset baseline treats it as a diff to review. The divergence does not go away — you just stop paying for it in duplicated effort, and start absorbing it as a controlled set of exceptions against one framework you already run.

Reconcile the divergence in the architecture, or you will reconcile it, more expensively, in a room full of national regulators who each read their own version of the same directive.