NIS2 Supply-Chain Security: Turning Article 21(2)(d) Into Supplier Assessments That Scale

A filing cabinet of security questionnaires nobody has reopened in eighteen months is not supply-chain security. Under NIS2 it is evidence that you do not have any.

NIS2 (Directive (EU) 2022/2555) makes supply-chain security an explicit, named obligation rather than a good-practice aspiration. Article 21(2)(d) requires in-scope entities to take measures covering “supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers.” That single clause is where most programmes either quietly work or quietly fail, and the failure mode is almost always the same: a one-off questionnaire sent at onboarding, filed, and never revisited. This is a reading of how to turn that clause into a supplier-assessment model that a supervisor, or an incident, can actually test.

What 21(2)(d) actually obliges — and what 21(3) adds

The measure itself is short. The teeth are in Article 21(3), which tells you how to choose the measure. When assessing supply-chain measures, entities 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.” Read those two provisions together and three things fall out.

First, the obligation is supplier-specific. “Vulnerabilities specific to each direct supplier” rules out a single flat questionnaire applied identically to everyone. Second, it reaches practices, not just posture — the supplier’s secure development procedures are named, so you are assessing how they build, not only what certificates they hold. Third, the scope is direct suppliers and service providers; NIS2 does not oblige you to audit your suppliers’ suppliers, though Article 22’s Union-level coordinated risk assessments of critical supply chains sit above all of this and can reshape what “critical” means for a whole sector. The point is that the directive is asking for a differentiated, evidenced, repeatable process. It is not asking for more paper.

If you have not yet mapped the ten measures in Article 21(2) to concrete controls, that is the prior step — we set it out in NIS2 Article 21 measures translated into controls. Supply chain is one line of ten, but it is the line that most often has no owner.

Segment before you assess

The scaling problem is real. A mid-sized entity can have several hundred direct suppliers. You cannot assess all of them to the same depth, and Article 21(3) does not ask you to — proportionality runs through the whole directive. So the first artefact is not a questionnaire. It is a segmentation of your supplier estate by criticality.

Rate each direct supplier on a small number of factors that actually predict blast radius: whether they touch or host your essential-service systems, whether they hold access credentials into your environment, whether they process sensitive or regulated data, and whether a failure on their side would interrupt the service that brought you into NIS2 scope in the first place. The supplier who runs your core payment or scheduling platform is not in the same tier as the firm that supplies office stationery, and treating them alike is how programmes drown. The dependencies that hurt are frequently the ones nobody consciously selected — the transitive ones, the defaults, the “it came with the platform” integrations — a pattern we have written about in the dependencies you didn’t choose. Segmentation is where those surface, or where they stay hidden.

Three tiers is usually enough: critical, important, and routine. What matters is not the number of tiers but that the tier drives everything downstream — assessment depth, evidence expected, reassessment frequency, and the contractual clauses you require.

Match assessment depth to the tier

Depth is where the one-off questionnaire has to be replaced by something proportionate and evidenced.

• Critical suppliers warrant evidenced assessment: an independent assurance report (a SOC 2 Type II or an ISO/IEC 27001 certificate with the Statement of Applicability, not a logo on a website), review of their secure development procedures, penetration-test summaries, and named right-to-audit and incident-notification clauses in the contract. This is the tier where Article 21(3)’s reference to secure development procedures bites hardest.
• Important suppliers warrant a structured questionnaire that is validated against at least some external evidence — a current certificate, a recent assessment report — rather than taken on the supplier’s word alone.
• Routine suppliers warrant a light self-attestation and a criticality re-check when the relationship changes. The governance cost of assessing them heavily is not justified by the risk they carry.

The discipline is asymmetric on purpose. Effort concentrates where a compromise would actually reach your essential service. Where you can, ask for machine-verifiable evidence rather than assertions — a signed software bill of materials tells you more than a tick-box, and it is a natural fit for critical software suppliers, as we cover in living SBOMs in the pipeline.

Continuous monitoring is the part everyone skips

A questionnaire captures a supplier at a moment. Supplier risk moves continuously. The gap between those two facts is where the real exposure lives, and it is the part of the model that most programmes never build.

Continuous monitoring does not mean a real-time feed for every vendor. For critical suppliers it means a defined cadence of reassessment, plus event triggers that force an out-of-cycle look: a breach disclosure at the supplier, a change of ownership, a material change in the service, or a relevant advisory. SolarWinds is the case study that keeps earning its place here — the compromise was upstream, trusted, and signed, and no onboarding questionnaire would have caught it; the lessons are in supply-chain risk lessons from SolarWinds. What would have helped was knowing which suppliers were critical, holding notification clauses that obliged disclosure, and having a process to act on it. That is monitoring, not paperwork.

What a supervisor, or an incident, will test

NIS2 gives supervisors real leverage: infringements of the Article 21 measures expose essential entities to administrative fines of up to EUR 10 000 000 or 2% of total worldwide annual turnover, whichever is higher, and important entities to up to EUR 7 000 000 or 1.4%. Beyond the number, management bodies carry direct accountability for approving and overseeing these measures. So the question a competent authority asks is not “do you have questionnaires.” It is closer to: show us your supplier segmentation and the criteria behind it; show us the assessment evidence for your critical suppliers; show us the last time you reassessed them and what triggered it; show us the contractual clauses that let you get that evidence.

If those four artefacts tell a coherent story, you have a defensible supply-chain security posture. If you have a shared drive of onboarding questionnaires and nothing since, you have documented the moment you stopped looking. (Exact obligations and deadlines land in the national transposing law — verify against your member state’s implementation, which in several states arrived after the 17 October 2024 deadline.)

The suppliers who will hurt you are the ones you assessed once, trusted permanently, and never watched again.

Sixteen Pillars is a technology governance consultancy based in Cyprus. Engagements run remote across the EU, UK, and Middle East, with on-site time where the engagement requires it.