NIS 2 supply chain security: what to ask your suppliers, and what you cannot
NIS 2 makes supply chain security one of the ten minimum measures: Article 21(2)(d) of Directive (EU) 2022/2555 requires "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers". Article 21(3) says what to weigh: each direct supplier's specific vulnerabilities, the overall quality of its products and cybersecurity practices, including its secure development procedures, and the results of the EU coordinated risk assessments of Article 22(1). The obligation stays with your entity: you cannot make a supplier compliant, but you can know who your critical suppliers are, write security into the contract, ask for proportionate evidence and review it over time.
What Article 21(2)(d) requires
The text targets direct suppliers and service providers. Recital 85 explains why: incidents where attackers compromised an entity "by exploiting vulnerabilities affecting third-party products and services". It names providers of data storage and processing services, managed security service providers and software editors, and encourages entities "to incorporate cybersecurity risk-management measures into contractual arrangements" with their direct suppliers; risks from other levels of the chain "could" be considered. Recital 86 asks for "increased diligence" when selecting a managed security service provider, because such providers are themselves targets and are closely integrated into the entity's operations.
Article 22 adds an EU layer: the NIS Cooperation Group, with the Commission and ENISA, may carry out coordinated security risk assessments of specific critical ICT services, systems or products supply chains, taking into account technical and, where relevant, non-technical risk factors. Recital 90 cites the assessment carried out for 5G networks as the model. Where such an assessment exists for a product you use, Article 21(3) requires you to take its results into account.
Inventory and rate your suppliers
Start with a register of suppliers and service providers that have access to your information systems or that run a service you depend on: hosting, cloud, managed IT, software publishers, maintenance contractors with remote access, payment and telecom providers. For each, record the service, the data and systems concerned, the type of access, the contract reference and end date, the owner on your side, and a criticality rating. A simple grid is enough to rate them:
| Question | Raises criticality when |
|---|---|
| What happens to your essential services if the supplier stops for a week? | The service stops or degrades and there is no quick alternative |
| What access does the supplier have? | Administrator rights, remote access, or a connection into your network |
| What data does it process? | Personal data, health data, financial or confidential business data |
| How replaceable is it? | Proprietary technology, long migration, few alternatives (lock-in) |
| Is it a security provider itself? | Managed security services, incident response, audits (recital 86) |
Keep the rating short (high, medium, low) and write down the reason. The register is the backbone of the rest: clauses, evidence and reviews follow the criticality. If you already keep an IT contract register, add the security columns there; the article on the IT contract register template sets out the base columns and the notice-date formula.
Clauses to add to contracts
New contracts and renewals are the moment to act. For high-criticality suppliers, the clauses usually worth negotiating are:
- Incident notification: the supplier informs you of any security incident affecting your service or data within a stated time, short enough for your own 24-hour early warning under Article 23(4), and cooperates in the handling.
- Access: named accounts, strong authentication, logging of sessions, access limited to what is needed and removed at the end of the contract.
- Vulnerabilities and updates: the supplier tells you of vulnerabilities affecting what it delivers and applies security patches within agreed lead times.
- Subcontracting: disclosure of subcontractors that touch your data or systems, and your right to object to a change.
- Evidence and audit: the documents the supplier provides each year, and the conditions of an audit or an on-site check.
- Data location and return: where data are stored, and how data, configurations and logs are returned at the end.
- Exit: an exit plan and assistance period, so that leaving a supplier does not become a continuity incident.
The figures in these clauses (hours, days, months) are yours to set and negotiate: the directive gives none for suppliers. Market leverage is uneven; a standard cloud contract may not move, in which case the evidence route below matters more.
Evidence you can reasonably request
| Evidence | What it shows | What to check |
|---|---|---|
| Certificate of an information security management system, such as ISO/IEC 27001 | An audited management system | Scope (does it cover the service you buy?), issuer, validity date |
| Answers to a security questionnaire | Self-declared practices | Keep it proportionate to the criticality; ask for proof on the few answers that matter |
| Summary of a recent penetration test or audit | That testing happens and findings are tracked | Date, scope, status of the critical findings |
| Vulnerability disclosure policy and security contact | That flaws can be reported and handled | A working address, a stated process |
| Continuity and restore test results | That the service can be recovered | Date of the last test, recovery times achieved |
What you generally cannot obtain: other customers' information, unrestricted access to the supplier's systems, or a commitment that the supplier is "NIS 2 compliant" when it is not itself in scope. A supplier below the directive's size thresholds may have no NIS 2 obligation of its own; your requirements reach it through the contract, and should be sized to the risk it carries for you.
Monitoring over time
Set a review rhythm by criticality, for example yearly for high and at renewal for the others, and add event triggers: an incident at the supplier, a change of subcontractor or hosting location, a merger, a published vulnerability in a product you use. ENISA's report "Good Practices for Supply Chain Cybersecurity", published on 13 June 2023, reviews the practices observed among entities in scope and is a useful reference for the review questions. Record each review in the register with its date and decision, and report the high-criticality issues to management; supply chain is one of the domains the board reviews under the NIS 2 compliance checklist. How this measure sits among the ten others is explained in NIS 2 Article 21: the measures one by one.
FAQ
Do my suppliers have to be NIS 2 compliant?
Only if they are in scope themselves. Your obligation under Article 21(2)(d) and (3) is to manage the risks of your relationships with direct suppliers; a supplier outside the directive receives requirements through your contract.
Do I have to assess my suppliers' suppliers?
Article 21(2)(d) covers direct suppliers and service providers. Recital 85 says entities "could consider" risks from other levels; asking critical suppliers to disclose their key subcontractors is a proportionate way to do so.
Is a supplier's ISO/IEC 27001 certificate enough?
It is good evidence of a managed approach, provided its scope covers the service you buy and it is valid. It does not replace contract clauses on incident notification, access and exit.