Answering NIS2 Supplier Questionnaires as a Software Vendor

· Yunus Yildiz

If you sell software to hospitals, energy companies, municipalities or cloud providers in the EU, the questionnaires have probably started. NIS2 rarely regulates the supplier directly; the Dutch regulator is explicit that "een toezichthouder zal geen toezicht houden op toeleveranciers". What it regulates is the customer, and the customer's obligations include you.

This post goes through what the law asks your customer to consider, and then through an answer kit that covers most questionnaires with one set of documents.

What Your Customer Has to Weigh

Article 21(2)(d) of NIS2 requires essential and important entities to address "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 that involves:

entities take into account the vulnerabilities specific to each direct supplier and service provider and the overall quality of products and cybersecurity practices of their suppliers and service providers, including their secure development procedures.

That is a judgment about you, and your customer has to be able to show how they made it. Hence the questionnaire.

For one group of customers the Commission went further. Implementing Regulation (EU) 2024/2690 sets detailed requirements for cloud computing, data centre, content delivery, managed service and managed security service providers, DNS and TLD operators, online marketplaces, search engines, social networks and trust service providers. If your customer is one of them, its supplier obligations are written out in the Annex:

  • Selection criteria (point 5.1.2): your "cybersecurity practices ..., including [your] secure development procedures", your ability to meet their specifications, and "the overall quality and resilience of ICT products and ICT services".
  • Contract terms, where appropriate (point 5.1.4): cybersecurity requirements, staff skills and background checks, an obligation to notify incidents "without undue delay", "the right to audit or right to receive audit reports", an obligation to handle vulnerabilities, rules for subcontracting, and what happens at termination.
  • What to obtain when acquiring a product (point 6.1.2): requirements on "security updates throughout the entire lifetime ... or replacement after the end of the support period", "information describing the hardware and software components used", the cybersecurity functions and secure configuration, and a way to validate that what was delivered meets the requirements.

Point 6.1.2(c) is an SBOM request in all but name.

Customers outside that list follow their national law. In the Netherlands, the Cyberbeveiligingswet's duty of care includes the measure "Maak je toeleveringsketen veilig", and the NCSC mentions frameworks such as ISO 27001 while stating that none of them is mandatory or a guarantee. The questions that result are the same ones, worded differently. The Dutch side is covered in what Cbw customers may ask of their software suppliers.

The Four Questions

Strip the formatting off any supplier questionnaire and it asks four things about a specific release.

1. What is in it?

The legal hook is 6.1.2(c) and the "overall quality of products" in Article 21(3). The evidence is a software bill of materials for each release, in a machine-readable format (CycloneDX or SPDX), tied to the artifact it describes by its digest. One SBOM for "the product" answers nothing, because the customer runs a version, not a product. What the CRA itself requires of an SBOM, and from when, is in the clause-by-clause SBOM post.

2. What do you know about its vulnerabilities?

The hooks are NIS2 Article 21(2)(e), "vulnerability handling and disclosure", and the contract obligation "to handle vulnerabilities" in 5.1.4(f). The evidence has three parts:

  • scan results for that release, with the date of the scan, because a result without a date says little;
  • exploitability statements for findings that do not affect you, so the customer's scanner and yours can be reconciled (a VEX document is the machine-readable form);
  • your coordinated vulnerability disclosure policy and a contact point, for example in a security.txt.

If you are a manufacturer under the CRA, add your process for Article 14 reporting, which has applied since 11 September 2026.

3. How do I know this is your artifact?

The hooks are the assurance and validation requirements in 6.1.2(e) and (f): the customer must be able to check that what arrived is what was assessed. The evidence is a signature on each artifact and a provenance attestation saying how and from what it was built, together with the exact command to verify both. A signature nobody can verify with a documented key or identity is decoration.

4. What happens when it goes wrong?

The hooks are the incident notification obligation in 5.1.4(d) and the support-period requirement in 6.1.2(b). The evidence is:

  • how and how fast you notify customers of incidents that affect them, in terms you are willing to put in a contract;
  • the support period of each version: how long it receives security updates, and what the customer should move to after that;
  • how updates reach them and how they are told.

Everything Else on the Form

Questionnaires also ask about your company rather than your release: certifications, staff screening and training (5.1.4(b) and (c)), audit rights (5.1.4(e)), subcontractors and subprocessors (5.1.4(g)), and data return or deletion at the end of the contract (5.1.4(h)). These change rarely. Write them down once, have them reviewed, and version them.

The Answer Kit

The work is not answering once. It is answering fifteen times, in fifteen formats, every year. Split the answers into what describes the company and what describes a release, and keep both where a customer can be pointed to them.

== COMPANY PACK (reviewed yearly, versioned) ==
Security contact and security.txt location
Coordinated vulnerability disclosure policy
Incident notification commitment (who, how, how fast)
Support period policy (per product line; how end of support is announced)
Secure development practices (short description, not a slogan)
Certifications and audit reports held, with scope and date
Staff screening and security training
Subcontractors / subprocessors with a security role
Contract templates: audit rights, incident notice, vulnerability handling, termination
[CRA manufacturers] Article 14 reporting process and coordinating CSIRT

== RELEASE PACK (produced by the build, per version) ==
Artifact identifier and digest
SBOM (CycloneDX or SPDX), bound to the digest
Vulnerability scan result, with scanner and date
Exploitability statements (VEX) for findings that do not apply
Signature and the command to verify it
Provenance attestation (source, builder, inputs)
Release notes listing security fixes
Support end date for this version

The company pack is a document. The release pack only works if the build produces it, because nobody will assemble eight files by hand for every release, and a questionnaire always asks about the version the customer is running, not the latest one.

Sources

This article reflects our reading of the sources above as of the date given. What a specific customer may require depends on its own risk assessment and national law. It is not legal advice.