Use this guide to scope direct supplier risk, select proportionate controls, set contract terms, monitor changes, and retain evidence under NIS2 Article 21.
It separates the Directive's general duty from the detailed requirements that Regulation (EU) 2024/2690 places on specified digital entities.
NIS2 Article 21 requires essential and important entities to include in their appropriate and proportionate cybersecurity risk-management measures. Start with direct suppliers and service providers that can affect NIS2-relevant network and information systems, assess the supplier-specific factors in Article 21(3), apply controls proportionate to the relationship's risk, and retain the scope, assessment, treatment, contract, monitoring, and corrective-action evidence. Detailed policy, contracting, monitoring, and registry rules under Regulation (EU) 2024/2690 apply only to the digital-entity categories named in that Regulation.
1
Section 1
What NIS2 requires from a supply chain security program
Article 21(2)(d) makes , including security-related aspects of relationships with direct suppliers and service providers, one part of the required all-hazards cybersecurity risk-management measures. Article 21(1) requires those measures to be appropriate and proportionate to the risks, taking account of factors including exposure, entity size, incident likelihood and severity, societal and economic impact, state of the art, standards, and implementation cost.
When selecting supply chain measures, Article 21(3) requires the entity to consider vulnerabilities specific to each direct supplier and service provider, the overall quality of products, supplier and service-provider cybersecurity practices, and secure development procedures. The entity must also consider any applicable of a critical ICT supply chain.
Map direct suppliers and service providers whose products, services, access, maintenance, or operations can affect NIS2-relevant network and information systems.
Assess supplier-specific vulnerabilities, product quality, cybersecurity practices, secure development procedures, and the risk created by the relationship.
Connect supplier risk findings to risk treatment, contract clauses, monitoring, and management reporting.
Take corrective measures without undue delay if the entity finds that its Article 21 measures do not comply with the required baseline.
Use Member State implementing rules and competent-authority guidance for local supervisory expectations.
First determine whether Regulation 2024/2690 applies
Regulation (EU) 2024/2690 applies the detailed Article 21 requirements to DNS service providers, TLD name registries, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers, managed security service providers, online marketplaces, online search engines, social networking services platforms, and trust service providers. Other essential and important entities remain subject to Article 21 and applicable national law, but this regulation's Annex is not automatically binding on them.
A covered digital entity must establish, implement, and apply a policy. The policy must identify its role in the supply chain and communicate that role to direct suppliers and service providers. It must also set selection and contracting criteria covering cybersecurity practices and secure development, the supplier's ability to meet security specifications, product and service quality and resilience, embedded risk-management measures, and the ability to diversify supply and limit vendor lock-in where applicable.
Record whether the entity is one of the categories covered by Regulation 2024/2690 before treating its Annex as binding.
For a covered entity, approve a policy and apply its criteria to new supplier selection and procurement.
Classify direct suppliers and service providers by the ICT products, ICT services, or ICT processes they provide and the risk they create.
Take applicable Article 22 coordinated critical-supply-chain risk assessments into account when establishing the policy.
For entities covered by Regulation 2024/2690, point 5.1.4 requires contracts or service-level agreements to specify listed terms where appropriate, based on the supply chain policy and risk assessment. The list covers cybersecurity requirements; staff awareness, skills, training, and certifications where appropriate; background verification; incident notification without undue delay; audit rights or audit reports; vulnerability handling; subcontracting; and termination duties such as retrieving and disposing of information.
Translate each applicable term into an owner and operating process. Onboarding and access controls should implement the agreed permissions; incident and vulnerability processes should use the supplier notice route; service reviews should track agreed levels; and offboarding should remove access, transfer service and data, and complete the agreed retrieval or disposal steps. For entities outside the regulation's scope, use these clauses as a risk-based reference only when consistent with Article 21, national law, and the relationship.
Include cybersecurity requirements and service-level expectations for ICT products, ICT services, and ICT processes.
For covered digital entities, require suppliers and service providers to report without undue delay incidents that present a risk to the entity's network and information systems, and require them to handle vulnerabilities that present such a risk.
Set subcontracting requirements and flow relevant cybersecurity requirements to permitted subcontractors.
Define access, maintenance, continuity, data handling, termination, transition, retrieval, and disposal obligations where the risk assessment makes them appropriate.
Keep contract or SLA evidence mapped to the supplier risk tier and to the controls it supports.
Retain enough evidence to show what the entity decided and implemented: which relationships were assessed, what each supplier provides, the identified risks, the selected treatment, the applicable contract requirements, monitoring results, and corrective actions. ENISA's examples are guidance, not a closed list of mandatory documents.
For entities covered by Regulation 2024/2690, point 5.2 requires an up-to-date registry containing contact points for each direct supplier and service provider and a list of the ICT products, ICT services, and ICT processes each provides. ENISA also identifies useful evidence such as the policy, supplier evaluations, risk analyses, contracts or SLAs, supplier-related incident records, policy reviews, and exit documentation.
policy and approval or review record.
For a covered digital entity, the required registry of direct suppliers and service providers, with contact points and supplied ICT products, ICT services, or ICT processes.
Supplier classification, selection criteria, risk analysis results, and evaluation notes.
Signed contracts, SLAs, security addenda, vulnerability-reporting terms, incident-notification terms, audit rights, and exit provisions.
Monitoring records, supplier incident records, policy review evidence, and remediation tracking after significant supplier changes or incidents.
Do not give every vendor the same review. Article 21 measures must be proportionate to risk, so depth should follow the supplier's ability to affect relevant systems and services. A certificate or questionnaire can support the review, but it does not replace the Article 21(3) assessment of the specific relationship.
ENISA's guidance for Regulation 2024/2690 explains that a free and open source software community or project may fall outside the direct-supplier or service-provider relationship when no contract exists beyond a standard copyright licence. The entity still needs to manage risks from the software it uses. Where a direct supplier integrates open source components, risk, maintenance, dependency, and vulnerability evidence can form part of that supplier review.
Do not assume a supplier questionnaire satisfies Article 21 unless it leads to risk treatment, contract terms, monitoring, and evidence.
Do not apply direct-supplier clauses to open source communities without checking whether a supplier or service-provider relationship actually exists.
Do not ignore supplier access, maintenance connections, managed services, or cloud services when mapping supplier risk.
For covered digital entities, do not rely only on a planned review: point 5.1.6 also triggers review and action after significant changes to operations or risks, or significant supplier-related incidents.
Implementation checklist for NIS2 supply chain security
Use this sequence after confirming that the entity is essential or important under the applicable national implementation. Mark the Regulation 2024/2690 steps as mandatory only when the entity falls within one of that regulation's named categories.
Procurement, security, legal, business continuity, incident response, service owners, and the management body should work from the same supplier inventory and risk decisions.
Does NIS2 require a program?
Article 21(2)(d) requires essential and important entities to include in their cybersecurity risk-management measures, including security-related aspects of relationships with direct suppliers and service providers. The Directive does not prescribe one document called a "program"; the entity must implement appropriate and proportionate measures under national law. Regulation 2024/2690 separately requires its covered digital entities to establish, implement, and apply a supply chain security policy.
What should a NIS2 supplier review cover?
Article 21(3) requires consideration of vulnerabilities specific to each direct supplier and service provider, overall product quality, supplier and service-provider cybersecurity practices, secure development procedures, and applicable Article 22 coordinated supply-chain risk assessments. For entities covered by Regulation 2024/2690, the binding Annex adds policy, selection, contracting, monitoring, and registry requirements; ENISA supplies non-binding implementation and evidence examples.
Does Regulation 2024/2690 apply to every NIS2 entity?
No. Its Article 21 technical and methodological requirements apply to DNS service providers, TLD name registries, cloud computing and data centre providers, content delivery networks, managed and managed security service providers, online marketplaces, online search engines, social networking services platforms, and trust service providers. Other essential and important entities remain subject to NIS2 Article 21 and applicable national implementation.
Scope: identify direct suppliers and service providers that can affect NIS2-relevant network and information systems, and record what they provide and how they connect.
Assess: consider supplier-specific vulnerabilities, product quality, cybersecurity practices, secure development, applicable Article 22 results, and the likelihood and impact of supplier failure or compromise.
Treat: select proportionate technical, operational, organisational, and contractual controls, with an owner and target evidence for each material risk.
Contract: for Regulation 2024/2690 entities, apply point 5.1.4 terms where appropriate and record why any listed topic is not relevant.
Register: for Regulation 2024/2690 entities, keep the point 5.2 supplier registry current.
Monitor: track service levels, incidents, vulnerabilities, material supplier changes, and changes in risk; trigger an unscheduled review when the facts require one.
Correct and report: record mitigating or corrective measures and escalate material residual risk through the entity's governance process.
Build a NIS2 supply chain security workflow around Article 21
Sorena can help convert supplier inventories, contract clauses, risk reviews, and source citations into a reusable NIS2 supply chain security workflow.
Explains direct supplier/service-provider evidence, lifecycle monitoring, supplier categorisation, and considerations for free and open source software.
Sets binding technical and methodological supply-chain requirements for the digital-entity categories named in the regulation, including policy and supplier-selection criteria.
Requires covered entities to specify the listed contract or service-level terms where appropriate, based on the supply chain policy and risk assessment.