France's Resilience Law (NIS2): what becomes mandatory, and 3 projects to start without waiting for the decrees

Introduction

For two years now, the question that comes up in almost every NIS2 meeting has been the same: "when exactly does this apply?". It is a fair question, and it is also the best way to lose another six months.

The honest answer is that the effective date will not change the amount of work. A company that discovers, on the day the decrees are published, that it has no inventory of its exposed assets will face exactly the same project with less time to do it. So this article does two things: a dated status update on the French transposition, then the three projects that depend on no decree and that you can start today.

Where things actually stand

Member states were required to transpose the NIS2 directive by 17 October 2024. France missed that deadline, which triggered an infringement procedure from the European Commission. The transposition vehicle, the bill known as the "Resilience Law", passed first reading in the Senate in March 2025, then took more than a year to come back before the National Assembly, where it was debated in the summer of 2026.

The text is organised in three parts: resilience of critical entities (the CER directive), cybersecurity (NIS2) and the financial sector (the DORA regulation). Three different regimes in a single law, which explains part of the delay.

And here is the part most people miss: the law itself contains almost no technical requirements. It sets the framework, designates the competent authority, provides for penalties, and defers the substance to implementing decrees and to reference documents published by ANSSI, sector by sector. Waiting for "the law" before starting means waiting for the wrong document.

Who is in scope

NIS2 takes the French perimeter from roughly 500 entities under NIS1 to an order of magnitude of 15,000. That is a change in nature, not only in scale: it moves from operators of vital importance to a broad slice of the economy.

The mechanism crosses two criteria, sector and size.

The 18 sectors cover energy, transport, health, water, digital infrastructure and services, public administration, manufacturing, postal services, waste management, food production and a few others. The point that surprises people most often: digital is heavily represented, which pulls in managed service providers, hosting companies, marketplaces and IT contractors, many of whom assumed they were out of scope.

The difference between the two categories is less about the obligations, which are close, than about supervision: essential entities can be inspected proactively, important entities mostly after the fact, following a report or an incident.

The supply chain trap

There is a second way to be affected by NIS2, and it catches far more companies than the first: being a supplier to an entity that is in scope.

Article 21 of the directive requires regulated entities to manage the security of their supply chain. In practice: your regulated customers will send you questionnaires, write security clauses into contracts, and ask for evidence. A thirty-person company entirely outside the perimeter can therefore end up having to demonstrate its security posture because it sells to a healthcare operator.

That mechanism is already running, it waits for no decree, and it is today the main reason out-of-scope companies call us.

Penalties, and management liability

The ceilings set by the directive are well known: up to 10 million euros or 2% of worldwide turnover for an essential entity, up to 7 million or 1.4% for an important entity, whichever is higher.

But the provision that should hold a board's attention is elsewhere. NIS2 makes management bodies accountable for approving risk management measures and overseeing their implementation. They are also required to follow training. This is no longer a topic you delegate entirely to the CISO by signing a budget once a year.

The three projects to start now

Here is the useful part. These three projects share one property: they will be required whatever the final wording of the decrees, they take time, and they hold value on their own even if you turn out to be out of scope.

Project 1: know where you stand, and write it down

Qualify your status (essential, important, out of scope) and document the reasoning, sector by sector if you run several activities. A group with a logistics subsidiary and an industrial one may well have two different answers.

Then identify who owns the topic internally. Not "the IT department": a person, with a name, a mandate and access to the board. That is what an inspection checks first, and it is the cheapest of the three projects.

Project 2: map what you expose, and what you depend on

This is the longest of the three, which is exactly why it should start first. Two halves.

The technical half. You cannot produce a credible risk analysis on a perimeter you do not know. And the declared inventory is nearly always short of reality: campaign subdomains, staging environments left online, leftovers from acquisitions. We laid out the method and the commands in our guide on inventorying your external attack surface, and the broader exercise in mapping your company's information system.

The supplier half. List your critical dependencies: hosting providers, SaaS vendors, managed service providers, contractors with access to your systems. For each one, note what breaks if that supplier breaks. This list almost never exists, and yet it is precisely what article 21 targets.

Project 3: be able to notify an incident within 24 hours

This is the most concrete NIS2 obligation, and the most underestimated. The notification timeline is tight:

1. Early warning within 24 hours of becoming aware of a significant incident.
2. Full notification within 72 hours, including an initial assessment.
3. Final report within one month.

Twenty-four hours feels comfortable right up until the incident lands on a Friday evening. What you need prepared is short: who decides an incident is "significant", who writes, who approves, through which channel it goes out, and where the technical material sits. Run the drill once. You will probably find that your decision chain already takes more than 24 hours just to reach the right people.

What about the compliance report itself?

Once the projects are running, the next question arrives quickly: in what form do you present all this? We devoted a full guide to the expected structure, the article 21 measures and the technical evidence to attach: how to write a NIS2 compliance report.

And if you are already pursuing ISO 27001, the overlap is significant. Our recommendations on automated vulnerability scanning for ISO 27001 produce the same kind of evidence NIS2 expects on vulnerability management.

Where to start today

If you only do one thing after reading this, do project 2, technical half. It is the only one whose result will surprise you, and it conditions all the others.

Beyond that, Flawfence automates the technical side of compliance: continuous mapping of your external surface, detection and validation of genuinely exploitable vulnerabilities, and dated reports that serve as evidence for NIS2 and ISO 27001 alike. The rest, organisation, governance and crisis management, stays with you. No tool will do it for you, and be wary of the ones that claim otherwise.

FAQ

Has the Resilience Law been enacted?

At the publication date of this article the text is at the end of its parliamentary journey, with enactment expected during 2026. The implementing decrees and ANSSI's sector reference documents will follow. Check the current status before building a timeline on it.

How long will we have to become compliant?

The stated principle is a progressive ramp-up, in the order of three years after entry into force, with registration with ANSSI first and inspections coming later. That progressivity applies to the technical requirements, not to registration.

Is a 40-person company in scope?

In principle no, the important-entity threshold starts at 50 employees in the listed sectors. But two exceptions matter: some entities are designated regardless of size (trust service providers, domain name registries and public network operators in particular), and above all, your regulated customers can impose equivalent requirements on you contractually.

Does NIS2 mandate vulnerability scanning?

Not under that name. Article 21 requires vulnerability handling and disclosure, without prescribing a tool or a frequency, much like control A.8.8 of ISO 27001. In practice, demonstrating vulnerability handling without recurring detection is very hard.

What if we do not know which sector we fall into?

Use the MonEspaceNIS2 eligibility simulator, and if doubt remains, ask the question in writing rather than deciding alone. Getting the qualification wrong is expensive either way: you either fund obligations that do not apply, or you find out late that they do.

Conclusion

NIS2 is not a deadline, it is a permanent regime. The enactment date decides when inspections start, not how much work there is. The companies that come out of this best will not be the ones that followed the legislative news most closely, but the ones that already know what they expose, who they depend on, and who to call on a Friday evening.

Start with the mapping. Everything else organises itself around it.