You read the scope, concluded your company is too small and the sector is wrong, and moved on. That reasoning is usually correct and almost never the end of it — because the organisations that are in scope are required to manage the security of their suppliers, and you are one.
This is the part of NIS2 that catches software companies off guard. Not an inspection, not a fine. A procurement questionnaire attached to a renewal, from a customer who now has to be able to account for you.
What follows is a practical description of what tends to arrive and what is worth having ready. It is not legal advice, and whether your own company falls directly in scope is genuinely a question for a lawyer — the sector definitions and thresholds have real edge cases.
What NIS2 is, briefly
NIS2 is an EU directive raising the baseline for cyber security across sectors judged critical to society, replacing an earlier and much narrower directive. Being a directive rather than a regulation, it takes effect through each member state's own implementing law, so the specifics and the timing differ by country.
Two features matter more than the rest for a supplier:
It has teeth at the management level. NIS2 puts responsibility on company leadership explicitly, including approval of the risk measures. Where earlier rules could be delegated downward until they evaporated, this is deliberately harder to ignore — and it is why the questionnaires you receive are being taken seriously by the people sending them.
Supply chain security is a named obligation. An organisation in scope must consider the security of its direct suppliers and service providers as part of its own risk management. That sentence is the entire reason this article exists.
Why "we are not in scope" does not settle it
Scope is about the entity, not the requirements. If you sell software to a hospital group, an energy company, a transport or postal operator, a bank, a water utility, a central government body or a managed service provider, at least some of your customers are in scope. They are obliged to manage supplier risk. They cannot do that without asking you things.
So the obligation reaches you as a commercial requirement rather than a legal one — which in practice is harder to argue with, not easier. A regulator might negotiate. A procurement process that has flagged your contract as non-compliant simply does not renew.
The pattern to expect: the first request arrives from your largest customer, is answered in a scramble, and then arrives from three more within a year, each in a slightly different format.
One caveat on that, because it catches the reader this article is written for. If what you sell is a hosted service rather than software the customer installs, read the digital sector entries before concluding you are outside: cloud computing services, data centres, managed service providers and managed security service providers are all named categories. A SaaS company past the medium-sized threshold can be in scope on its own account, not merely through a customer. For most small vendors it is the size threshold that keeps them out, not the sector list — and size thresholds are the kind of thing that changes while you are not looking at it.
What actually turns up in the questionnaire
These are consistently the difficult ones, in the sense that most companies cannot answer them from existing records:
- "Provide a bill of materials for the software you supply." Every third-party component, with version and licence. If you cannot generate this, you are writing a spreadsheet by hand that is wrong before you send it. What an SBOM is and how to produce one covers this properly.
- "Describe your vulnerability handling process." Not whether you scan. How you find out, how quickly, how you decide what to fix first, and how you tell customers. A named process beats an impressive tool here.
- "How quickly do you patch a critical vulnerability?" They want a number and a basis for it. "As soon as possible" reads as no process at all.
- "Do you have a contact for reporting a vulnerability in your product?" A published security contact and a stated response commitment. This is cheap to set up and conspicuous by its absence.
- "How and when will you notify us of an incident?" NIS2 puts short reporting deadlines on the entities in scope: an early warning within 24 hours of becoming aware of a significant incident, a fuller notification within 72 hours, and a final report within a month. Your customer cannot meet theirs if you take a week to tell them, so their timeline becomes a term in your contract.
- "Which of your own suppliers can reach our data?" The chain continues past you.
What to have ready
In rough order of what buys most credibility per unit of work:
A generated software inventory. Not maintained by hand — generated from the same resolution that produces your actual dependency tree, in SPDX or CycloneDX, dated. This single artefact answers the hardest question in most questionnaires. Answering it well is disproportionately convincing, precisely because so few suppliers can answer it at all.
A written vulnerability handling process, one page. How you learn about vulnerabilities, how often you check, how you prioritise, what your target response times are, and how you inform customers. One page that describes what you actually do beats ten that describe what you aspire to, and the reviewer will notice the difference.
Evidence that it runs. A process document nobody can demonstrate is a claim. Dated scan results, a findings history showing things being raised and closed, and a record of decisions — including risks you accepted, with reasons — turn an assertion into something checkable.
A security contact and a disclosure policy. An email address that reaches someone, a stated response time, and a security.txt on your site. An afternoon of work.
An incident notification commitment you can actually meet. Before you sign one. Their clock starts when they learn; yours has to start earlier.
A VEX statement, if you ship software customers scan. This is the advanced item, and it solves a specific recurring pain: your customer runs your SBOM through a scanner, gets forty hits, and emails you about all of them. A VEX document is the standard way to say which of those actually affect your product and why the rest do not.
What not to do
Do not answer aspirationally. A questionnaire response is a contractual representation. "We continuously monitor all dependencies" is a bad sentence to have written if an incident later shows you did not. The honest version — what you do, how often, what you do not cover — is both safer and, on the evidence of how these actually get read, more persuasive.
Do not buy a certification to make it stop. ISO 27001 is valuable and genuinely helps with these conversations, but it is a large programme and it does not by itself answer the supply-chain questions above. Many companies start there because it is legible, and arrive a year later still unable to produce a bill of materials.
Do not treat the first questionnaire as a one-off. It is the first of many, and they will diverge in format while asking the same six things. Build the answers as artefacts you can regenerate, not as a document you wrote once for one customer.
Does NIS2 apply to my company if I am just a supplier?
Usually NIS2 does not apply to a supplier directly: scope depends on sector, size and the role your organisation plays. But the organisations that are in scope must manage the security of their direct suppliers as part of their own risk management, so the requirements reach you contractually through your customers rather than through the directive. In practice that is harder to argue with than a regulatory obligation, because a procurement process that flags your contract as non-compliant simply does not renew it.
What does NIS2 require about supply chain security?
NIS2 makes the security of direct suppliers and service providers a named part of an in-scope organisation's own risk management, rather than something optional. That is why suppliers who are not themselves covered start receiving security questionnaires: their customer cannot demonstrate compliance without being able to account for the software and services they buy. NIS2 also places responsibility explicitly on company management, which is why these requests are being pursued seriously.
What do NIS2 supplier questionnaires actually ask for?
NIS2 supplier questionnaires consistently ask for six things that most companies cannot answer from existing records: a bill of materials for the software you supply, a description of your vulnerability handling process, your target time to patch a critical vulnerability, a published contact for reporting vulnerabilities in your product, how and how quickly you would notify them of an incident, and which of your own suppliers can reach their data. The bill of materials is the one that usually cannot be produced on short notice.
How should I prepare for a NIS2 supplier questionnaire?
Generate a software bill of materials rather than maintaining one by hand, since it answers the hardest question and few suppliers can produce it. Write your vulnerability handling process down on one page, describing what you actually do rather than what you aspire to. Keep evidence that the process runs, including decisions to accept a risk and the reasons. Publish a security contact with a stated response time. And agree an incident notification commitment you can genuinely meet before you sign one.
Where TrustCtrl fits
CodeControl produces the artefacts these questionnaires ask for as a by-product of doing the work. The software bill of materials is generated from a real scan, in both SPDX and CycloneDX, dated — and a VEX document from the triage decisions your team already made. The findings history is the evidence that the process runs, including the risks you accepted and why. VulnControl covers the same question for the software your service runs on rather than the software you ship.
None of that makes anyone compliant on its own — compliance is a question about your organisation, not your tooling. What it changes is whether answering takes an afternoon or a fortnight.