NIS2 when your customers are in scope and you are not

Most software companies asking whether NIS2 applies to them are asking the wrong question first. The more useful one is whether it applies to their customers, because the directive was written to travel down a supply chain, and it does that regardless of whether the supplier at the far end has ever heard of it.

What it looks like from the supplier’s side is not a compliance project. It is a renewal that arrives with three new clauses in it, a questionnaire with a deadline, and a request for a named security contact.

What the directive is

Directive (EU) 2022/2555, usually shortened to NIS2, sets baseline cybersecurity risk-management and incident-reporting obligations on organisations operating in sectors the EU considers critical. It replaced the earlier network and information security directive and widened the sector list considerably. The European Commission’s overview is the shortest accurate summary of its aims.

Because it is a directive rather than a regulation, it does not bind anyone directly. Each member state writes it into national law, and the text that actually applies to a company is that national law. The transposition deadline was 17 October 2024 and member states did not all meet it, so the honest answer to "is it in force" is that it depends on where the entity is established, and that this needs checking rather than assuming.

Who the directive itself binds

Scope is decided by sector and by size, in that order. The annexes split the sectors into two lists, and the labels are not a severity ranking so much as a difference in supervision.

• Annex I covers sectors of high criticality: energy, transport, banking, financial market infrastructure, health, drinking water, waste water, digital infrastructure, ICT service management between businesses, public administration and space. Entities here are generally essential entities.
• Annex II covers other critical sectors: postal and courier services, waste management, chemicals, food, manufacturing of certain products, digital providers such as online marketplaces and search engines, and research. Entities here are generally important entities.
• Size generally decides whether an entity in one of those sectors is caught at all, with medium-sized enterprises and above in scope and smaller ones usually outside it. There are categories that are in scope irrespective of size, so the threshold is a rule with named exceptions rather than a hard floor.
• Essential entities face proactive supervision; important entities are supervised reactively, after an incident or an indication of non-compliance. The substantive obligations are largely the same.

A point worth noticing in that list: managed service providers and managed security service providers sit in Annex I. A consultancy that merely delivers projects is a different proposition from one that runs systems on a client’s behalf, and firms that have drifted from the first into the second sometimes discover they are directly in scope. Meanwhile most SaaS vendors are not, while their customers in health or transport very much are.

The article that reaches you anyway

The risk-management obligations include supply-chain security explicitly. In-scope entities must take account of vulnerabilities specific to each direct supplier and service provider, and of the overall quality of those suppliers’ products and cybersecurity practices, including their secure development procedures.

That sentence is the whole mechanism. An essential entity cannot satisfy it with a policy statement, because a supervisor will ask what it actually knows about its suppliers. So it asks its suppliers, in writing, and it writes the answers into the contract so that it can evidence them later.

The directive does not have to bind you for it to reach you. It binds your customer, and your customer holds the renewal.

There is a second mechanism that lands harder still. Management bodies of in-scope entities have to approve the risk-management measures and oversee their implementation, and they can be held personally accountable for failures. A named individual with liability attached asks noticeably sharper questions than a procurement template does.

What actually lands in the contract

• A notification window measured in hours, flowing down from the reporting timetable your customer is bound by. Their clock starts when they become aware; yours has to start earlier for theirs to be met.
• A right to information about your own suppliers and sub-processors, because their supply chain does not stop at you.
• Evidence of security testing on the product or service you provide, refreshed on a stated cadence rather than once at signature.
• Vulnerability handling commitments: a route for reporting an issue to you, a response time, and patch timelines tied to severity.
• A named security contact who is reachable outside office hours, and an obligation to keep that name current.
• Audit or assessment rights, sometimes exercised through a questionnaire and sometimes through a third party.
• Business continuity expectations, including how quickly you can restore service and when you last proved it.

None of these is exotic. All of them are much cheaper to arrange in advance than to negotiate under the time pressure of a renewal, and the incident clock is the one that catches teams out, because it is an operational commitment rather than a document.

The reporting timetable, and why it becomes yours

An in-scope entity must send an early warning to its national authority within 24 hours of becoming aware of a significant incident, a fuller notification within 72 hours, and a final report within a month. Those windows govern your customer, not you.

The practical consequence is that if the incident originates in your service, your customer needs to know inside the first few hours of your own awareness in order to file at all. That is why supplier contracts increasingly specify a shorter internal window than the regulatory one. Meeting it is a question of whether somebody on your side is authorised to make the call at the weekend, which is a rota rather than a policy.

Keeping it separate from the Cyber Resilience Act

These two get conflated constantly, and the difference is worth holding onto. NIS2 asks how an organisation manages risk and reports incidents. The Cyber Resilience Act asks what condition a product is in when it is placed on the market. One is about the operator, the other about the artefact, and a company can be caught by both, either or neither.

The overlap in practice is the evidence. Knowing what is in your software, being able to say quickly whether a published advisory affects it, and having a route for someone outside your company to report a problem will be asked for by both, in different words.

What is worth having before you are asked

1. 01A current inventory of what you ship and what is inside it, because every question about supply chain eventually reduces to that.
2. 02A recent, honest account of your security testing: what was covered, what was found, what was fixed. A dependency and supply-chain audit plus an application assessment covers the ground most of these clauses point at.
3. 03A published route for vulnerability reports and somebody who reads it, since an unmonitored inbox is treated as awareness whether or not anyone opened it.
4. 04A written incident path with a named decision-maker and a deputy, tested at least once so the first run is not the real one.
5. 05Your own supplier list, with what each one can access. You are somebody else’s supply chain, and they are yours.

And the boundary, stated plainly: none of this is certification. We are not a notified body, an assessment report is not a conformity statement, and no testing supplier can declare you compliant with a national implementation of a directive. What testing produces is engineering evidence that your customer’s risk assessment can rest on, which is what the clause is really asking for.