Supply chain security stops at your direct suppliers — and that is harder than it sounds

Read the boundary carefully

Supply chain obligations attract scope creep faster than any other part of NIS2. Programmes start mapping tier-two and tier-three dependencies, run out of budget, and deliver a partial map of everything instead of a complete assessment of what the directive actually names.

Direct suppliers and service providers. The people you have a contract with. Not their subcontractors, not the open-source projects three levels down in a dependency tree.

That is a relief for scoping and a problem for expectations, because the depth demanded within that boundary is set by article 21(3).

The quality-of-practices test

Three distinct things, each of which resists being answered by a form:

• Vulnerabilities specific to each supplier — which means per-supplier, not a policy applied uniformly.
• The overall quality of their products and cyber practices — a judgment about capability, not a checkbox.
• Their secure development procedures — how they build, not only how they operate.

A returned questionnaire evidences that you asked. It does not evidence that you took anything into account. The gap between those two is where most supplier programmes are weakest, and it is visible in minutes to anyone who looks at the follow-up.

What tiering is actually for

You cannot assess a thousand suppliers to that depth, and you are not expected to. Article 21(1) qualifies everything with "appropriate and proportionate". Tiering is how proportionality gets applied — but the tier must be driven by what a supplier could do to you, not by what you spend with them.

Spend is a convenient proxy and a poor one. The supplier that can hurt you most is often small: the managed service provider with domain administrator credentials, the specialist vendor whose software runs unattended on your OT network, the payroll processor holding all your employee data. None of them appears near the top of a procurement spend report.

Managed service providers are now on both sides

NIS2 added ICT service management to Annex I, naming managed service providers and managed security service providers. Your MSP is therefore likely in scope in its own right — and simultaneously the object of your article 21(2)(d) assessment.

That is useful. An MSP subject to NIS2 has to be able to answer your questions, because it faces the same obligations internally. Ask for the evidence rather than the assertion: their own risk assessment, their incident response arrangements, their approach to privileged access into customer environments.

Contracts are where this becomes real

An assessment that changes nothing is an expense, not a control. The output has to land in the contract: security requirements, an obligation to notify you of incidents affecting your services and on what timeline, audit or evidence rights, and consequences for non-performance.

The incident notification clause is the one to get right first. Your article 23 clock starts when you become aware — and if a supplier takes a week to tell you, you were aware late through no fault of your own and in breach regardless. Contractual notification timelines are what protect your own compliance.

And the part you do not control

Article 22 provides for coordinated Union-level security risk assessments of critical supply chains, carried out by the Cooperation Group with the Commission and ENISA. Article 21(3) requires you to take their results into account. In practice this means watching for those assessments and being able to show you responded when one touches a technology you depend on.