A client subject to the NIS2 duty of care must be able to demonstrate that they understand the risks in their own supply chain. Software that you develop for that client is part of that chain. In practice, this translates into contractual requirements that address two things simultaneously: the product you deliver, and the way you make that product. Both are reflected in the contract text, often as an annex to the procurement contract.
The core principle is straightforward: the client asks not only whether the software works, but also whether you can demonstrate how it remains secure, who has access to it, and what happens if something goes wrong. This represents a shift from the past, when functionality and delivery time were often the only points of discussion.
Requirements for the product you deliver
The most common contractual requirement concerns the composition of the software itself. Clients increasingly ask for an overview of the libraries and open-source components used, a so-called software bill of materials. The reason is that a vulnerability in an underlying component poses just as much risk as a flaw in your own code, and a client wants to be able to see through those risks without having to read the source code themselves.
Requirements also appear regarding how vulnerabilities in the software are identified and remedied, and within what timeframe. This may involve automated scans for known weaknesses, a fixed procedure for patches, or the question of who may report a vulnerability and where it should be directed. For existing software, clients sometimes also ask about the support period: how long a version remains provided with security updates.
Requirements for your own development pipeline
A second cluster of requirements focuses not on the product, but on the process by which it is made: the development pipeline. Think of who has access to the source code and the environment in which building and testing takes place, how changes are controlled before they go live, and whether there is separation between a test, acceptance, and production environment. The use of multi-factor authentication for developers who have access to source code or build systems also appears in contracts, as does the question of who manages the keys and credentials associated with software deployment.
Some clients also ask about the origin of the software you use to build: the compiler, the build tools, the packages retrieved during the build process. This aligns with a broader understanding that an attack can run not only through the final product, but also through the factory in which it is made.
Why these requirements are formulated precisely this way
The duty of care that underlies all of this requires an organisation subject to the directive to assess and manage risks in its own supply chain. How this is precisely implemented varies by country in the national law based on the European directive, and by the sector in which the client operates. What is a hard requirement in one contract may still be a non-binding question in another contract. If you want to understand how that obligation is structured fundamentally, you can read it in the explanation per obligation in our knowledge base.
Important to remember: it is the client who sets these requirements because they themselves are under supervision, not because software companies as such fall under the directive. Whether and how strictly this is enforced in your case depends on the sector and the size of that particular client. For your own situation, the text of the national law or advice from a legal professional is the appropriate starting point, not a general assessment.
What this means for your preparation
Most of these requirements can be answered well with some preparation, and the response you draft once can be reused each time with a new client. A list of components in use, a brief description of your access controls and a fixed procedure for patches are not documents you need to reinvent for every contract.
If you first want to see whether and how this affects your organisation, then the check that determines your position in the supply chain in a few questions provides an initial direction, without requiring an account. For the specific questions that clients ask and the way we support you in answering them, read more at the frequently asked questions page or see how we substantiate the information on the platform.
The free knowledge base and the check give you an initial overview without obligations. If you then want to actually translate the contractual requirements into an ongoing dossier with evidence and ready-made answers to questionnaires, that is the moment to consider what a subscription adds to that.