NIS2 and suppliers: what your large customer asks of you and how you prove it

Published on May 12, 2026 · Updated on October 28, 2026

This article is general information about laws and regulations, not legal advice.

A questionnaire about your security, sender: the procurement department of your largest customer. You supply software, hosting, managed services, maintenance or components to a hospital, a grid operator or a municipality, and that customer falls under NIS2. The short answer: as a supplier you usually do not fall under it yourself, but your customer does. Since 15 August 2026 it has to be able to demonstrate that it manages the risks of its suppliers, and it may therefore set you requirements that match the risk of your service. What you send back is an honestly completed questionnaire with dated evidence of what you expose to the internet and what you remediate there.

In short

NIS2 obliges the organisations that fall under it (the law calls them essential and important entities) to arrange the security of their supply chain, including their relationship with direct suppliers (Article 21(2)(d) of the directive). In the Netherlands this has applied since 15 August 2026 through the Cyberbeveiligingswet (Cybersecurity Act).
The obligation rests with your customer. Your obligations arise through that customer's contract and procurement policy.
The requirements must be proportionate to the risk your service poses. A marketing agency faces lighter requirements than whoever hosts core systems.

Two questions often come back: which standard or certificate you follow, and evidence that your basic security holds up. This article is mainly about the second: knowing what you expose to the internet, closing vulnerabilities in time and being able to show it.

Do you fall under the act yourself?

The act applies to organisations in designated sectors, such as energy, drinking water, healthcare, digital infrastructure, transport and government, and then only from a certain size. An installation company or maintenance contractor usually does not fall under it, not even with more than 50 employees. Such a company receives the questionnaire because it has remote or physical access to the installations or systems of a customer that does fall under it. If you manufacture or trade yourself, look carefully. An organisation of medium size or larger (generally 50 employees) that makes electronics, electrical equipment, machinery, vehicles or medical devices, among other things, or runs a wholesale business in food or chemicals, may fall under it itself. The same applies to IT service providers: managers of IT environments (managed service providers), security service providers, cloud providers and data centres fall under it themselves from that same size, with technical requirements from a European implementing regulation (Implementing Regulation 2024/2690). In doubt? Take the NIS2 self-check. Only organisations that fall under the act themselves have to register in the NCSC entity register.

Why your large customer suddenly sets requirements

According to the Dutch government, more than 8,000 organisations in 18 sectors fall under the Dutch Cybersecurity Act. Because each of them buys from many suppliers, the act indirectly reaches many times that number; there is no official count.

For those 8,000 organisations the supply-chain duty of care is a part of their duty of care that the regulator can check. The Dutch NCSC advises them to check suppliers' answers, because a completed questionnaire on its own does not say enough. That is where the questionnaire, the amended contract or the request for a recent scan report comes from. What the law does and does not require of your customer more broadly is set out in what is actually required under the NIS2 supply-chain duty of care.

In depth: what Article 21 says about suppliers exactly

Article 21(2)(d) of the NIS2 directive names supply-chain security, including the security-related aspects of the relationship between the entity and its direct suppliers and service providers. Paragraph 3 adds that the entity takes into account the vulnerabilities specific to each direct supplier and the quality of its products and cybersecurity practices, including secure development procedures. In the Cyberbeveiligingswet that last provision is in Article 21(4). If you supply software, that is where the questions about your development process and your dependencies come from.

Two words matter for your position. Direct suppliers: your customer's obligation is aimed at its direct suppliers, so at you. And appropriate and proportionate (paragraph 1): the requirements must be in proportion to the risk. Many questionnaires also ask about your own suppliers, even though the directive itself imposes nothing on you there. How to answer that is covered in theme 4 of the guide to the NIS2 supplier questionnaire. If you hold ISO 27001, supplier controls 5.19 to 5.23 of ISO 27002 cover that question. The comparison table by Digitale Overheid, drawn up for government bodies, links Article 21(2)(d) to exactly those five controls.

What requirements may your NIS2 customer impose on you as a supplier?

Proportionality is the yardstick. A supplier that hosts core systems or has access to customer data can expect heavier requirements than a supplier of office furniture. Disproportionate could be, for example, a mandatory ISO 27001 certificate for a supplier without access to customer systems, a penetration test by a specialist (pentest) every quarter for a service with no internet connection, or an unlimited on-site audit right. The NCSC advises your customer to classify suppliers by importance and to tailor requirements accordingly. Among other things, it looks at whether a supplier is indispensable for what the customer most needs to protect, and whether it has access to confidential systems or data. Ask yourself those questions too, and ask your customer whether it has classified you and in which category. When a requirement is heavy, offer a lighter alternative that demonstrates the same thing.

Within that limit the same questions keep coming back. They cover how your systems stay up to date with security updates (vulnerability management), whether outdated software or admin login pages are openly exposed to the internet, and how you manage access and your domain. There are also questions about logging in with a second step (MFA, for example a code on your phone), about a notification period for incidents and about your own subcontractors. Such a supplier assessment (purchasers often call it a Vendor Security Assessment) contains, for example, a question like this:

"Describe your process for patch management and vulnerability management. Indicate within how many days critical vulnerabilities in systems reachable from the internet are remediated, and attach evidence of the most recent vulnerability scan. Also confirm whether multi-factor authentication (MFA) is enforced on all systems from which [customer name] data can be accessed."

"We patch monthly in line with our policy" is an answer your customer has to believe. "Critical vulnerabilities on internet-facing systems within 14 days; attached are our scan report of 1 October and our list of September's findings with the date on which we remediated each of them" is one it can check. When asked for "the most recent vulnerability scan", ask whether your customer means your internet-facing systems or your internal systems. For what is exposed to the internet, an external measurement is the right document. How to answer the questionnaire theme by theme is covered in the guide to the NIS2 supplier questionnaire.

In depth: which provisions you may come across in the contract

The same requirements return in the contract or in a security annex. Expect a notification period for incidents that may affect your customer, because it has to report a significant incident itself to the NCSC's central reporting point as an early warning within 24 hours and as an incident notification within 72 hours. You may also come across, for example:

an annex with minimum requirements, such as remediation periods for vulnerabilities, MFA and log files;
insight into your own subcontractors, and a notification when you change them;
a right to an audit or to a test by or on behalf of your customer, a provision the NCSC mentions itself.

You can also expect arrangements on continuity, handover at termination and termination after a serious incident. Read such an annex as an extension of the questionnaire, because everything you commit to, you must be able to show later. A wider period you demonstrably meet generally counts for more than a tight one you miss. Also check whether a requirement is worded as an obligation of result ("you prevent") or as an obligation of effort ("you make every effort"), and what it says about liability. If you do not yet meet a requirement, offer an improvement plan with a timeline.

What happens if you do not cooperate?

The fines under the Cyberbeveiligingswet apply only to your customer. If you do not fall under the act yourself, NIS2 imposes no obligation on you. If cooperation with a supplier assessment is part of your contract or your service level agreement (SLA), not completing it is a contractual matter. Commercially it always counts. A customer that receives vague answers cannot assess your risk and will probably rate it higher, with consequences in a tender or at contract renewal. At equal price and quality, being able to show your risk can tip the balance.

In depth: rules that may apply to you directly

Apart from NIS2, other rules may affect you directly. As a processor of personal data, the GDPR requires appropriate security and arrangements with your customer (Articles 28 and 32). DORA, the European rules on digital operational resilience in the financial sector, comes into play if you provide ICT services to banks, insurers or investment firms. Direct supervision there applies only to designated critical providers; the rest runs through mandatory contract clauses. The Cyber Resilience Act applies if you make products with software in them, such as apps, devices or software you sell. Its reporting obligations have applied since 11 September 2026, the other requirements apply from 11 December 2027. Services that run only online (SaaS) generally fall outside it.

How do you demonstrate your basic security as a supplier?

A questionnaire is paper: a snapshot and a promise, written by you. An external measurement shows what is visible from outside your environment on a fixed date: entry points to your systems that are reachable from the internet (open ports), software versions, your website's security certificate, the security of your domain and your email, reachable admin login pages. A measurement has limits too. It sees only what is reachable from outside, does not look behind login screens and does not replace a pentest. A report without findings therefore says something about your external attack surface on that day. You decide yourself which domains and systems are measured (the scope), and the seal only proves that the report has not been changed afterwards. To show whether MFA is on for everyone, whether your backups work and how you update internally, you need other documents, such as a screenshot of the sign-in settings in Microsoft 365 or Google Workspace, or a log. If an external provider manages your IT, ask it for those documents.

The effort scales with the risk. If you are a supplier without access to customer systems or customer data, a current overview of your external attack surface and a fixed rhythm of remediation is often enough; ask your customer whether that is enough for it. A certification programme only comes into view at a higher risk profile.

Map what you expose to the internet

Start with what an attacker sees of your domain, because your customer's assessor can look at that too without asking you anything. Typical findings in a first external measurement are a forgotten test environment on a subdomain, an expired or nearly expired security certificate, email without a DMARC policy (the setting that stops others from sending email on behalf of your domain) and an outdated website system or admin panel. Such points rarely appear in the questionnaire you just completed, while an outsider can see them at first glance. For the domain of your business email address you can check your email security and your website's certificate yourself with the free DMARC check and SSL check.

Monitor continuously, because one report proves one day

New vulnerabilities appear daily and colleagues put new services online. A series of monthly reports shows your process: what was open in September and no longer in October, with your remediation date alongside. If a questionnaire with a deadline is on your desk, have an interim report made on the current state.

Fix what you find and record what you did

Keep a record, per finding, of what you decided: remediated, mitigated or consciously accepted with a reason. A finding with such a decision is normal to an assessor. A finding that is still open in the next report without explanation calls for an explanation. The law itself names no remediation period. Public guidance gives you something to hold on to. The UK certification scheme Cyber Essentials requires participants to install updates for critical and high-risk vulnerabilities within 14 days of release. Since June 2026 the US government has required its federal agencies to remediate publicly reachable systems with a vulnerability on the list of known exploited vulnerabilities (KEV) generally within three days. In a questionnaire, only quote a period that your own reports and records can back up.

In depth: how to demonstrate a remediation period

The US directive BOD 26-04 (10 June 2026) works with four questions: is the system publicly reachable, is the vulnerability on the KEV list, can exploitation be automated, and how much control does an attacker gain? These lead to periods of 3, 14 or 60 days, or remediation at the next upgrade. The full table applies from December 2026. How to use EPSS (a score for the likelihood that a vulnerability will be exploited) and KEV to decide what comes first is covered in which vulnerability first.

Your measured remediation period runs from the report in which a vulnerability first appears to the first report in which it has gone. With monthly reports you prove "within a month", counted from the report in which it first appeared. To demonstrate 14 days you need an interim report, or the remediation date from your own records alongside it. A finding also disappears when a system was offline or fell outside the measurement. So record the remediation date yourself. An assessor can then put three things side by side: the period you quote in the questionnaire, the measured period from the series of reports and the date on the report itself. If the measured period deviates from what you stated, your own declaration becomes the weak point. What auditors and insurers mean by verifiable evidence is set out in forensically substantiated evidence.

A scan does not make anyone "NIS2-compliant", by the way. The law also asks your customer for risk management, incident reporting and board accountability. That distinction is set out in scanning is not NIS2 compliance.

How Exposentry fits in

With a subscription, Exposentry does the measurement and the monthly reporting, so that you can focus on remediation; a Baseline scan gives a one-off picture. The measurement comes from OpenKAT, the open-source security scanner developed within the Dutch government, to which founder Edward Hasekamp contributes. The servers of your domain and email provider, which come into view through your domain settings, are set apart in the report as "out of scope". Per type of finding the report states, where known, which scan module detected it and when. The report is sealed with Exposentry's own certificate and a timestamp from an independent service, so that your customer can verify that it has not been changed since. You request an interim report yourself from your dashboard. What to include with such a report for your customer's NIS2 questionnaire is described on that page. The free scan, based on public sources, gives a first picture of what you expose to the internet.

Frequently asked questions

Do I fall under NIS2 myself as a supplier? Only if your own organisation operates in one of the designated sectors and is large enough: generally from 50 employees, or an annual turnover and balance sheet total both above €10 million. A few digital services are covered regardless of size. If you provide IT management, IT security services, cloud services or data centre space yourself, you fall under it yourself from medium size (generally 50 employees). If you supply organisations that do fall under it, NIS2 reaches you indirectly, through the requirements your customer sets for you under its supply-chain duty of care. In doubt about your own position? Take the NIS2 self-check.

What requirements may my NIS2 customer impose on me? Requirements that are appropriate and proportionate to the risk your service poses to that customer. A supplier that hosts core systems or has access to customer data faces heavier requirements than a supplier of office furniture. A customer may ask how you keep your systems up to date, whether you use MFA and within what period you report incidents to it, and may ask for evidence.

Do I need a NIS2 certificate? No. There is no official NIS2 certificate and the law currently prescribes no specific standard or quality mark. Quality marks with NIS2 in the name have no legal status. The NCSC does mention the NIS2 Supply Chain quality mark and the Cyra assessment method as aids on the way to ISO 27001. If your customer requires one, that is a contractual requirement. An ISO 27001 certificate helps in answering questions and says something about your management system; what you expose to the internet today is shown by a measurement.

What happens if I do not complete my customer's questionnaire? Fines under NIS2 apply to your customer. If cooperation is part of your contract or SLA, not completing it is a contractual matter. And commercially it always counts: a customer that receives no or vague answers cannot assess your risk and will probably weigh that at contract renewal or in a tender.

Do I have to check my own suppliers too? Your customer may ask through the contract for insight into your suppliers, even though the law itself imposes nothing on you there. Keep a list of who hosts your environment, who manages your email and who has access to that customer's data, with what you know about their security.

How do I demonstrate NIS2 compliance as a supplier? NIS2 compliance is something your customer has to demonstrate, because the law applies to it. You show that you are a managed risk for it: with a current picture of what you expose to the internet, dated evidence of remediation, and a clear answer to its questionnaire and contract annex.

What counts as sufficient evidence for my customer? A completed questionnaire is a self-declaration. More convincing is a dated external measurement of your domains and systems, with your remediation status of what it found. That shows what an outsider saw of you at that moment and what you did about it.

Written by Edward Hasekamp, founder of Exposentry and collaborator on the open-source OpenKAT project. See the project on GitHub and the profile at github.com/hasecon. Exposentry provides EU-sovereign, forensically substantiated vulnerability monitoring based on OpenKAT. More articles in the Knowledge base.