NIS2 Supply Chain: Obligations for IT Service Providers of Affected Companies

The NIS2 supply chain describes the security requirements that a NIS2-regulated company passes on to its IT and AI service providers through contracts. The legal basis is Article 21 of the NIS2 Directive (EU) 2022/2555: affected entities must assess and secure risks in their supply chain. It is precisely through this that service providers also become subject to obligations even though they themselves do not fall within the scope, but supply affected companies.

• Who is meant? Not primarily the agency itself, but its affected customer. The latter must secure its suppliers and passes the requirements on contractually.
• What is it based on? On Article 21 (risk management measures including supply chain security) as well as Article 20 and Recital 137 (responsibility of management bodies).
• What is the consequence? IT and AI service providers must deliver demonstrable technical and organisational measures, even without being a formal addressee of the law.

Why unregulated service providers are nevertheless affected

NIS2 regulates entities in defined sectors above certain size thresholds. A specialised AI or web agency generally does not fall within the scope itself. The leverage lies one level higher: Article 21 of the Directive explicitly requires essential and important entities to include the security of their supply chain and the relationships with their direct suppliers and service providers in their risk management.

In concrete terms, this means: the regulated company must assess the security practices of its suppliers, define requirements and ensure compliance. Since it can only fulfil this obligation if the suppliers play their part, it passes the requirements on contractually. In this way, an unregulated service provider is effectively bound to the same standards that apply to its customer. The obligation therefore does not arise directly from the law, but from the contract with the affected company.

This is strategically intensified by the liability logic of the Directive. Article 20 requires the management body to approve the risk management measures and oversee their implementation. Recital 137 makes clear that responsibility can also apply if the management body has failed to comply with its governance obligations, and indeed even without a successful attack. Responsibility is thus tied to the breach of duty, not to the damage incurred. In practice, this means: the management of affected companies has a hard self-interest in properly vetting their suppliers and binding them contractually, because the failure falls back on them.

The legal framework in DACH: same objective, different implementation

NIS2 is a directive and must be transposed nationally. Different frames of reference therefore apply to DACH supply chains, which a service provider should be aware of.

• Germany: The transposition act NIS2UmsuCG was passed by the Bundestag on 13 November 2025, promulgated on 5 December 2025 and entered into force on 6 December 2025 without a transition period. The scope expands from around 4,500 to about 29,500 affected companies. The BSI registration portal opened on 6 January 2026, and the deadline for initial registration expired on 6 March 2026. The supply chain obligations are anchored in the national version via the BSIG.
• Austria: The NISG 2026 was adopted by the National Council on 12 December 2025, promulgated on 23 December 2025 and enters into force nine months later on 1 October 2026. The scope covers around 4,000 companies in 18 sectors. Characteristic is the shift to self-classification and self-declaration instead of an administrative decision, as well as the establishment of a Federal Office for Cybersecurity within the Ministry of the Interior (BMI). Essential entities must anchor cybersecurity at management body level.
• Switzerland: Switzerland is not bound by NIS2, but operates a parallel regime under the revised Information Security Act. Operators of critical infrastructures have, since 1 April 2025, been required to report significant cyberattacks to the Federal Office for Cybersecurity (BACS) within 24 hours. Swiss subsidiaries often effectively fall within the NIS2 supply chain context through EU parent or customer relationships.

In the regulated financial sector, DORA (Regulation (EU) 2022/2554) provides a related, stricter model for third-party risk: Articles 28 to 30 govern ICT third-party risk with binding contractual requirements such as audit rights, exit clauses and sub-processor controls. On 18 November 2025, the European supervisory authorities designated 19 critical ICT third-party providers for the first time, including AWS, Microsoft Azure and Google Cloud. Anyone who supplies financial companies should be aware that the supply chain requirements there are contractually significantly stricter.

What an AI agency or IT service provider specifically has to deliver

The contractual passing on of obligations is not an abstract construct, but translates into verifiable evidence. The following table maps typical requirements from the Article 21 risk management catalogue to the respective responsible party and the specific measure.

For AI service providers, there is an additional particularity: their own supply chain often includes model and cloud providers as subcontractors. Anyone who integrates an LLM via an API thereby pushes a further sub-processor into the customer's chain. These sub-processors must be disclosed and assessed as part of the provider's own security concept, because the affected customer bears responsibility for the entire chain. In the DACH environment, the AIC4 (AI Cloud Service Compliance Criteria Catalogue) of the BSI is the relevant reference point when AI services are provided via a cloud service; it extends the BSI C5 with AI-specific controls.

Practical example: how the obligation manifests in a tender

A specific, illustrative scenario from the SME sector clarifies the mechanism. A DACH industrial company with around 1,200 employees qualifies as an important entity under NIS2. It awards the development of an AI-supported customer portal to an external agency.

Pseudocode of the chain of obligations:

```
Client (important entity)
-> fulfils Art. 21: risk management incl. supply chain
-> condition: every service provider must demonstrate a security baseline
IF agency.certified(ISO_27001) == false:
agency completes security questionnaire
agency accepts contractual clauses (TOM, MFA, IR, sub-processor list)
agency.disclose(sub-processors = [cloud provider, LLM provider])
-> client reviews, documents, monitors (Art. 20)
```

In practice, the agency therefore receives not only a specification for design and functionality, but also a security annex. It must present its information security management system, name its subcontractors, assure an incident response procedure and grant an audit right. An agency that can present this evidence immediately passes the pre-screening; an agency without a corresponding structure is often eliminated before the technical pitch. What is a pure compliance burden for the client thus becomes a selection criterion for suppliers.

Risk assessment of suppliers: the client's perspective

From the perspective of the affected company, supplier assessment is not a one-off act but an ongoing process. Typical components are the classification of a service provider's criticality (what access does it have to systems and data?), the review of the security evidence, the contractual anchoring of the requirements and regular monitoring. The more deeply a service provider is embedded in critical processes, the stricter the review. An AI service provider that productively accesses customer data or automates workflows is assessed more strictly than a supplier without data access.

For service providers, a clear consequence follows from this: anyone who creates transparency about their own security architecture and their own sub-processor chain reduces the customer's review burden and makes themselves more attractive as a partner. In the DACH BFSI environment, providers without recognised evidence such as ISO/IEC 27001, SOC 2, BSI C5 or AIC4 typically do not reach the final selection round.

For agencies and B2B decision-makers

For agencies and IT service providers in the DACH region, NIS2 shifts the competitive logic: demonstrable information security is no longer a hygiene factor but a prerequisite for access to contracts from affected companies. Anyone who builds an ISMS, documents their sub-processor chain and meets standards such as ISO/IEC 27001 or the AIC4 gains a robust advantage in tenders. For B2B decision-makers on the client side, the reverse applies: supplier vetting is part of fulfilling one's own obligations and should be built into procurement processes at an early stage. As an AI and digital agency in Vienna, Blck Alpaca helps to set up AI projects in such a way that they fit into the supply chain risk management of affected companies, from transparent sub-processor documentation to a clean interface for reporting obligations.

Note: This article serves as technical guidance and is not legal advice. The specific applicability, the precise interpretation of Article 21, contractual clauses, deadlines and possible sanctions must be clarified with qualified advisers in the relevant jurisdiction.