Article 21 of Directive (EU) 2022/2555 lists the cybersecurity risk-management measures essential and important entities must adopt. Of the ten categories listed, paragraph 2(d) is the one that has caused the most retroactive contract review across European boards in 2025: supply chain security.
The text is short. Article 21(2)(d) requires entities to put in place measures covering "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers". Recital 85 unpacks the intent: an entity may not outsource its way out of NIS2 obligations, and the supplier risk needs to be measured, contracted, and overseen.
The board-level question is not whether to act — it is what to put in supplier contracts so that "supply chain security" is provable to a regulator. Here are five clauses that the published guidance from European national competent authorities and ENISA's Good Practices for Supply Chain Cybersecurity converge on.
1. Security baseline alignment
The first clause requires the supplier to implement, at minimum, the cybersecurity measures listed in Article 21(2) of NIS2 — adapted to the supplier's role and the data it touches.
In practice, the contract should reference a defined baseline. Three options work:
- A direct reference to ISO/IEC 27001 with an Annex A statement of applicability that is shared with the entity.
- A reference to a national framework that is recognised in the supplier's jurisdiction (the BSI's IT-Grundschutz in Germany, the ANSSI's PSSI in France, the CCN-CERT Esquema Nacional de Seguridad in Spain).
- A direct enumeration of the relevant Article 21(2) categories (MFA on critical access, encryption, vulnerability management, incident response, etc.).
The clause should also include a change-management commitment: the supplier notifies the entity in writing if the baseline materially weakens during the contract.
2. Incident notification chain
The second clause tightens the supplier's incident notification obligation so it fits inside the entity's own 72-hour clock under Article 23.
The defensible threshold drawn from regulator guidance is:
- The supplier notifies the entity within 24 hours of becoming aware of any significant incident affecting the services it provides to the entity.
- The notification includes, at minimum, the same elements the entity itself owes its CSIRT at the early-warning stage: suspected unlawful or malicious cause, potential cross-border impact, and basic identifying information.
- The supplier provides updates at least every 24 hours while the incident is ongoing, and a final report within one month of resolution.
Less than 24 hours is preferable for cloud and managed-service suppliers — ENISA's guidance suggests a 6 to 12-hour window for those — but 24 hours is the floor that lets the entity meet its own NIS2 obligations.
3. Subprocessor transparency and change-of-control notification
Article 21(2)(d) covers direct suppliers, but most attacks on the supply chain pivot through a subcontractor of the supplier. The clause should:
- Require the supplier to disclose, on request, the list of critical subcontractors that touch the entity's systems or data, along with their security baseline.
- Require prior written consent before the supplier adds, replaces, or removes a critical subcontractor.
- Require notification within 30 days of any change of control of the supplier itself (acquisition, merger, ownership shift), with a right for the entity to terminate without penalty if the new owner is incompatible with the entity's risk register.
This is where the legal team and the security team need to coordinate. The notification windows are negotiable; the principle is not.
4. Right to audit and evidence of certification
Article 21 expects entities to verify, not just trust. The clause should give the entity the right to audit the supplier's security practices — directly or via accredited third parties — at least once a year, and ad hoc following any significant incident affecting the services.
For practical efficiency, the clause should accept standard audit reports as substitutes for direct on-site audits:
- A current ISO/IEC 27001 certificate, with the Annex A statement of applicability.
- A SOC 2 Type II report covering at least the Security and Availability trust criteria.
- A TISAX assessment for automotive supply chains.
- For cloud providers, a CSA STAR Level 2 attestation.
Direct audit rights are then exercised only when the standard reports do not cover the relevant scope, or when there has been a material incident. This protects the supplier's costs without weakening the entity's oversight.
5. Termination assistance, data return, and secure deletion
The final clause is what closes the loop when the relationship ends — willingly or not. It should require:
- Continuity assistance for an agreed period (typically 30 to 90 days post-termination) so the entity can migrate without service disruption.
- Data return in a documented, machine-readable format the entity can ingest, on a defined timeline.
- Secure deletion of all entity data from the supplier's systems and those of its subcontractors, certified in writing within 30 days of completion.
- A clear carve-out for backups that the supplier is legally required to retain, with explicit limits on access and an end-of-life schedule.
Without this clause, the entity carries a residual risk on data it cannot see, hosted by a counterparty no longer under contract — exactly the scenario regulators reference when they ask whether supply chain security was actually implemented or merely declared.
A NIS2-compliant supplier contract is not a longer contract. It is a more specific one — five precise clauses beat fifty loose pages of standard terms every time.
Who counts as a "critical" supplier?
The clauses above apply to critical suppliers. NIS2 itself does not define the term. The defensible test, drawn from the published guidance of European national competent authorities, has three components:
- The supplier processes, hosts, or transmits personal data, confidential business data, or operational data that, if compromised, would trigger the entity's own significant-incident threshold.
- The supplier delivers a service that, if interrupted for more than the entity's recovery time objective, would cause severe operational disruption.
- The supplier has privileged access (administrator, root, signing keys) to systems within the entity's NIS2 perimeter.
Any supplier matching any one of these tests is critical. The board does not need to debate the framework — it needs to confirm the list exists, is owned at executive level, and is reviewed at least annually.
What good looks like
Three signals show up consistently in regulator post-inspection notes:
- A dated supplier register that classifies critical vs. non-critical and records the contract version reference for each.
- Evidence of clause inclusion — the same five clauses, in substantive form, in every critical supplier contract executed since transposition.
- Evidence of clause exercise — at least one audit report, one incident notification correctly relayed within 24 hours, or one terminated supplier with documented data return per audit cycle.
None of this is exotic. It is what mature procurement teams already do on critical IT contracts. Article 21(2)(d) makes it a regulatory expectation rather than a best practice.
Sources
- Directive (EU) 2022/2555, Article 21(2)(d) (supply chain security).
- Directive (EU) 2022/2555, recital 85 (intent and scope of supply chain measures).
- Directive (EU) 2022/2555, Article 23 (incident reporting obligations) — the 72-hour clock that the supplier notification clause must fit inside.
- ENISA, Good Practices for Supply Chain Cybersecurity.
- NIS Cooperation Group, published guidance on supply chain risk management.
- National competent authority frameworks referenced as baselines: BSI IT-Grundschutz (DE), ANSSI PSSI (FR), CCN-CERT Esquema Nacional de Seguridad (ES), ACN guidance (IT), NCSC-IE guidance (IE).
