NIS2 · Supply chain

NIS2 supply chain requirements: what your customers will now ask of you as a supplier

By Lucas Weber, CyberSec42 · Updated 28 Oct 2026

NIS2 requires in-scope organisations to manage the security of their supply chain, explicitly including their relationships with direct suppliers and service providers (Article 21(2)(d) NIS2; in Germany, Section 30(2), second sentence, no. 4 of the BSI Act, BSIG). The obligation sits with the customer, not the supplier. It still reaches you as a security questionnaire, a contract clause and a request for evidence, even if your own company is not covered by NIS2. Suppliers who keep an evidence pack, a lean security management system and a recent test report ready answer these requests much faster and do not start from scratch for every customer.

This article is a practical overview and does not constitute legal advice. Contract clauses and the binding interpretation of the law in your case belong with your legal counsel.

Why NIS2 reaches companies that are not in scope

NIS2 applies to essential and important entities. Germany transposed the directive through the NIS2 Implementation Act, which rewrote the BSI Act (BSIG); the new version has applied since 6 December 2025. Under Section 30(1) BSIG the duties rest with the entity itself. A 20-person software company supplying a specialist application to an energy utility therefore has no obligation of its own under the Act. It acquires obligations through the contract.

The reason is one of the ten minimum measures every in-scope entity has to implement:

One detail that many summaries miss: the statutory text of Section 30 BSIG does not reproduce Article 21(3) NIS2 word for word. The criteria are set out in the explanatory memorandum, and the Act is to be read in line with the directive. For you as a supplier this changes little in practice. Your customer has to assess your security practices and document that assessment, because Section 30(1), third sentence, BSIG requires entities to document their compliance. The memorandum expressly lists agreements, audit reports, certifications and assessments as possible documentation.

Who counts as a direct supplier

The term covers the entity's direct contractual partners: software vendors, SaaS providers, IT service providers, data centres, maintenance firms with remote access, and suppliers whose products or access touch the customer's network and information systems. The duty does not automatically extend to the end of the chain. Recital 85 does say, however, that entities could consider risks from other tiers of suppliers. That is why customers almost always ask which subcontractors you use yourself.

Special case: you are in scope yourself

Some service providers are listed in Annex 1 of the BSIG in their own right, for example providers of cloud computing services, data centre services, managed service providers and managed security service providers. Whether your company belongs there depends on entity type and size and needs its own assessment, described in our article NIS2: who is affected and what to do next. This article covers the more common case: you are not subject to NIS2, but your customers are.

What in-scope customers typically ask for

A very concrete template for supplier contracts is Implementing Regulation (EU) 2024/2690. It applies directly only to certain digital providers, such as cloud services, data centres, managed service providers, online marketplaces and trust service providers. Because it spells out the supply chain duty of Article 21(2)(d) NIS2 point by point, it also works as a reference for other entities. Under point 5.1.4 of its Annex, contracts with suppliers should, where appropriate, specify the following:

Then there is the selection side. Under point 5.1.2, entities set criteria for choosing suppliers, including their cybersecurity practices and secure development procedures and the overall quality and resilience of their ICT products and services. This is when the questionnaire arrives, often during the tender rather than at contract stage.

Security questionnaires

The questionnaire is usually a supplier's first encounter with NIS2. Some customers use their own lists, others use standard formats. ENISA's technical implementation guidance on the Implementing Regulation mentions, as possible evidence, reports based on the Standardized Information Gathering (SIG) questionnaire or the Consensus Assessment Initiative Questionnaire (CAIQ). The topics recur: access control and multi-factor authentication, encryption, backup and recovery, vulnerability and patch handling, secure development, logging, incident handling, subcontractors and where data is processed.

Evidence rather than assurances

A ticked "yes" no longer satisfies many procurement teams, because the customer has to back up its own assessment. They ask for documents:

• Certificates and attestations. An ISO 27001 certificate with a matching scope is a widely used form of evidence; in North America a SOC 2 report is common, and for cloud services an attestation against the BSI C5 criteria catalogue. ENISA's guidance explicitly names industry-standard certifications as evidence of a supplier's security practices and gives ISO 27001 and SOC 2 as examples. Note: a certificate only counts if its scope covers the product or service the customer actually buys.
• Security test reports. A penetration test report shows that your application has been tested from the outside and how you dealt with the findings. Customers usually want the date, the scope and the remediation status rather than every detail.
• Policies and process descriptions. Incident and notification process, patch and vulnerability management, access management, backup concept, list of subcontractors.

Notification duties in the contract

In-scope entities must report significant incidents in stages: an early warning no later than 24 hours after becoming aware, an incident notification no later than 72 hours, and a final report no later than one month after that (Section 32(1) BSIG). If the root cause lies with a service provider, the customer can only meet these deadlines if that provider informs it quickly. Supplier contracts therefore include a separate notification duty, as point 5.1.4(d) of the Implementing Regulation also provides, often with a fixed number of hours. That deadline is a contractual term, not a statutory one, so it can be negotiated. Only commit to what your out-of-hours availability can actually deliver.

How SMEs and SaaS providers can prepare

The good news is that almost every customer asks about the same things. Work out the answers properly once and you can reuse them for every further customer. Five building blocks carry most of the load.

1. Build an evidence pack

One central, current collection of everything customers typically request, with a date on every document:

• Short description of your security organisation, with a contact for security and incidents
• Certificate or readiness status, including scope
• Summary of your latest penetration test with date, scope and remediation status
• Incident and notification process with availability and deadlines
• Vulnerability and patch process with target times by severity
• Backup and recovery concept with the date of the last restore test
• List of subcontractors and data locations
• Description of your secure development: code review, dependency checks, separation of test and production

Much of this overlaps with the technical and organisational measures you already describe for GDPR data processing agreements. Maintaining both from one source avoids contradictions between documents.

2. A lean ISMS instead of a binder

Your answers need a working information security management system behind them, or they will not survive the first follow-up question. For small teams that means a tightly drawn scope, a handful of real risks, and controls that work technically and produce evidence. What this looks like for software teams is covered in our article ISO 27001 for SaaS and startups. One point is particularly useful for supply chain questions: ISO/IEC 27001:2022 has dedicated Annex A controls for supplier relationships (5.19 to 5.23). A customer that runs ISO 27001 already assesses suppliers along lines your ISMS can mirror.

3. A penetration test as solid evidence

For SaaS providers, a pentest report is often the quickest way to answer the question about product security with evidence instead of a promise. For the report to hold up in procurement, check three things:

• The scope matches the customer. Test what the customer uses: the application, its APIs, tenant isolation and roles. A test of your marketing website does not help much.
• The report can be shared. An executive summary you can pass on under a non-disclosure agreement without revealing attack details.
• Remediation is documented. A retest shows that the vulnerabilities found have been fixed. That is exactly the vulnerability handling point 5.1.4(f) of the Implementing Regulation expects to see in the contract.

A penetration test is an authorised assessment within a scope agreed in writing. Process, duration and scoping are explained in our article Penetration testing: process, duration and what it costs.

4. Answer questionnaires honestly and reusably

• Keep an answer library. File every answered question with its evidence. The second questionnaire then takes a fraction of the time of the first.
• Answer with evidence. Rather than "yes", write "yes, see document X, as of month and year".
• Name gaps openly. "Planned by quarter X" backed by a real plan is more credible than a "yes" that collapses at the first check. An incorrect commitment can become expensive under the contract later.
• Make one person responsible. Otherwise questionnaires end up with sales, who cannot judge the technical answers.

5. Check contract clauses before you sign

Supplier contracts often arrive as non-negotiated templates. Before signing, check with your legal counsel whether notification deadlines are achievable with your on-call setup, whether an on-site audit right can be replaced by audit reports, whether patch deadlines fit your release process and whether you can flow the requirements down to your own subcontractors.

The checklist

Where CyberSec42 helps

The typical situation: a large customer asks for evidence and the deadline is already running. We work on two fronts, separately or combined, within a scope agreed in writing.

Frequently asked questions

Further reading

• NIS2: who is affected and what to do next
• ISO 27001 for SaaS and startups: what counts
• Penetration testing: process, duration and what it costs
• Service: SaaS penetration testing as evidence for enterprise customers

Sources

• Directive (EU) 2022/2555 (NIS2), Articles 21 and 22, Recital 85 (EUR-Lex)
• Implementing Regulation (EU) 2024/2690, Annex points 5 and 6.5 (EUR-Lex)
• Section 30 BSIG: risk-management measures (gesetze-im-internet.de, German)
• Section 32 BSIG: reporting obligations (gesetze-im-internet.de, German)
• Bundestag document 21/1501: government bill implementing NIS2, with explanatory memorandum (German)
• ENISA: Technical Implementation Guidance on Implementing Regulation 2024/2690 (June 2025)
• BSI: NIS-2-regulated companies (German)
• BSI: C5 criteria catalogue
• ISO/IEC 27001:2022