For a great many companies, the first encounter with NIS2 is not a statute. It is a contract renewal. A German customer sends an amended security annex, or a tender pack arrives with a supplier security section that did not exist last year, and somebody has to answer it.
The mechanism is worth understanding, because it does not depend on being in scope yourself. Information security stops at your firewall; responsibility for it stops at your legal entity. The gap between those two lines is what supply chain security is about: operations move outwards to providers, the duty stays at home. And where the duty stays at home, it travels outwards again through contracts.
Three instruments, one expectation
What is striking is how similarly the three instruments currently shaping the field argue at this point. None of them requires that your providers be secure. Each requires that the contracting organisation manage the security of its sourcing relationships and be able to evidence that it does.
One detail of the German transposition is routinely reported too softly. § 30(2) sentence 2 BSIG is not a collection of themes to orient yourself against but a binding minimum: the measures must cover at least the ten numbered items it lists, and supply chain security is number 4. At least cuts both ways: the numbered item is not negotiable, and the list is not exhaustive.
| Instrument | Legal source | Core of the requirement |
|---|---|---|
| NIS2 | Directive (EU) 2022/2555, Art. 21(2)(d); in Germany § 30(2) sentence 2 no. 4 BSIG | supply chain security as a numbered item of the statutory minimum catalogue, including the relationships with direct suppliers and service providers |
| DORA | Regulation (EU) 2022/2554, Chapter V Section I, Art. 28–30 | management of ICT third-party risk across the whole contractual lifecycle, minimum contractual content, exit strategies |
| ISO/IEC 27001 | Annex A, organisational controls | information security in supplier relationships, contractual agreements, the ICT supply chain, monitoring of services, use of cloud services |
The German NIS-2-Umsetzungsgesetz has been in force since 6 December 2025 and widened the population of supervised entities from roughly 4,500 to roughly 29,500. The side effect matters more than the headline for anyone outside Germany: every one of those entities now has to address its direct suppliers, and a large share of those suppliers are not German and not in scope of anything. They receive the requirement anyway, in writing, with a signature block.
Why the questionnaire does not carry the weight put on it
The supplier questionnaire is popular because it scales. It also has several design faults, and they compound.
It collects self-assertion without evidence. It is frequently answered by sales rather than by the security function, and it is not assessed. It is filed.
It describes the company, not the service you buy. A provider may run a well-managed management system whose scope does not cover the site or the service you actually consume.
It is a point-in-time document. A change of subcontractor, a migration to another region or a change of ownership devalues the answers without anyone finding out.
And it works asymmetrically. Large providers decline to complete bespoke questionnaires at all; small ones answer yes to everything. What you end up with is a response rate that evidences effort and says nothing about risk.
The levers that do work
Segment by criticality, not by spend. What matters is what a service carries: which business process depends on it and how sensitive that process is. The inexpensive niche provider underpinning a time-critical procedure belongs in the top group; the expensive stationery supplier does not.
Put it in the contract rather than the questionnaire. What is effective is what is enforceable when it matters: notification duties with a stated deadline and a named channel, transparency and a consent right over subcontractors, inspection and audit rights, committed recovery times, the place of processing, and agreed data return with an exit scenario. DORA prescribes minimum contractual content of this kind for financial entities expressly; for everybody else it is simply the only place where a requirement on a third party becomes binding.
Read the scope, not the logo. A certificate becomes evidence only once its scope statement, sites, validity period and issuing certification body have been checked. Third-party audit reports say more than certificate copies because they contain findings. Every piece of evidence you file needs an expiry date, or the folder ages silently.
Trigger on events, not on the calendar. An annual review misses exactly the events that matter: a change of subcontractor, a security incident at the provider, a change in the scope of services, a change of ownership, financial distress.
The blind spot sits one level down
Two risks only appear beyond the direct contracting party.
The first is concentration. Three providers you manage as independent can run on the same platform or in the same region, so that one outage takes all three at once. Multi-vendor on paper is not diversity in practice.
The second is subcontractors. Their replacement may well be notifiable under the contract, but in practice it is only noticed if somebody reads the notification and reconciles it against their own records.
Neither question can be answered while providers live in a list of their own. They have to sit in the same inventory as processes, applications and systems, with the relationships recorded between them. Only then can you answer the question that actually gets asked in an incident: if this provider fails, what stops?
In an incident your clock runs, not theirs
This is the hardest point of the lot, and the one that catches suppliers outside Germany by surprise. Your own reporting deadlines run regardless of how quickly a provider tells you anything. The early initial notification under § 32 BSIG falls due within 24 hours; under DORA, separate and likewise short stages apply to major ICT-related incidents. A company that learns from its provider's status page that an incident is running has already spent most of that window.
The reporting chain therefore belongs in the contract, and once in an exercise, including the question of who reaches whom at two in the morning, in which time zone, and in which language.
A realistic way in
Do not start with a questionnaire. Start with the accounts payable ledger: it shows who is actually being paid, which is a more honest list than any register of approved suppliers. Map those entries to the processes and systems they support, segment by criticality, and close the contractual gaps in the top group first. The rest can follow.
A small, maintained set of supplier records that is connected to the asset inventory will carry you further in an audit and in an incident than a complete questionnaire archive whose age nobody can see.
The lever that does not work without an inventory
Of the four levers the piece describes, three presuppose that the list of providers is complete and the dependencies known. In most organisations that condition does not hold, and it is why questionnaires end up standing in as a substitute: you can only survey what you know about.
In Rizzqo a provider is therefore not an entry in a side list but a supporting asset like a server, with a category and subcategory, a named owner inside your own organisation, and links to the business processes and information running through it. The structure runs across several steps, so sub-suppliers can be modelled and three formally independent providers resting on the same one show up as converging links. Criticality follows from that rather than from an estimate. NIS2 is supported; its catalogue is enabled when a customer needs it.