secria.eu

What questions does a software company receive in a NIS2 questionnaire?

An overview of the questions that come up repeatedly in security questionnaires specifically for software developers: about the code you build and about the development pipeline in which you do that.

What questions does a software company receive in a NIS2 questionnaire?

If you develop software for a client who is themselves subject to Directive (EU) 2022/2555 — or to the Cybersecurity Act in the Netherlands — you will almost certainly receive a security questionnaire. The questions in such questionnaires always cover two things in software development: the security of what you deliver, and the security of the environment in which you create it. This second aspect distinguishes these questionnaires from those for, say, an installation company or a facilities service provider.

The core is always the same: can someone gain access to your client's system via your source code, your build environment, or your account at a package manager, and what do you do to prevent that or detect it quickly. Anyone who can answer those two questions is already well on their way through most of the checklist.

Why software is a separate category

For most suppliers, a client looks at what happens inside your company: who has access to which systems, how you test a backup. With a software supplier, there is an additional layer: what you send from your company to that of the client. This could be an update, an API connection, or code that runs directly in their environment. That is why a client asks more detailed questions here than with a supplier who only uses office automation.

Questions about the product: what you deliver

A large part of the questionnaire covers the software itself. Do you use external libraries and components, and do you keep track of which ones you use — often referred to as a software bill of materials. How do you handle a vulnerability discovered in such a component, and within what timeframe do you then release an update. Is code reviewed by a second person before it goes live. Do you test for known weaknesses before delivery, and who does that.

Below this there is often another question about disclosure: if someone outside your company discovers a vulnerability in your software, is there a way to report it to you, and what happens with such a report. This is not a legal obligation that flows from Directive (EU) 2022/2555 itself for you as a supplier, but in practice clients ask about it because they need to demonstrate it to their own supervisor.

Questions about the development environment: how you build

The second section covers the environment in which the software is created. Who has access to the source code, and is that access tied to individuals or shared. Is multi-factor authentication in place on the environment where code is built and delivered. Is a change automatically tested before it goes to production, and can someone bypass that step. Who manages the keys and certificates with which software is signed, and where are they stored.

Also quite consistently asked: how do you manage the laptops and accounts of developers who work with this environment, especially if they work remotely. And: do you keep logs of who changed what in the code or the pipeline, and for how long. The latter aligns with what is more broadly called incident logging, but focused on the development environment itself.

What a client may and may not ask

The checklist may address the security of your product and your development process insofar as it affects the client's risk. Questions about your entire internal organization, your personnel policies outside this context, or parts of your business that have nothing to do with the delivered software, are out of scope. Where exactly that line runs varies by contract and by sector, and that is something to clarify in the conversation with the client, not something to let pass unchallenged.

How to build this correctly once

Most of these questions are not a snapshot but a standing set that recurs with almost every client, just worded differently. Once you document the answers for each measure — with supporting evidence and an owner — you only need to copy and adapt them the next time you receive a questionnaire. With a few questions that show whether and how you are affected you first see where you stand, and in the overview by topic you will find the elaboration of individual measures such as access control and incident logging. If you are unsure about a specific question in a list you received, the list of frequently asked questions often already provides an initial direction, and an explanation of where our information comes from shows how we maintain sources.

If you want to first check for yourself whether and how your company is affected, do the free quick-scan or browse through the knowledge base. Both can be consulted without an account, and provide an initial, factual indication — not a judgment on your specific situation, for which you should always consult a lawyer or the supervisory authority responsible for your sector if in doubt.

This article is general information and not legal advice.