NIS2: work out your scope before a customer does it for you

The timetable slipped, the obligations did not

Directive (EU) 2022/2555 was adopted on 14 December 2022, repeals NIS1 with effect from 18 October 2024, and had to be transposed by 17 October 2024. Most member states missed it: letters of formal notice to twenty-three of them on 28 November 2024, reasoned opinions on 7 May 2025, referral to the Court of Justice against Ireland, Spain, France and the Netherlands on 8 July 2026.

France sits in that group. The bill on the resilience of critical infrastructure and the strengthening of cybersecurity, tabled on 15 October 2024, transposes NIS2, the CER directive and the national elements of DORA in a single text. The Senate passed it on 12 March 2025, the National Assembly's special committee adopted its version on 10 September 2025, and the floor debate then slipped for the best part of a year — partly over an argument that has nothing to do with NIS2, the legal protection of end-to-end encryption. It is now listed for July 2026, with promulgation expected over the summer. As this article goes out, at the end of July 2026, the text is still not promulgated: check that before relying on it, because it is the one passage the parliamentary calendar can date.

The delay produces the same reflex everywhere: wait. It rests on a misreading. Articles 2, 3, 20, 21 and 23 will not be rewritten in Paris, which has no power to do so.

ANSSI did not wait. On 17 March 2026 it published version 2.5 of the Référentiel Cyber France, a working document tied to Article 14 of the bill. ReCyF sets twenty security objectives, the first fifteen for important and essential entities alike, objectives 16 to 20 for essential entities only. The acceptable means of compliance it proposes are not mandatory, but an entity that implements them can rely on them during an inspection. It is already the lens the French regulator will read you through, published ahead of the law it will serve.

Essential, important, or out of scope

The test has two steps: fall within one of the entity types listed in Annex I or II, then clear the size cap in Article 2 — the size of a medium-sized enterprise under Recommendation 2003/361/EC, meaning fifty staff, or ten million euros in annual turnover and balance sheet total.

Article 3 then splits the two regimes. An Annex I entity that exceeds those ceilings is essential: two hundred and fifty staff, or more than fifty million euros of turnover and more than forty-three million of balance sheet total. So are qualified trust service providers, TLD name registries, DNS service providers and central government bodies, whatever their size. Everything else is important.

Article 2(2) cuts through the size logic, and its sharpest exception is the one least often quoted: an entity falls in scope regardless of size if it is the sole provider in a member state of a service essential to critical activities, or if it carries particular importance at national or regional level. Neither test can be run on a spreadsheet.

Scoping is genuinely hard, for three reasons. Qualification happens legal entity by legal entity, not at group level: a sixty-person subsidiary running an Annex I service is in scope even if its holding company is not. Annex I then contains a category many did not see coming, B2B ICT service management, where managed service providers and managed security service providers are named outright, so a mid-sized integrator running someone else's endpoints is caught. And Article 26 shifts jurisdiction, for most digital players, to the member state of the main establishment — where decisions on cyber risk management are predominantly taken, which is not always where the head office sits.

Hence an observation I make without pleasure: most of the organisations we work with did not discover they were in scope through their own analysis. They discovered it in a customer's supplier questionnaire, with a fortnight to reply. That is the worst possible moment to start, because the answer commits you.

What a regulator reads into “appropriate and proportionate”

Article 21(1) calls for appropriate and proportionate measures, built on an all-hazards approach, taking account of the state of the art and the cost of implementation, calibrated to the entity's exposure and size. The phrase gets read as an escape clause; it is not one.

Proportionality is not an argument, it is a demonstration, and it runs through a dated, traceable risk analysis that has been decided on and approved. An entity that can produce a current EBIOS RM analysis, a treatment plan and a list of residual risks explicitly accepted has a defensible position. Without a risk analysis there is no proportionality, only undocumented trade-offs.

Article 21(2) lists ten minimum families, from risk analysis policy through business continuity and supply chain security to multi-factor authentication. A serious ISO 27001 management system already covers most of them. Two points slip through almost every time: (f), which asks you to assess how effective your measures are rather than how far along they are, and (d), which I come back to below.

For eleven categories of digital players, a far more precise text already exists. Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 turns Article 21(2) into detailed technical requirements and puts numbers on significance — direct financial loss above five hundred thousand euros or 5 % of annual turnover, whichever is lower, exfiltration of trade secrets, death or serious harm to health. Everywhere else the Article 23(3) test stays qualitative.

Article 20, and why the budget conversation changes

One sentence in the directive does more for security than the whole of Article 21. Article 20 requires management bodies to approve cyber risk management measures, oversee their implementation, and be capable of being held liable for the entity's breaches of Article 21.

It is the first time a European cyber text has pushed accountability above the CISO, and the effect is immediate: a remediation plan turned down two years running passes in a fortnight once the executive committee understands it has to approve it, or refuse it, on the record.

What Article 20 actually demands is concrete: an agenda item, a dated deliberation, minutes that name what was approved — the policy, the risk appetite, the treatment plan, and above all the list of residual risks accepted. That last document is what protects directors, because it turns presumed negligence into a decision owned. Appointing a NIS2 lead does not move that responsibility an inch.

That table reads counter-intuitively: the gap between the two regimes is not really about the measures, since Article 21 applies to both, but about the odds of being inspected. An important entity can go years without seeing an auditor. It will see one the day after its first notified incident.

Twenty-four hours, seventy-two hours, one month

Article 23 bites as soon as an incident is significant: severe operational disruption or financial loss for the entity, or considerable damage caused to others. The cascade runs in three steps.

1. Early warning within twenty-four hours of becoming aware of the incident, stating only whether it is suspected to be malicious and whether it could have cross-border impact.
2. Incident notification within seventy-two hours: initial assessment of severity and impact, plus any indicators of compromise.
3. Final report within one month of the notification, with root cause and mitigation measures. If the incident is still ongoing at that point, a progress report takes its place and the final report follows a month after the incident is handled.

Article 23 also requires you to tell recipients of the service who may be affected. A regulatory notification stays confidential; a customer notification never stays confidential for long.

The hard part is not the deadline, it is the word “aware”. The clock starts in the SOC at three on a Sunday morning, when an analyst correlates two alerts. If your procedure hands the significance call to a crisis committee that meets Monday morning, the twenty-four hours are gone. So write two things down in advance: a significance test mechanical enough for one person to apply, and a named, reachable delegate authorised to file the early warning alone. That warning is not a report — it runs to a few lines. The commonest mistake is holding it back until you understand what happened.

Supply chain, where almost every programme gives way

Bluntly: Article 21(2)(d) is the weakest point in nearly every NIS2 programme we audit. It asks you to address the security of relationships with direct suppliers and service providers, and Article 21(3) requires you to take each one's specific vulnerabilities into account.

What we actually find: a three-hundred-line supplier spreadsheet pulled from accounts payable, a boilerplate security clause in the contracts, a questionnaire sent once and never read again, and no link between the three. No criticality, no review, no evidence.

Three corrections change the trajectory. Rank by the service delivered, not the invoice: what matters is not what you pay a provider but what stops if they go down, what they can see of your data, and what administrative access they hold. A provider on fifteen thousand euros a year with a domain admin account is a major risk; a two-million-euro supplier with no access to your systems is not. Stop treating questionnaires as controls: a questionnaire is a statement, evidence is an audit report or a test result. And align contractual deadlines with your own — if your provider commits to telling you within seventy-two hours, your twenty-four-hour warning is structurally late.

Where to start if you are starting now

1. Qualify legal entity by legal entity, and write the conclusion down — including “out of scope”, which is the one you will have to defend.
2. Draw the technical perimeter: the systems supporting the listed services, not the whole estate. Draw it too wide and the programme dies on budget.
3. Run the risk analysis on that perimeter. It is ReCyF objective 16, and it is what makes proportionality defensible.
4. Measure the gap against ReCyF, starting from your ISO 27001 statement of applicability if you have one.
5. Cost the remediation plan with its residual risks and have the management body formally approve it. Without a deliberation, Article 20 is not satisfied.
6. Test the notification chain with an exercise, not a procedure. Success looks like an early warning filed inside twenty-four hours, on a Sunday.

The referral of 8 July 2026 changes nothing in your internal timetable, but it marks the outer edge of it. Organisations that waited for the law will find that a serious NIS2 programme takes twelve to eighteen months, and no implementing decree will shorten that.