EU rules

NIS2 supplier checks: what a software vendor should answer

What NIS2 Article 21 and Germany's BSI Act require of buyers when they check a software vendor, and ten questions built from the legal text.

·

8

min read

In short

  • NIS2 Article 21(2)(d) lists supply chain security among the minimum measures, and Article 21(3) says covered companies must weigh each supplier's secure development procedures.

  • Germany's NIS2 law was published on 5 December 2025 and took effect the next day, and Section 30 of the BSI Act repeats the supply chain duty for the companies it covers.

  • The Federal Office for Information Security (BSI) says the law does not directly bind every supplier, so covered companies are expected to pass requirements on to them.

  • The most detailed list of contract points for suppliers sits in an EU implementing regulation that binds only certain provider types, and we use it as a model for questions, which is our reading.

Cover for the article "NIS2 supplier checks: what a software vendor should answer": the title in white on a dark background, with the label FlightLabs Insights.

If your company falls under NIS2, you must take the security of your suppliers into account, and a software vendor is a supplier. The law does not hand the vendor a checklist, so a buyer's question list has to be built from the legal text.

What does NIS2 require of a buyer about its suppliers?

Directive (EU) 2022/2555 is the NIS2 Directive. Article 21(1) tells Member States to make "essential and important entities" take "appropriate and proportionate technical, operational and organisational measures". Article 21(2) then lists measures that must be included "at least". Point (d) is "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers". Point (e) covers "security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure".

Article 21(3) is the text most relevant to a vendor check. When an entity decides which supply chain measures are appropriate, it must take into account "the vulnerabilities specific to each direct supplier" and "the overall quality of products and cybersecurity practices of their suppliers and service providers, including their secure development procedures". Recital 85 names software editors among the suppliers it has in mind and says entities "should in particular be encouraged to incorporate cybersecurity risk-management measures into contractual arrangements with their direct suppliers".

Two limits are worth knowing. The article says "direct suppliers", and the recital only says entities "could consider" other levels. Article 22 puts no duty on the buyer. It lets the NIS2 Cooperation Group, with the Commission and ENISA, carry out coordinated risk assessments of critical ICT supply chains. Article 21(3) then requires entities to take the results into account.

Article 20 puts the approval and oversight of these measures on the management body, which "can be held liable" for infringements of Article 21.

Does Germany's law say the same?

Yes, in nearly the same words. The act implementing NIS2 was issued as Federal Law Gazette 2025 I No. 301 on 5 December 2025, and its Article 30 says it enters into force "am Tag nach der Verkündung", the day after promulgation. The BSI states that it came into force on 6 December 2025. The EU deadline in Article 41 of the Directive was 17 October 2024, so Germany's law took effect more than 13 months after that date.

Section 30(2) of the BSI Act lists the same minimum measures. Number 4 is "Sicherheit der Lieferkette einschließlich sicherheitsbezogener Aspekte der Beziehungen zu unmittelbaren Anbietern oder Diensteanbietern", and number 5 covers security in acquisition, development and maintenance, including handling and disclosure of vulnerabilities. Section 30(1) adds that compliance must be documented. Our reading is that a covered buyer therefore needs the vendor's answers in writing.

The BSI counts about 29,500 companies in Germany and institutions of the federal administration as covered, according to its press release of 6 January 2026. Its statistics page shows 20,141 entities registered in the BSI portal by 30 September 2026. These are different measures: the first is an estimate of who is covered, the second a count of who has registered.

Can a covered company push these duties onto its vendors?

The BSI answers this in its page on the secure supply chain. It says the BSI Act does not indirectly oblige all suppliers and service providers. Covered companies may no longer be able to work with every company without risking a breach of their own duties, and the BSI calls it an economic decision whether a supplier keeps serving covered entities in the EU. It also says covered companies must oblige their suppliers to meet matching security requirements.

The BSI's general FAQ on NIS2 goes further in item 27. It quotes the explanatory memorandum to the law: supply chain measures include "vertragliche Vereinbarungen mit Zulieferern und Dienstleistern zu Risikomanagementmaßnahmen, Bewältigung von Cybersicherheitsvorfällen, Patchmanagement". Entities may also ask suppliers to follow security by design and security by default. A supplier that is not itself covered may find it sensible to check its own practices against Section 30(2) before agreeing terms with a covered client. Item 2 of the same FAQ adds that a company that has outsourced all its IT stays responsible, and that contracts alone do not suffice.

What can a buyer ask for in the contract?

The most concrete list is in Commission Implementing Regulation (EU) 2024/2690. Point 5.1.4 of its Annex says the entities it covers must ensure that contracts with suppliers specify, "where appropriate", a set of eight points.

The first group concerns the supplier's own conduct. The contract states cybersecurity requirements for the supplier, covers the awareness, skills and training of its employees and certifications where appropriate, and provides for verification of the background of its employees. The second group concerns what happens when something goes wrong. The supplier must notify incidents "without undue delay", the buyer receives "the right to audit or right to receive audit reports", and the supplier takes on an obligation to handle vulnerabilities that present a risk to the buyer. The third group concerns the chain and the end of the relationship: rules on subcontracting, with matching requirements for subcontractors, and obligations at the end of the contract, such as retrieval and disposal of information.

Point 6.1.2 adds what to ask for when acquiring an ICT product or service: security requirements, security updates "throughout the entire lifetime" or replacement after the end of support, information describing the hardware and software components, and methods for validating that the delivered product meets the requirements.

This regulation does not apply to every NIS2 entity. Its Article 1 names DNS service providers, TLD name registries, cloud computing service providers, data centre providers, content delivery network providers, managed service providers, managed security service providers, online marketplaces, search engines, social networking platforms and trust service providers. ENISA's technical implementation guidance of June 2025 explains the regulation and describes itself as "not legally binding" and "only of an advisory character". It adds contract elements to consider, such as where data is processed and the right of competent authorities to audit.

So a vendor outside those provider types is not bound by point 5.1.4. Its customer, if covered, still has to show that it considered the vendor's practices under Article 21(3). Our reading is that the point 5.1.4 list is a fair model for what a covered buyer may ask for, since it is the EU's own description of what a supply chain contract should contain. No text we found says a buyer must ask for every item.

Which questions should a vendor be able to answer?

This section is our addition. We took the legal text above and turned each requirement into a question. The reference in brackets shows where the question comes from. The list is a working tool and not legal advice.

Three questions establish who the vendor is and how it builds. Ask whether it is covered by NIS2 or the BSI Act itself, and under which type of entity (Implementing Regulation Article 1; BSI FAQ item 27). Ask how it develops software securely and where those procedures are written down (Article 21(3); Annex point 6.2). Ask how customers and researchers report a vulnerability to it, and what it does with the report (Article 21(2)(e); Annex point 5.1.4(f)).

Four more questions concern the product itself. The buyer can ask for how long the vendor provides security updates for each version, what happens at the end of support, and whether it can describe the software components its product contains (both from Annex point 6.1.2). It can also ask how the vendor tests that the product meets its security requirements and whether the results can be shown (Annex points 6.1.2 and 6.2.2), and how soon the vendor will report an incident that puts the buyer's systems at risk (Annex point 5.1.4(d)). Your own reporting clock under Article 23(4) is 24 hours for an early warning and 72 hours for a notification.

The remaining questions concern oversight and people. Ask whether you can audit the vendor, or receive audit reports (Annex point 5.1.4(e)), and how its staff are trained and background-checked (Annex point 5.1.4(b) and (c)). Finally, ask which subcontractors touch your data or code and what requirements bind them, and what happens to your data and access at the end of the contract (Annex point 5.1.4(g) and (h)).

The incident question carries weight because Article 23(4) gives a covered buyer 24 hours from becoming aware of a significant incident. If the incident started at the vendor, a promise to report within a week would leave the buyer unable to meet its own deadline. That is our reading.

Written answers help because Section 30(1) of the BSI Act requires the buyer to document its compliance. Certificates can support an answer. The BSI cautions that applying a standard does not automatically mean the BSI Act is fully met.

What does FlightLabs send for a supplier check?

We publish what we send on our security and data protection page: a data processing agreement with the sub-processors and security measures listed, an incident commitment in writing to tell you within 24 hours at the latest, our AI-tool policy, and written answers to security questionnaires with an engineer on the call. If a client under NIS2 asks how the software we build is tested, our application security testing produces a report with each finding ranked and a retest. How a project runs day to day is on how we work. These are descriptions of our own offer. Whether they satisfy a particular buyer's NIS2 duties is for that buyer and its lawyer to judge.

What we could not confirm

The EUR-Lex site refuses automated requests. We read the Directive and the implementing regulation in the Official Journal text served by the EU Publications Office, and we did not compare it with any consolidated version or corrigendum.

On 20 January 2026 the Commission proposed "targeted amendments to the NIS2 Directive". Its press release lists easier compliance, a small mid-cap category, jurisdiction, ransomware data and supervision, and it names no change to Article 21 or 22. The same package proposes a revised Cybersecurity Act with an ICT supply chain security framework aimed at high-risk third-country suppliers, which we did not study. We could not open the proposal text, and we did not find out whether it has been adopted.

We did not assess whether a software-as-a-service vendor counts as a "cloud computing service provider" under the Directive, which decides whether point 5.1.4 binds it. We did not look for a ministerial ordinance under Section 30(5) of the BSI Act that could add requirements. We found no official statement of which written proof a German buyer must hold from a supplier, since the BSI FAQ says only that it can be sensible to check practices against Section 30(2). The BSI supply chain page shows no publication date.

Sources

Researched and written by FlightLabs. Every figure links to its source. Facts last checked on

Share

Share on LinkedIn (opens in a new tab)

Related service

Application security

See the service

Have a project in mind?

We reply within one working day.

FlightLabs is a Berlin-based software engineering company that builds, tests, secures and runs production software and AI for European companies, with its engineering team in Addis Ababa, 1–2 hours from Central European Time.

hello@flightlabs.ioBerlin, GermanyEngineering team: Addis Ababa, Ethiopia
LinkedIn (opens in a new tab)

In partnership with eTech S.C.