NIS2 is nearly two years late in four countries. It reached your sales cycle on time.

Your biggest customer's procurement team has sent over a new security addendum, and it is not the usual two pages. It wants incident notification on a clock, a right to audit you, background checks on your staff, cybersecurity conditions on your subcontractors, and the return and destruction of their data when the contract ends. The covering email cites NIS2, the EU's cybersecurity directive for critical and important sectors.

Which is confusing, because the news says NIS2 is stuck. On 8 July 2026 the European Commission referred Ireland, Spain, France and the Netherlands to the EU's Court of Justice 4 for still not having transposed the directive, that is, written it into their national law, nearly two years past the transposition deadline 5 of 17 October 2024. Twenty-three member states missed that deadline and got formal warnings 7 in November 2024, then a sharper round 8 in May 2025, and the four holdouts went to the Court.

I have watched founders read a headline like that and file the whole regulation under "not yet". The addendum in your inbox is the answer to that filing: the version of NIS2 that lands on a software vendor almost never arrives from a regulator. It arrives from a customer, in a contract, and that channel has been open for a while.

Does NIS2 apply to my SaaS at all?

Most founders I talk to answer this in about two seconds: we are not energy, not a hospital, not a bank, next question. It is worth spending longer than two seconds, because the test has two parts.

First, are you a listed type of entity? Annex I of the directive lists cloud computing service providers under "Digital infrastructure", and its "ICT service management" sector lists managed service providers and managed security service providers 1. Now the part that surprises people: recital 33 (a recital is the explanatory preamble of an EU law, guiding how the operative articles are read without creating obligations itself) names Software as a Service, in writing, as one of the service models of cloud computing 1.

Before you panic or relax: the operative definition in Article 6(30) is narrower than the recital sounds. A cloud computing service must enable "on-demand administration and broad remote access to a scalable and elastic pool of shareable computing resources", which the recital glosses as customers provisioning capacity for themselves, without human interaction from the provider 1. A hosting platform where customers spin up their own capacity is squarely inside. A vertical B2B application where nobody provisions anything is a genuine argument, and I have not seen it settled. What I would stop saying is "we are just an app, so NIS2 is not about us", because that sentence assumes the answer.

Second, are you big enough? Article 2(1) catches entities that qualify as medium-sized or larger under the EU's SME definition 1: medium-sized means fewer than 250 staff and turnover up to EUR 50 million or a balance sheet up to EUR 43 million 3. Below medium-sized you are generally out, unless one of the Article 2(2) special cases applies. In scope as medium-sized makes a cloud, managed service or managed security service provider an important entity; above the medium-sized ceilings, an essential one, with heavier supervision and fine ceilings of at least EUR 10 million or 2% of worldwide turnover 1.

One thing to check if a larger group controls you: the SME definition adds 100% of the numbers of linked enterprises, those held through majority voting rights or equivalent control, so a thirty-person portfolio company would count the group's headcount 3. But recital 16 lets member states treat such an entity as not medium-sized where its systems and services are genuinely independent of the group 1, so the answer depends on which member state supervises you, which is itself the useful thing to know before you assume either way.

If my country has not transposed it, am I off the hook?

In a narrow sense, yes. A directive binds member states to legislate, so until yours has done it, your national regulator has no NIS2 rulebook to enforce against you. The Commission's court case is against the state, and the penalties are the state's to pay 4. But it is a bad thing to plan around, for two reasons, and close to irrelevant for a third.

First, it is temporary by construction. The Netherlands was on the July referral list, and its own implementing law, the Cyberbeveiligingswet, enters into force on 15 August 2026, bringing more than 8,000 Dutch organisations under a legal duty of care 10. Being late and being about to switch on are not alternatives.

Second, where you are supervised is not where you are incorporated. Article 26 puts cloud providers, managed service providers and several other digital entities under the jurisdiction of the member state where decisions about cybersecurity risk-management measures are predominantly taken, not where the holding company sits 1. If those decisions are made in an office in a member state that has transposed while the entity is Irish, Ireland's delay is not your delay. One caveat: a Commission proposal from January 2026 would simplify exactly these jurisdictional rules 6, so do not build an establishment decision on Article 26 without checking where that proposal has got to.

Third, and this is the point of this piece: your customers in member states that did transpose are already bound, and their obligations name you.

What does my customer's supply chain duty require of me?

Article 21(2)(d) requires every in-scope entity to include, in its risk-management measures, "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers" 1.

Direct suppliers is the phrase that reaches you. Sell software to a hospital group, a utility or a logistics operator in a member state that has transposed, and you are inside their obligation, whatever your own scope status. Article 21(3) sharpens it: when deciding which measures are appropriate, your customer must take into account "the vulnerabilities specific to each direct supplier and service provider and the overall quality of products and cybersecurity practices of their suppliers and service providers, including their secure development procedures" 1. That last phrase is your engineering process, named in a directive as something your customer must assess.

One carve-out: banks and other financial entities answer to DORA, the EU's financial-sector resilience regulation, instead, because NIS2 stands down where a sector-specific EU act imposes at least equivalent requirements 1. A bank will still send you third-party security requirements that look familiar, but the instrument is DORA. Do not answer a DORA questionnaire with a NIS2 answer.

What the duty becomes on paper is set out with unusual precision, for digital infrastructure and digital providers, in Commission Implementing Regulation (EU) 2024/2690. Point 5.1.4 of its Annex requires contracts with suppliers to specify, where appropriate 2:

• cybersecurity requirements for the supplier
• awareness, skills, training and where appropriate certification requirements for the supplier's employees
• background verification of the supplier's employees
• an obligation to notify the customer of incidents that present a risk to their systems, without undue delay
• a right to audit, or to receive audit reports
• an obligation to handle vulnerabilities that present a risk to the customer's systems
• requirements on subcontracting, including cybersecurity requirements for subcontractors
• obligations at termination, such as retrieval and disposal of information

If your customer is a hospital rather than a cloud provider, that regulation does not govern them directly, but it is the only binding EU-level specification of what supply chain security means, and it is what the questionnaires and the redlines are converging on 2.

Notice how much of it is ongoing behaviour rather than a document you can send. A SOC 2 report is genuinely responsive to the audit-rights point and evidences controls behind several others, but it cannot discharge the rest: notifying incidents, handling vulnerabilities, holding subcontractors to the same terms and returning data at exit are continuing obligations, not control assertions. A point-in-time report says what was true during an observation window. Those four say what you will do next time.

Why does this keep coming back after the deal closes?

Because the duty was never a one-time procurement gate. Point 5.1.6 of the same Annex requires entities to "monitor, evaluate and, where necessary, act upon changes in the cybersecurity practices of suppliers and service providers", at planned intervals and when significant changes or incidents occur 2. ENISA, the EU's cybersecurity agency, puts numbers on that in its implementation guidance: review the supply chain policy at least annually, and keep a process that monitors suppliers over the life of the relationship 9.

So the answers you gave during the deal have a shelf life, and the thing that expires them is your own roadmap. You add a sub-processor. You move a workload to a new region. You ship a feature that reads a category of customer data the security addendum never contemplated. None of those used to be compliance events. Each one now potentially contradicts a document your customer is relying on for their own NIS2 file, and none of them generates a notification to anybody.

That is the failure I expect to see most, and it is not a team that ignored NIS2. It is a team that answered the questionnaire honestly in March and shipped for five months.

What are we doing about this at Lawcel?

Lawcel is software that watches a company's product changes and flags the ones that contradict the legal documents the company has published. We sell it to companies in Europe, so we are on the supplier side of this ourselves, and two records we keep for ourselves address the drift rather than the paperwork.

The first is a structured record of the promises we have made that carry a deadline: breach notification windows, sub-processor change notice, deletion and return timelines, each with its trigger, its timing quoted verbatim from the source document, and who it is owed to. That is exactly the shape of the incident-notification clause in point 5.1.4(d): a duty that lives in a contract, owed to a named counterparty, on a clock.

The second is the loop the product is built around: every pull request in our own repository is analysed against our own published documents, and when a change contradicts something we have published, it opens a case naming the document to fix. We did not build that for NIS2, but supply chain security is the same problem wearing different clothes: a set of claims about your product that has to stay true while the product changes underneath it.

What would I do about this now?

If you sell to European enterprises and have been treating NIS2 as somebody else's deadline, three things, in this order.

Work out whether you are in scope, properly, and write the answer down. Listed type plus size, with the linked-enterprise question answered rather than assumed, because you will be asked again after the next funding round. If you land in scope, the reporting duties are yours directly, and Article 20 requires your management body to approve the risk-management measures, oversee them, and accept that it "can be held liable" for infringements, in whatever form your national transposition gives that liability 1.

Read point 5.1.4 as a contract checklist and find out which of the eight you can already meet. Not which you can claim: which you can evidence. The audit right and the vulnerability-handling obligation are usually the two that need something real behind them, and incident notification to customers is the one most often promised in a sentence nobody has ever executed.

Then decide who finds out when the answers stop being true. Legal wrote the addendum, engineering changed the system, sales made the assertion, and nothing in a normal stack connects the three. Whatever you use, the requirement is that a change to the product surfaces against the commitments already made, rather than being discovered by a customer who kept better notes than you did.

The transposition delay bought you time with regulators in four countries. It bought you nothing at all with the customer whose addendum is sitting in your inbox, and your customers were always the ones who were going to ask.