NIS2 Supply Chain Security: What Article 21(2)(d) Requires

NIS2's supply chain obligation is a single sub-paragraph — Article 21(2)(d) — that turns into a programme of work. It is one of the most significant changes from NIS1, and it is the measure most SMEs underestimate, because the directive's brevity hides the operational scope.

This article unpacks what Article 21(2)(d) actually requires, how to build a defensible supply chain security programme without enterprise resources, and what it means if you are a supplier to in-scope entities rather than an in-scope entity yourself. For the broader Article 21 context, see NIS2 Article 21: All 10 Risk Management Measures Explained.

This is not legal advice. National transpositions and sector-specific guidance refine the supply chain obligation; verify against your jurisdiction's implementing law.

What Article 21(2)(d) actually requires

Article 21(2)(d) requires essential and important entities to implement, as part of their risk management measures:

Supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers.

Three words in that text carry the operational weight:

• "Direct" — the obligation reaches your direct suppliers and service providers. You are not required to audit your suppliers' suppliers (tier 2 and beyond), though you should understand concentration risks that propagate up the chain.
• "Suppliers or service providers" — not just IT vendors. Any supplier whose product or service touches your network and information systems, or whose failure would materially affect your operations, is in scope. SaaS platforms, managed service providers, payroll processors, and cloud hosts all qualify.
• "Security-related aspects of the relationship" — the obligation is about the relationship, not just the supplier's intrinsic security. It covers how you select, contract with, monitor, and exit suppliers.

Article 21(3) adds an important framing: when assessing supply chain security measures, entities must take into account the specific vulnerabilities of each direct supplier and service provider, and the overall quality of products and cybersecurity practices of their suppliers, including their secure development procedures. The Cooperation Group is also empowered to carry out coordinated security risk assessments of critical supply chains at EU level.

Why this measure catches SMEs out

The typical failure mode is straightforward: an SME inventories its "IT vendors" — the cloud host, the security tooling, maybe the MSP — produces a list of five to ten, and considers the supply chain measure addressed.

The reality is that a 100-person company commonly has 40 or more vendors with access to, or dependency on, its network and information systems. The HR SaaS platform holds employee personal data. The analytics tool runs JavaScript on your production website. The payroll processor has banking integration. The marketing automation platform has API access to your customer database. The contractor's laptop connects to your VPN.

Every one of those is a direct service provider under Article 21(2)(d). The supply chain measure is not satisfied until they are all identified and risk-assessed.

Building the supply chain security programme

A defensible programme has five components. None requires enterprise tooling — a spreadsheet and a disciplined process get an SME most of the way.

1. The supplier register

A single inventory of every direct supplier and service provider. Minimum fields:

• Supplier name and the service provided
• Type of access or dependency (data access, network access, operational dependency, none)
• Data categories the supplier processes, if any (personal data, confidential business data, none)
• Criticality tier (see below)
• Contract reference and renewal date
• Security certifications held (ISO 27001, SOC 2, etc.)
• Date of last review

The register is a living document. It must be updated when suppliers are added, changed, or removed — not reconstructed annually from memory.

2. Criticality tiering

You cannot apply equal scrutiny to 40 suppliers. Tier them. A workable three-tier model:

• Tier 1 — critical: failure would cause severe operational disruption, or the supplier has access to your most sensitive data or systems. Examples: cloud host, core SaaS platform, MSP. Full due diligence, annual review, contractual security clauses, exit plan.
• Tier 2 — important: failure would cause material but recoverable disruption, or the supplier has limited data access. Lighter due diligence, review on renewal, standard security clauses.
• Tier 3 — low: failure would cause minor or no operational impact, no meaningful data or system access. Register entry only, no active review.

Tiering is itself a risk-based decision and should be documented — it ties directly into the proportionality principle of Article 21(1).

3. Due diligence

For Tier 1 and selected Tier 2 suppliers, a security due-diligence process. For most SMEs this is a questionnaire, not an audit. A workable questionnaire covers 10–15 questions:

• Security certifications held and their current validity
• Data location and sub-processor disclosure
• Incident notification commitments and timelines
• Encryption practices for data at rest and in transit
• Access control and authentication practices
• Business continuity and backup arrangements
• Penetration testing cadence
• Right-to-audit provisions
• Compliance posture for NIS2, DORA, GDPR as applicable

The questionnaire output goes into the supplier register. Where a supplier holds a current ISO 27001 certificate or a recent SOC 2 Type II report, that evidence can substitute for much of the questionnaire — request the certificate or report rather than re-asking questions it already answers.

4. Contractual security clauses

Article 21(2)(d) is about the relationship, and contracts are the primary instrument of the relationship. New contracts with Tier 1 and Tier 2 suppliers should include security clauses covering, at minimum:

• A baseline security standard the supplier must maintain
• Incident notification obligations — the supplier must tell you about incidents affecting your data or services, within a defined window
• Sub-processor disclosure and approval rights
• Right-to-audit or right to receive audit evidence
• Data location and processing restrictions
• Exit and data return / deletion provisions on termination

For existing contracts, security clauses can be added by addendum at renewal. Industry association templates are usually sufficient for SMEs — bespoke legal drafting is rarely necessary for standard supplier relationships.

5. Ongoing monitoring and review

Due diligence at onboarding is a snapshot. The relationship needs periodic review:

• Tier 1 suppliers — annual review, re-checking certifications, incident history, any material change
• Tier 2 suppliers — review at contract renewal
• Trigger-based review — a supplier suffering a public breach, changing ownership, or materially changing its service triggers an out-of-cycle review

The review log is audit evidence. A competent authority assessing your supply chain measure will ask to see it.

The concentration risk question

Article 21(3) directs attention to the "overall quality" of supplier practices, and a specific dimension of supply chain risk is concentration. If five of your Tier 1 suppliers all run on the same cloud platform, the platform's outage is a single point of failure that your supplier register will not surface unless you look for it.

For SMEs, concentration risk analysis does not need to be sophisticated. A simple exercise: for each Tier 1 supplier, note the underlying infrastructure it depends on. If a pattern emerges — everything on one hyperscaler, everything in one region — that is a documented risk to carry in your risk register, even if you accept it.

This connects to DORA's more prescriptive treatment of concentration risk for financial entities. See DORA Third-Party Oversight for how DORA formalises what NIS2 leaves to judgement.

If you are a supplier, not an in-scope entity

A large share of SMEs are reading Article 21(2)(d) from the other side: they are not in NIS2 scope themselves, but their customers are — and those customers are now sending security questionnaires, demanding contractual clauses, and asking for attestation.

This is the commercial transmission of NIS2. The directive does not directly bind a supplier that is out of scope, but the supplier's in-scope customers are obligated to assess and manage it. The practical consequences for an out-of-scope supplier:

• Expect security questionnaires from in-scope customers, increasingly as a precondition for new contracts
• Expect contractual security clauses, including incident notification obligations, in renewal negotiations
• A current ISO 27001 certificate or SOC 2 report dramatically reduces friction — it answers most questionnaires pre-emptively
• Inability to satisfy customer due diligence increasingly translates into lost or unrenewed contracts

For an out-of-scope SME supplier, the rational response is to treat a baseline security posture as a commercial requirement, not a regulatory one. The contracts depend on it even though the directive does not bind you directly.

📨 Supply chain security is where NIS2 spreads beyond its formal scope. Risk Letters tracks how the obligation propagates through European supply chains. Free weekly briefing.

How the Implementing Regulation treats supply chain

Commission Implementing Regulation (EU) 2024/2690 — which applies to specific entity types including cloud providers, MSPs, and DNS providers — specifies supply chain security in more technical detail than the directive. For entity types in its scope, it sets out expectations on supplier security policies, the directory of suppliers, and the handling of supplier-related vulnerabilities. Even if your entity type is not in the Implementing Regulation's scope, its supply chain provisions are a useful benchmark for what "good" looks like.

Common pitfalls

Six failure modes:

1. The IT-vendor blind spot — inventorying technical vendors and missing SaaS sprawl. The HR platform and the payroll processor are direct service providers too.
2. The static register — building the supplier list once and never updating it. Within a year it no longer reflects reality.
3. Equal scrutiny for all suppliers — applying Tier 1 due diligence to all 40 vendors, exhausting the process, and abandoning it. Tier first.
4. No contractual teeth — assessing suppliers but never embedding incident notification or audit rights in contracts. The assessment without the contract is half the measure.
5. Onboarding-only diligence — checking the supplier once at signup and never again. The annual review is part of the obligation.
6. Ignoring concentration — a register of 40 suppliers that all run on the same platform looks diversified and is not.

Frequently asked questions

Does Article 21(2)(d) require me to audit my suppliers' suppliers? No. The obligation reaches direct suppliers and service providers. You should be aware of concentration risks that propagate up the chain, but you are not required to audit tier 2 and beyond.

Is a security questionnaire enough, or do I need to audit suppliers? For most SMEs, a questionnaire for Tier 1 and selected Tier 2 suppliers is sufficient. A current ISO 27001 certificate or SOC 2 report from the supplier can substitute for much of the questionnaire.

My supplier won't sign security clauses — what do I do? Document the gap as a risk in your risk register, assess whether the relationship can continue, and consider alternatives. A supplier's refusal to accept reasonable security clauses is itself a risk signal.

We're a small supplier to in-scope customers — are we obligated under NIS2? Not directly, if you are out of scope. But your in-scope customers are obligated to assess and manage you, which transmits the obligation commercially. A baseline security posture becomes a commercial necessity.

How often do I review suppliers? Tier 1 annually; Tier 2 at contract renewal; any supplier on a trigger event (breach, ownership change, material service change).

Does GDPR's processor due diligence overlap with NIS2 supply chain? Substantially. A supplier processing personal data is both a GDPR processor and a NIS2 direct service provider. A single due-diligence process can satisfy both — but the NIS2 obligation extends to suppliers that touch your systems even without processing personal data.

Does this apply to open-source software in our stack? Open-source components are part of secure development under Article 21(2)(e) rather than the supply chain measure under 21(2)(d), which concerns supplier relationships. Both matter; they are different measures.

The bottom line

Three takeaways:

1. One paragraph, a programme of work. Article 21(2)(d) is brief, but the operational scope is a register, tiering, due diligence, contracts, and ongoing review.
2. Tier before you scrutinise. Equal attention to 40 suppliers is the fastest route to an abandoned programme.
3. The obligation transmits commercially. Even out-of-scope suppliers feel NIS2 through their in-scope customers' due diligence.

For the SME-scaled version of the supply chain programme, including a lightweight questionnaire and tiering model, see Minimum Viable NIS2 Compliance for SMEs.

---

Sources & further reading

• Directive (EU) 2022/2555 — NIS2 — Article 21(2)(d) (supply chain security), Article 21(3) (supplier vulnerability assessment, Cooperation Group coordinated assessments)
• Commission Implementing Regulation (EU) 2024/2690 — supply chain security detail for specific entity types
• ENISA — Good Practices for Supply Chain Cybersecurity — and threat landscape for supply chain attacks
• NIS Cooperation Group — coordinated risk assessments of critical supply chains