NIS2 Supply Chain Security: Building a Supplier Register With No Template

NIS2 asks you to secure your supply chain in a single sub-clause and then hands you nothing to fill in. Where DORA prescribes a machine-validated register down to the field, Article 21(2)(d) gives essential and important entities one sentence about "the relationships between each entity and its direct suppliers or service providers", and leaves the format, depth, and evidence entirely to you. That freedom is the trap: with no template to pass or fail, teams produce a supplier list that satisfies nobody when the competent authority asks to see the risk management behind it.

The deliverable NIS2 actually wants is a supplier register you can defend: who your direct suppliers are, which ones matter, what you require of them, and how you know they are meeting it. This is how to build that without a form to hide behind.

What Article 21(2)(d) actually requires

Article 21 sets a baseline of risk-management measures; point (d) is supply chain security, "including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers." Two words carry most of the weight:

• Direct. The obligation is scoped to your direct suppliers and service providers, not the entire nth-tier chain. You are accountable for the vendors you contract with and for understanding the risk they bring, including what sits behind them, but NIS2 does not ask you to audit your supplier's supplier's supplier. Scope discipline here is the difference between a workable programme and an infinite one.
• Relationships. The unit of risk is the relationship, not the company. The same vendor can be low-risk for one service and business-critical for another; you assess the relationship you actually have.

Article 21(3) sharpens it: when assessing which measures are appropriate, entities must take into account the vulnerabilities specific to each direct supplier, the overall quality of the products and cybersecurity practices of their suppliers (including their secure-development procedures), and the results of the Article 22 Union-level coordinated security risk assessments of critical supply chains. That last point matters: the 5G toolbox was the template, and sector-wide assessments feed directly into what you are expected to have considered.

The supplier register NIS2 implies

Reverse-engineer the register from what Article 21(2)(d) and 21(3) make you prove. At minimum, each direct-supplier relationship needs:

Field	Why it exists	What "done" looks like
Supplier + service	The relationship is the unit of risk	One row per service, not per company
Criticality tier	21(3) proportionality; drives everything else	Tiered by impact if the supplier fails or is breached
Data / systems accessed	Defines the blast radius	What the supplier can touch, at what classification
Security requirements	21(2)(d) contractual expectations	Requirements set proportionate to the tier
Assurance held	21(3) "quality of cybersecurity practices"	ISO 27001, SOC 2, questionnaire result, on file and dated
Incident-notification flow-down	Your 24h/72h clock depends on theirs	Contractual notification obligation and route
Monitoring + review date	21(2)(d) is ongoing, not one-off	A cadence tied to tier, with a last-reviewed date

Notice what this is not: it is not a procurement spend list, and it is not your full asset inventory. It is the subset of relationships where a supplier's security posture becomes your risk.

Implementation: tier first, then everything follows

The single decision that makes the programme proportionate is criticality tiering, and it is the one most often skipped. Tier every direct supplier by the impact of that supplier being breached or unavailable, not by contract value. A €5k/year identity provider outranks a €500k/year facilities contractor every time.

Once tiers exist, the rest is mechanical:

1. Build the inventory from more than procurement. Procurement and accounts payable give you paid suppliers, but they miss the free SaaS and OAuth-connected apps in daily use. Enumerate the enterprise applications in Entra ID (consented and federated apps) and reconcile against the register, anything in active use that is not listed is either an omission or shadow IT, and both are yours.
2. Set requirements per tier (21(2)(d)). Bake security obligations into contracts proportionate to the tier: security standards to meet, incident-notification timeframes, right to audit or evidence, sub-supplier disclosure, and secure-development expectations for product suppliers (21(3) names these explicitly).
3. Collect assurance, don't assume it (21(3)). For Tier 1–2, hold a current ISO 27001 certificate, SOC 2 report, or completed security questionnaire, on file and dated. "They're a big vendor" is not an assessment.
4. Flow down the incident clock. NIS2's 24-hour early warning and 72-hour notification start when you become aware, which for a supplier-side incident depends on them telling you. If a Tier 1 supplier has no contractual notification duty, your reporting timeline is already broken.
5. Monitor on a cadence. Re-review Tier 1 suppliers at least annually and on trigger events (their breach, a merger, a service change, an Article 22 sector assessment). Record the review date; an un-reviewed critical supplier is the finding.

A note for entities coming from the EBA outsourcing register

Banks and financial firms spent years maintaining an outsourcing register under EBA/GL/2019/02. NIS2 generalises that instinct to every essential and important entity, but with two differences worth internalising: it covers all direct suppliers and service providers (not only outsourcing), and it prescribes no format. If you are a financial entity, you have already moved past both, DORA now governs your ICT third-party risk with a stricter, machine-validated register, and it takes precedence over the equivalent NIS2 provisions. For everyone else, the EBA register is a useful mental model of the discipline, not a scope boundary.

Common mistakes

1. A flat supplier list with no criticality tiering, so every control is applied uniformly or not at all.
2. Scoping to "all suppliers" and drowning, instead of to direct suppliers whose posture is your risk.
3. Security clauses in Tier 1 contracts but no evidence anyone ever checked the supplier met them.
4. No incident-notification flow-down, quietly breaking the 24h/72h reporting obligation.
5. Register built once from procurement data and never reconciled against what is actually in use.
6. Ignoring Article 22 coordinated risk assessments for your sector's critical suppliers.

What the competent authority looks for

Supervision under NIS2 is asymmetric: essential entities face proactive supervision (audits, inspections), important entities face reactive supervision (triggered by evidence of non-compliance). Either way the examiner is testing whether the measure is real, in a predictable order:

1. Does a supplier register exist, and does it distinguish critical relationships? An untiered list reads as a control that was documented but never operated.
2. For critical suppliers, do the contractual security requirements exist, and can you show the assurance behind them?
3. Is there incident-notification flow-down consistent with your own reporting obligations?
4. Is the register maintained, with review dates and trigger-driven updates?
5. Does the management body (Article 20) demonstrably oversee this? NIS2 makes senior management approve and monitor the measures and holds them personally liable, so "the board has visibility" needs to be evidenced, not asserted.

Evidence and documentation to keep

• The supplier register itself, with criticality tiers and last-reviewed dates.
• The tiering methodology, so a second assessor reaches the same tiers.
• Contractual security clauses for critical suppliers, with the incident-notification terms.
• Assurance artefacts (ISO/SOC 2/questionnaire results) held per critical supplier.
• Monitoring and review records, plus evidence of management-body oversight.

The same discipline across frameworks

NIS2's supplier register is one posture of a pattern that runs through every major framework: know your third parties, tier them, put requirements in contracts, assess, monitor, and exit cleanly. Build the register once and it maps across all five. Mappings are approximate and directional.

Framework	Control	Posture
DORA	Art 28(3) + ITS (EU) 2024/2956	Prescriptive, machine-validated register (financial entities)
NIS2 (this article)	Art 21(2)(d)	Outcome-based directive; direct suppliers; no prescribed format
ISO/IEC 27001:2022	A.5.19–A.5.23	Certifiable; justified in the Statement of Applicability
NIST CSF 2.0	GV.SC	Outcome-based; profiles and tiers
CIS Controls v8.1	Control 15	Prescriptive safeguards, IG1→IG3

Key takeaways

• NIS2 gives no template, so the register is judged on whether it drives decisions. Every field should be one you act on.
• Scope to direct suppliers and to the relationship, not to every company in the chain.
• Tier by breach impact before anything else; proportionality is the whole game.
• Flow the incident-notification clock down to critical suppliers, or your 24h/72h obligation is already broken.
• Evidence management-body oversight (Article 20), which is a personal-liability obligation, not a formality.

References and further reading

• Directive (EU) 2022/2555 (NIS2), in particular Articles 20, 21, and 22.
• ENISA technical implementation guidance on the Article 21 measures; validate against your national transposition, which sets the binding detail.
• Your national competent authority's guidance, the transposing law, not the directive, is what you are supervised against.

Frequently Asked Questions

How deep into the supply chain does NIS2 go?

Article 21(2)(d) scopes the obligation to your direct suppliers and service providers. You must understand the risk they bring, including relevant sub-supplier and product-quality factors under Article 21(3), but you are not required to audit the entire nth-tier chain. Focus effort on direct relationships tiered by criticality.

Is there an official NIS2 supplier register template?

No. Unlike DORA, NIS2 prescribes no format for supply chain security. The competent authority assesses whether your supplier risk management is real and proportionate, not whether you completed a specific form, so the register is judged on the decisions it drives rather than its layout.

Do NIS2 and DORA both apply to us?

For financial entities, DORA is lex specialis and takes precedence for ICT risk, ICT third-party risk, and incident matters, so you apply DORA's Register of Information rather than the equivalent NIS2 supply-chain provisions for the same subject. Non-financial essential and important entities follow NIS2 Article 21(2)(d).

Why does supplier management affect our incident reporting?

NIS2's 24-hour early warning and 72-hour notification clocks start when you become aware of a significant incident. For a supplier-side incident, awareness depends on the supplier telling you, so critical-supplier contracts need an incident-notification obligation with a timeframe. Without it, a supplier breach can blow your reporting deadline before you even know.

---