Most companies that end up dealing with NIS2 never read the directive and were never meant to be its subject. They find out about it because a customer sends a security questionnaire with a deadline attached, or because a contract renewal arrives with a new annex full of security commitments and audit rights. The obligations did not apply to them. They were passed to them, and refusing to engage means losing the account.
This is not an accident of implementation. It is how the directive was designed to work. NIS2 covers a defined set of sectors and size thresholds, but it also requires the entities it covers to manage the risk arriving through their suppliers. Since the regulator has no direct relationship with a supplier in Serbia, Turkey, the United Kingdom or the United States, the mechanism it uses instead is the customer’s procurement process.
Two routes in, and one of them is rare
The first route is direct applicability. Certain categories of service provider fall in scope when they offer their services within the EU, regardless of whether they have an establishment there. Cloud providers, data centre operators, content delivery networks, managed service and managed security service providers, DNS providers, domain registries and several categories of online platform are the ones most often affected. Where this applies, the directive expects the provider to designate a representative established in one of the member states where it offers services, and supervision follows that designation.
If your company sells infrastructure or platform services into the EU, this route deserves a proper legal review rather than an assumption. It determines which member state supervises you, and the answer is not obvious from your customer list.
For everyone else, and that is the large majority, the first route does not apply and the second one does anyway.
The second route is contractual. An in-scope customer is required to address supply chain security as part of its risk management, including the security of its direct suppliers and service providers. It cannot discharge that obligation by hoping. So it inspects, it asks, and it writes what it needs into the agreement. Nothing in that process requires you to be in scope, established in the EU, or subject to any European supervisory authority. It only requires you to want the contract.
The practical consequence is worth stating plainly: a software vendor with twelve employees and no EU entity can face more concrete security questions than a mid-sized manufacturer that is itself regulated, purely because of who it sells to.
Why the requirements come down rather than stopping at the border
An in-scope entity has to consider the vulnerabilities specific to each of its direct suppliers, the overall security practices of those suppliers, and the results of any risk assessments it performs on them. It also has to be able to show its supervisory authority that it did this.
That last part is what changes the tone of the conversation. Your customer is not asking you to complete a questionnaire because someone in their security team is curious. They are assembling evidence they will have to produce, and an unanswered questionnaire is a gap in their file. This is why the follow-ups escalate and why procurement gets involved: the request has a compliance owner on the other side who cannot close their item without you.
It also explains why the requirements are frequently disproportionate to what you actually supply. A large customer building a supplier programme normally starts with one questionnaire applied broadly, then tiers it later. If you sell a low-risk product and receive a document written for a cloud platform, that is a signal to negotiate the scope rather than to ignore it.
What actually arrives
The specific artefacts vary by customer and by sector, but the set is fairly stable.
A security questionnaire. Anywhere from thirty to several hundred questions, covering access control, patching, logging, backup, encryption, personnel security, physical security and incident handling. Sometimes it is a standard framework, and increasingly it is a bespoke spreadsheet.
A security schedule attached to the contract. This is the part that matters commercially, because it converts answers into binding commitments. Read it as carefully as the pricing.
Audit and inspection rights. Usually a right to audit on notice, sometimes with a right to send a third party. Look at frequency limits, notice periods, who pays, and whether the right extends to your subcontractors, because that last clause obliges you to have secured it from them first.
Incident notification obligations with short deadlines. These are the clauses that catch suppliers out. Your customer works to statutory deadlines that start the moment they become aware of a significant incident: an early warning within twenty-four hours, a fuller notification within seventy-two. Their clock does not begin when you tell them, so anything you spend deciding whether to report comes out of their twenty-four hours. That is why supplier clauses ask for notification well inside that window, often within a few hours of your becoming aware. A clause like that is unmeetable if nobody at your company knows who to call or what channel to use.
Evidence of vulnerability handling and secure development. How vulnerabilities reported to you are triaged and fixed, what your patch timelines are by severity, whether you have a disclosure contact, and for software suppliers, how code is reviewed, what dependency scanning exists and how build systems are protected.
Subcontractor disclosure. Who else touches the service or the data, where they are located, and what happens when that list changes. Expect an obligation to notify before adding one.
Preparing so that answering takes days, not weeks
The cost of these requests is almost entirely a preparation problem. The same evidence gets requested repeatedly, and companies that assembled it once answer in days while companies that improvise answer in weeks, badly, and with commitments they cannot keep.
A maintained evidence pack. A short set of current documents in one place: information security policy, access control and offboarding process, patch and vulnerability management, backup and restore arrangements including the date of the last tested restore, incident response plan, business continuity summary, subprocessor list, and any certification or audit report you hold. Everything dated and owned. The dating matters, because a policy last reviewed four years ago answers the question in a way you did not intend.
A completed baseline questionnaire. Fill in one recognised framework thoroughly, in your own words, and keep it current. Most incoming questionnaires then become a mapping exercise instead of a research project.
Named contacts. A security contact, a privacy contact and an escalation path, with real people behind them and coverage when those people are away. Customers ask for this specifically, and a shared inbox nobody watches will be tested during an incident.
An asset and data inventory. What customer data you hold, where it is stored, which cloud regions and providers are involved, who has administrative access, and how long you keep it. Nearly every hard question in a questionnaire reduces to something in this inventory, and its absence is why answers take weeks.
A tested notification path. Decide in advance who declares an incident, who notifies which customers, against what contractual deadline, and using what template. Then walk through it once with the people named in it. A notification obligation that has never been rehearsed will be discovered on the worst day, alongside the incident itself.
Where ISO 27001 helps and where it does not
A current certification is genuinely useful. It shortens conversations, satisfies some questions outright, and demonstrates that an independent party has examined your management system. If you are weighing whether to certify and your customer base includes regulated EU entities, the commercial case is easier than it used to be.
It does not, however, answer the question a NIS2-driven questionnaire is asking, and it is worth understanding why before leaning on it too hard.
A certificate attests that you operate a management system that has been assessed against the standard, within a scope that you defined. It says nothing about whether that scope includes the product this particular customer buys. Scope statements are frequently narrower than the certificate holder implies, and a reviewer who reads the statement of applicability will notice which controls were excluded and on what grounds.
Beyond scope, the customer’s obligation concerns their supply chain and their service. They need to know your patch timelines for the components in the thing they bought, how quickly you would tell them about a breach affecting their data, which subcontractors are involved, and whether they may audit. A certificate does not contain those answers. The most efficient position is to hold the certificate and still maintain the evidence pack, using the certificate to establish that a system exists and the pack to answer what was asked.
The same reasoning applies to SOC 2 reports and to sector schemes. They are inputs to your customer’s assessment, not substitutes for it.
The commercial argument
It is tempting to treat all of this as unpaid compliance overhead imposed by somebody else’s regulator. That reading is understandable and it is a mistake.
Supplier assessments are now a stage in the buying process, and like every other stage, it can be won or lost. A supplier who returns a complete, coherent questionnaire in a week with current documents attached is easy to approve. A supplier who takes six weeks, contradicts itself between answers, and cannot say who to call during an incident creates work for the customer’s security team and doubt in their file. When the customer needs to show its authority how it manages supplier risk, the second supplier is the one that gets replaced at renewal.
There is also a filtering effect worth noticing. Requirements of this kind are appearing in more tenders each year, and they raise the effort of entry. For a supplier that has done the preparation, that barrier works in its favour.
Where to start
Find out which of your customers are in scope, because those are the ones the requirements will come from, and check whether any of your own services put you on the direct route. Then assemble the evidence pack before the next request arrives, using the last questionnaire you received as the outline. The work is the same either way. Doing it in advance is what makes it cheap.
We help suppliers build the technical position and the evidence behind it as part of cybersecurity and compliance, and the access control and offboarding questions that appear in every questionnaire belong to identity and access management.