A questionnaire on multifactor authentication, incident notification, backups or suppliers can unexpectedly land on your desk. The customer says this is because of NIS2 or the Dutch Cybersecurity Act, while your organisation itself is not within the legal scope. Both can be true at the same time.
Why your customer asks about your security
The Dutch Cybersecurity Act entered into force on 15 August 2026. Organisations within the scope of application should take appropriate and proportionate measures for their network and information systems. This includes supply chain security.
If your product, link, management account, software or service affects a critical process of the customer, a relevant chain risk arises. The customer therefore wants to know how to protect access, report incidents, treat vulnerabilities and organise continuity.
Ask what chain risk your customer wants to control, make appropriate agreements and provide proof that fits your product or service. Do not assume without analysis that the entire Dutch Cybersecurity Act applies directly to your organisation.
You don't automatically become a Cbw entity by delivering to a customer
Whether your organisation is directly covered by the Dutch Cybersecurity Act depends on the legal criteria, including activities, sector, size and possible designation. Delivering only to an organisation that is governed by the law does not automatically make you an essential or important entity.
The NCSC explicitly warns against the wrong assumption that the NIS2 rules apply in full to all suppliers. However, the customer may contractually impose security requirements to control his own chain risks. Therefore, investigate your own scope and treat customer requirements as a separate commercial and risk-driven demand.
Which suppliers are likely to get questions?
Not every supplier presents the same risk. A supplier office items usually has a different influence than an IT manager with management rights, a SaaS platform with personal data or a logistics link that controls a critical process.
Customers will focus on access, data, availability, replacementability and the possibility that an incident will affect your own systems or services.
- IT service providers, cloud and software providers
- Parties with management rights or network access
- suppliers of critical applications and links
- processors of sensitive or business-critical data
- maintenance lots for OT, machinery and operational technology
- logistics and other partners supporting critical processes
What requirements can a customer make?
The requirements should be appropriate to the service and the risk. A standard questionnaire can serve as a starting point, but discuss which parts are really relevant. A small supplier without customer access does not automatically have to provide the same proof as a managed service provider with management rights.
- risk analysis and basic information security policy
- multifactor authentication, access management and secure configuration
- patching and monitoring of vulnerabilities
- Logging, detection and incident response
- reporting periods and information in case of chain incident
- backup, repair tests and continuity arrangements
- security of development, links and changes
- understanding critical subcontractors and own suppliers
- audit right, reports, certificates or other evidence
What's the use of evidence?
A policy document shows what has been agreed; It doesn't prove the measure works yet. Combine policies with registrations, configuration overviews, test results, incident exercises, recovery reports and follow-up of anomalies.
ISO 27001, CYRA or other frameworks can help to structure questions. The NCSC stresses that the Dutch Cybersecurity Act does not provide for a single specific framework of standards for suppliers. So discuss what proof your customer needs and avoid costly duplications when multiple customers send different lists.
Read NIS2 clauses as concrete risk arrangements
Note that wordings that lay down the full law or all obligations without demarcation with the supplier. Ask which service, data, systems and incidents are included in the appointment. Also capture what "unrelenting" or "timely" means in hours and information.
Check that audit rights, liability, costs, subcontractors and termination are proportionate to the product delivered and the fee. Have legal agreements linked to what is technically and organizationally feasible.
- scope of service and relevant systems
- minimum measures and responsibility per party
- reporting criteria, deadlines and contact points
- evidence, periodic evaluation and follow-up
- subcontractors and changes in the chain
- support for research, recovery and reporting
- auditing, confidentiality, costs and liability
This is how you respond to a comprehensive customer questionnaire
Point out one coordinator and answer questions from a central evidence file. Mark as appropriate, as not applicable and which improvement is planned. Avoid unproven 'yes' responses; they can later become part of contractual expectations.
Ask the customer for priority and context when requirements appear unclear or disproportionate. A conversation about chain risk often results in more than endless correspondence about generic formulations.
Don't forget your own chain
If your service depends on hosting, software components, subcontractors or external administrators, those parties may also influence the customer. Map the direct suppliers and determine which dependencies are critical.
Record how you receive incident information, what recovery arrangements apply and whether you can meet the customer when a subcontractor fails. Promises to the customer must be carried through the chain behind them.
Make demonstrable resilience commercially usable
Well prepared suppliers respond to queries faster and do not need to re-collect evidence for every customer. A compact overview of measures, responsibilities, incident routes and test results can reduce uncertainty in procurement.
Just promise what you can do. Transparency about an improvement point is often more credible than a broad statement that everything is in order.
Practical roadmap for suppliers
Use the customer demand to improve your own resilience and evidence in a targeted way.
- Judge separately whether your organisation is itself covered by the Dutch Cybersecurity Act.
- Determine which customers, services, data and links are chain critical.
- Ask what specific risks and legal obligations the customer wants to control.
- Make a basic inventory of measures, gaps, owners and evidence.
- Prioritize access, vulnerabilities, incident reporting, recovery and proprietary suppliers.
- Answers to questions in central and factual terms, including non-applicable parts.
- Have contract requirements legally, technically and operationally linked.
- Plan periodic evaluation and update evidence after changes and exercises.
Sources and deepening
Based on official frameworks and practical implementation
The source pages provide the formal background. Kynexis Information Security translates this information into an executable approach for your organisation, sector and risk profile.
