NIS2 Supply Chain: Vetting Your Service Providers

Why the supply chain is the blind spot of the NIS2 debate

NIS2 coverage in 2026 revolves almost entirely around two points: registering with the BSI and the staggered reporting deadlines. Both matter, and both are well documented — including in our guide to NIS2 incident reporting for website operators. But Article 21 lists ten minimum measures, and supply chain security is one of them. It is the measure that shows up least often in projects, even though it describes the largest attack surface a website operator has.

The numbers support this. For its Threat Landscape 2025, ENISA analysed 4,875 incidents between 1 July 2024 and 30 June 2025 (ENISA Threat Landscape 2025). Supply chain risks account for 10.6 per cent of threat categories — attackers are actively leveraging the indirect path through third-party providers and dependencies (ENISA Threat Landscape 2025). For comparison: web threats sit at 27.3 per cent, mobile threats at 42.4 per cent (ENISA Threat Landscape 2025). As an initial access vector, phishing dominates at 60 per cent, followed by vulnerability exploitation at 21.3 per cent (ENISA Threat Landscape 2025) — both routes that can just as easily start at a provider as in your own house.

The economic frame is measurable too. Bitkom puts the total damage to the German economy from theft, espionage and sabotage at 289.2 billion euros, up roughly 8 per cent year on year (Bitkom, Wirtschaftsschutz 2025). The share attributable to cyber attacks rose from 67 to 70 per cent, equivalent to 202.4 billion euros (Bitkom, Wirtschaftsschutz 2025). 87 per cent of surveyed companies report incidents at all, and 34 per cent were hit by ransomware — up from 12 per cent in 2022 (Bitkom, Wirtschaftsschutz 2025).

What Article 21(2)(d) actually requires

The directive text is short. Article 21(2)(d) of Directive (EU) 2022/2555 requires measures covering supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers. The German BSIG adopts the wording almost verbatim in Section 30(2) no. 4 (BSIG as in force since 6 December 2025). Section 30(1) BSIG requires appropriate, proportionate and effective technical and organisational measures — proportionality is written into the statute, not merely a consolation for small operators (BSIG as in force since 6 December 2025).

It only gets concrete one level down. Implementing Regulation (EU) 2024/2690 of 17 October 2024, published on 18 October 2024, translates the ten measures from Article 21 into technical and methodological requirements. Its annex is divided into 13 thematic areas; number 5 is supply chain security (Implementing Regulation (EU) 2024/2690). Important for scoping: the regulation is directly binding only for certain digital services — DNS service providers, TLD name registries, cloud computing and data centre service providers, content delivery network operators, managed service and managed security service providers, online marketplaces, search engines, social networks and trust service providers (Implementing Regulation (EU) 2024/2690).

For all other sectors the regulation does not formally apply — but in practice it is the only available yardstick for what supervisory authorities consider appropriate supply chain measures. Working to it tends to land closer to the expectation than inventing your own system (project experience). ENISA published its Technical Implementation Guidance on Cybersecurity Risk-Management Measures, version 1.0, on 26 June 2025: a non-binding document mirroring the structure of the regulation's annex, offering implementation guidance and examples of evidence that can be shown to an auditor for each requirement (ENISA Technical Implementation Guidance 2025).

• 5.1.1 — supply chain security policy: the entity establishes a policy governing relations with direct suppliers and service providers, and communicates its own role in the supply chain to them (ENISA Technical Implementation Guidance 2025).
• 5.1.2 — selection criteria: the supplier's cybersecurity practices including secure development procedures, their ability to meet your specifications, the quality and resilience of products, and the ability to diversify sources of supply and limit vendor lock-in (Implementing Regulation (EU) 2024/2690).
• 5.1.4 — contract content: eight points, from security requirements to obligations on termination — the core of this article (Implementing Regulation (EU) 2024/2690).
• 5.1.6 and 5.1.7 — ongoing monitoring: reviewing the policy at planned intervals and on significant change, monitoring SLA reports, reviewing incidents at suppliers, unscheduled reviews (Implementing Regulation (EU) 2024/2690).
• 5.2 — directory of suppliers: an up-to-date registry with contact points per supplier and a list of the ICT products, services and processes they provide (Implementing Regulation (EU) 2024/2690).

Scope depends on sector and thresholds, not on gut feeling

Before anyone builds a registry, settle the obvious question: does NIS2 apply at all? The BSI expects around 29,500 companies and federal administration bodies to fall under the new obligations (BSI 2026). Previously, roughly 4,500 organisations were regulated under the old BSI Act (BSI 2026). Eighteen sectors are covered — from energy through transport and health to digital infrastructure. What matters is the combination of sector and size threshold under Section 28 BSIG, not self-perception.

The third row is the point this article takes seriously. Not every company is an essential or important entity — this is not a panic zone. But anyone supplying an entity that is in scope receives the requirements passed down through the contract. That is precisely the mechanism Article 21(2)(d) sets in motion: the regulated entity must bind its direct suppliers contractually, so notification duties, audit rights and security requirements travel down the chain. For agencies, hosts and managed service providers, NIS2 is therefore relevant even when they sit far below any threshold themselves (project experience).

The registration picture shows how slow the start has been. The statutory deadline under Section 33 BSIG expired on 6 March 2026. By the end of May 2026, only around 18,500 of the roughly 29,500 expected entities had registered (BSI, as at end of May 2026). The BSI subsequently announced it would tolerate late registrations until 31 July 2026 — legally a matter of enforcement forbearance, not a change to the statutory deadline (BSI 2026). Failure to register is a standalone administrative offence under Section 65 BSIG carrying a range of up to EUR 500,000 (BSIG as in force since 6 December 2025).

Step 1: the service provider inventory for website operators

Number 5.2 of the annex is the most concrete requirement in the whole section. The entity maintains an up-to-date registry of its direct suppliers and service providers containing at least contact points per supplier and a list of the ICT products, services and processes they provide (Implementing Regulation (EU) 2024/2690). ENISA adds a tip to also record the contract start and end dates and the region per supplier, and to review the registry at least annually or when significant changes occur (ENISA Technical Implementation Guidance 2025).

For a website this list is longer than most people expect. It consists not only of the contract partners who appear in accounting, but of everything that participates at runtime. The rule of thumb from practice: anything with its own domain in the network waterfall of your home page, or anything without whose availability the site stops working, belongs in the review (project experience).

One practical side benefit: deriving the registry from the site's actual network traffic rather than from the contract folder regularly surfaces services nobody remembered — a widget from an old campaign, a tracking pixel from a former provider, a font served from a foreign domain (project experience). These finds are unremarkable to a supervisor, but relevant to your own attack surface.

Step 2: risk-based classification instead of equal treatment

A registry without classification is a list. ENISA recommends classifying direct suppliers and names as possible characteristics the sensitivity of the assets purchased, the volume, availability requirements, applicable regulations, and inherent and mitigated risk (ENISA Technical Implementation Guidance 2025). It suggests critical, strategic and routine as example categories and recommends reviewing the classification annually or when significant changes occur (ENISA Technical Implementation Guidance 2025).

For website operators this comes down to two questions: what data does the service see? and what happens if it fails? The combination gives you the depth of review — and therefore how much evidence effort is justified.

The classification is not an end in itself. ENISA explicitly frames it as an evidence example that the entity should be able to show it assesses risks per supplier category and tailors measures accordingly — critical suppliers receive more attention and customised policies (ENISA Technical Implementation Guidance 2025). Treating every provider identically produces either too much paper or too little substance.

Step 3: the eight contract points the regulation names

Number 5.1.4 of the annex is the section you can print and put next to the draft contract. Entities shall ensure that their contracts with suppliers and service providers specify — where appropriate through service level agreements — the following (Implementing Regulation (EU) 2024/2690):

1. Cybersecurity requirements for the supplier, including requirements on security in the acquisition of ICT services or products set out in number 6.1 of the annex.
2. Requirements on awareness, skills and training and, where appropriate, certifications required from the supplier's employees.
3. Requirements on verification of the background of the supplier's employees.
4. An obligation on the supplier to notify the entity without undue delay of incidents that present a risk to the security of its network and information systems.
5. The right to audit or to receive audit reports.
6. An obligation to handle vulnerabilities that present a risk to the entity's network and information systems.
7. Requirements on subcontracting and, where subcontracting is allowed, cybersecurity requirements for subcontractors in line with point 1.
8. Obligations at termination of the contract, such as retrieval and disposal of the information the supplier obtained in the exercise of its tasks.

Point 4 is the link to your own reporting process — and the point where most standard contracts fail. Without undue delay is not a number. If you are subject to the 24-hour early warning under Article 23 of the directive, you need a notification deadline from your critical supplier that falls before it — otherwise your own deadline is arithmetically out of reach. ENISA names additional contract elements including contacts and reporting lines, the obligation to fully cooperate with the competent authorities, and the supplier's obligation to provide assistance at no additional cost or at a cost determined in advance in the event of an incident caused by the contracted product or service (ENISA Technical Implementation Guidance 2025).

The entity remains fully accountable for the integrity, availability and confidentiality of services provided by suppliers. SLAs must be clearly defined, actively managed and aligned with the entity's business continuity, security and compliance obligations.

— ENISA, Technical Implementation Guidance on Cybersecurity Risk-Management Measures, version 1.0, June 2025

That clarification defuses the most common misunderstanding in contract talks: accountability does not travel with the work order to the provider. It stays with the entity. The contract is the instrument for obtaining information and rights — not for handing off responsibility. ENISA also points out that the requirements from number 5.1.4 should be included in all relevant new and renewed contracts (ENISA Technical Implementation Guidance 2025). Existing contracts therefore migrate into the system at the next renewal, not through a special campaign.

For smaller organisations facing large providers, where individual negotiation rarely works, ENISA names a realistic toolkit: collective bargaining with organisations of similar size, representation through an association you belong to, legal advice for reviewing the contract, providers that publicly publish their security and reliability commitments, providers with standard certifications, and contract templates or free checklists from associations or government sites (ENISA Technical Implementation Guidance 2025).

Step 4: continuous evidence instead of a one-off questionnaire

This is where common practice and the annex genuinely part ways. The usual approach is an onboarding questionnaire: the provider ticks boxes, signs, and the answer goes into a folder. But number 5.1.6 requires the entity to monitor, evaluate and where necessary act upon changes in suppliers' cybersecurity practices — at planned intervals and when significant changes to operations or risks, or significant incidents, occur (Implementing Regulation (EU) 2024/2690).

Number 5.1.7 is blunter still and requires four things: regularly monitoring reports on the implementation of service level agreements, reviewing incidents related to suppliers' ICT products and services, assessing the need for unscheduled reviews and documenting the findings comprehensibly, and analysing the risks presented by changes to the products and services obtained (Implementing Regulation (EU) 2024/2690). A questionnaire from eighteen months ago answers none of those four.

The way out is not more paper, but a different kind of evidence. A questionnaire asserts a state at a point in time. A dated technical measurement evidences a state over a period — which is exactly what number 5.1.7 asks about. ENISA lists as evidence examples, among others, records showing that service levels are monitored in accordance with the established SLA and a list of security incidents related to or caused by engagement with third parties (ENISA Technical Implementation Guidance 2025).

What can actually be evidenced technically

Honesty helps here: not everything Article 21 requires can be checked from the outside. Whether a host trains its staff, whether background checks happen, whether a contingency manual exists — that lives in certificates and reports, not in network traffic. Conversely, there is an area where external measurement is more precise than any self-declaration: everything the provider actually delivers.

The table shows the realistic division of labour: contracts and audit reports cover the organisational side, continuous measurement the technical one. Together they produce the evidence position number 5.1.7 describes. With only one of them you have half an answer. For assessing newly disclosed vulnerabilities in provider components, the European feeds are worth a look — see our article on the EUVD and CVE vulnerability feeds.

When the provider is the incident

Article 23 of Directive (EU) 2022/2555 stages the reporting of a significant incident in three steps: an early warning within 24 hours, a notification with an initial assessment within 72 hours, and a final report within one month (Directive (EU) 2022/2555). The clocks run from becoming aware of the incident. This is exactly where the supply chain meets the reporting process: if the outage sits with the host, the tampered script with the payment service and the compromised configuration with the DNS provider, then the start of your own deadline depends on when you find out.

In practical terms: the failure of a critical provider should be noticed in your own house before the provider's status page confirms it. That needs no grand architecture — a recurring check of the endpoints you depend on, with an alert into a channel someone reads. Combine that with DNS and domain monitoring and a change history of the site and you get the dated record for the final report alongside the alert.

Common mistakes in the supply chain registry

A few patterns repeat across projects with website operators (project experience). All of them are easy to avoid once you have seen them.

• Building the registry from accounting rather than network traffic. Free services without an invoice are then systematically missing — even though they load scripts into the page.
• Skipping subcontractors. Number 5.1.4(g) explicitly requires requirements on subcontracting (Implementing Regulation (EU) 2024/2690). A host that itself sits in someone else's data centre is the norm, not the exception.
• No contact point recorded. Number 5.2(a) names contact points as mandatory content (Implementing Regulation (EU) 2024/2690). During an incident, a generic support address is not enough.
• Treating all providers alike. Without classification the effort lands in the wrong places — ENISA explicitly recommends categorising by criticality (ENISA Technical Implementation Guidance 2025).
• No documented exit process. ENISA names the supplier exit process explicitly as an evidence example: how services, data and access rights transition when a relationship ends (ENISA Technical Implementation Guidance 2025).
• The registry is not touched again after creation. Number 5.2 requires an up-to-date directory; ENISA recommends a review at least annually or when significant changes occur (ENISA Technical Implementation Guidance 2025).

Setting the supply chain up as a standing process

Supply chain security is the Article 21 measure that resists being closed out as a project. Inventory, classification and contracts are one-off work with annual upkeep. The evidence duty from number 5.1.7, by contrast, is a standing state — and that is precisely why it fails when it hangs on a calendar entry rather than on a process that runs by itself.

The pragmatic cut for an entity with 50 or more employees looks like this in practice: the registry lives in one place, not in three spreadsheets. Critical providers have a contractual notification deadline expressed in hours. The technically measurable properties of those providers — reachability, TLS state, headers, script integrity, changes — are checked without manual effort and filed with a timestamp. And the Article 23 deadlines hang on a reminder, not on one person's memory (project experience).

Bundling exactly that is the purpose of the NIS2 readiness module: it maintains the supply chain registry, suggests third-party services detected during the scan as entries, documents your status across the ten measure areas and, for a logged incident, calculates the 24-hour, 72-hour and one-month deadlines with reminders. The technical records come from the security scan and ongoing monitoring; which modules are in which plan is shown on the pricing overview. It remains a preparation and documentation aid — the legal assessment belongs with qualified experts and your competent authority.