The Cyberbeveiligingswet has applied since 15 August 2026 to more than 8,000 Dutch organisations. It places a supply-chain duty on you, not on your AI supplier: the NCSC states plainly that a supervisor will not supervise suppliers. Your ICT partner may well be in scope in its own right. Your specialist AI supplier almost certainly is not. Those three positions need three different instruments, and one standard questionnaire serves none of them.
Who falls under the Cyberbeveiligingswet, and who decides?
The law entered into force on 15 August 2026, alongside the Wet weerbaarheid kritieke entiteiten. Scope turns on two tests, and skipping the first is the common error. Your sector comes first: the Cbw binds roughly 8,000 organisations across the eighteen sectors named in its annexes, so a large Dutch company in an unlisted sector is not in scope at all, and most firms in this size band are not. Our API integration page carries that recital in full. Only then does size apply: 50 or more employees in fte, or fewer than 50 but with both annual turnover and balance-sheet total above 10 million euro. Partner and linked enterprises count toward all three figures, so a shared-services entity inside a group is often in scope while the operating companies around it argue about who owns the answer. The NCSC publishes both tests and the RDI self-assessment returns the classification.
Two things follow for an IT organisation between 250 and 5,000 FTE that clears both tests. First, registration in the entiteitenregister has been mandatory since the same date, runs through Mijn.NCSC.nl, and has to be kept current: a merger or a change in your IP ranges has to be passed on within two weeks, and failing to register can bring a fine or an order subject to penalty payments. Second, your classification matters more than the obligations list. Essential entities face proactive supervision, where an inspector can act without an incident having happened. Important entities are generally looked at afterwards. The fine ceilings follow the same split, at the levels the NIS2 directive sets: 10 million euro or 2 percent of worldwide turnover against 7 million euro or 1.4 percent.
Supervision is also not centralised. The NCSC's own table splits the sectors across the RDI, the ILT, De Nederlandsche Bank, the AFM and further sectoral inspectorates, and the FAQ below gives the mapping. If you run a multi-site estate across two listed sectors, the practical question is which body will one day read your AI documentation, and it is rarely the one your security team already has a relationship with.
Is your AI supplier in scope at all?
Here the three parties separate, more sharply than most procurement packs assume. You, the deployer, are in scope, registered, and on the reporting clock. Your ICT partner is a different case: beheer van ICT-diensten is itself a Cbw sector, and the RDI publishes quickscan results for that sector. If your managed service or managed security provider clears the same size test, it carries its own duty of care, its own registration and its own reporting obligation, entirely independent of your contract with it.
Your specialist AI supplier, in the ordinary case, is in scope for nothing. A firm that designs, builds and hands over an AI system is not managing your network and information systems, which is what places a provider in that sector. And the entity types the Cbw reaches regardless of size are a short, closed list: DNS service providers, providers of public electronic communications networks and services, trust service providers, top-level domain registries and government organisations. Managed service providers are not on that size-independent list, and an AI specialist is not remotely near it. A small AI supplier is out on the size test; a large one is out on the sector test.
The NCSC says the rest out loud. Its supplier page states that a supervisor will not supervise suppliers, and will not fine one for lacking a certificate. We are not the first here, and it would be dishonest to imply it. Privacy in Bedrijf has already mapped these same positions under Dutch law, down to the conclusion that what remains is the contract, and our own piece on the Belgian route under CyFun makes the structural point about direct suppliers. What we have not found set down anywhere is what the gap looks like for an AI system in particular: which events have to be named, and why your ICT partner's own statutory report is of no use to you at all.
What does the chain duty actually require of you?
The duty of care in article 21 asks for appropriate and proportionate technical, operational and organisational measures, and names securing the supply chain among the areas those measures have to cover. The NCSC renders the supplier test as your direct suppliers' and service providers' specific vulnerabilities and the general quality of their cybersecurity practices, including their secure-development procedures. Three words carry the weight. Direct, because the duty stops at the party you contract with, so the model provider behind your supplier's API sits outside it unless you contract with them too. Proportionate, and the NCSC's own illustration is a physical access pass that suits a server room but not a provider of digital price information. And assess, because what you owe is an assessment, not a certificate.
That last word is where AI procurement most often goes wrong. The standard NIS2 supplier questionnaire demands ISO 27001 or an equivalent framework, and the NCSC states that the Cbw prescribes no framework at all, naming ISO 27001 and sector schemes specifically. Send that pack to a fifteen-person AI specialist and you get one of two outcomes: a truthful no, which your own process then records as a finding, or a box tick that tells you nothing about the system being built. Meanwhile the party that does carry a statutory duty, your ICT partner, receives the same generic list. You have over-asked the supplier the law ignores and under-asked the one it regulates.
There is a quieter reason the generic pack underperforms. The NCSC notes that a supplier serving several Cbw organisations receives different lists of measures from each of them. Your questionnaire joins a queue, and the more generic it is the lower it sits in that queue. What the NCSC does recommend is recording the agreements in an SLA or a DAP, in measurable and unambiguous terms, covering service description, duration, ownership, risks and security. That is a drafting job, not an audit job. If you are also being asked to certify an AI management system, or to settle whether the system is high-risk at all, map the overlap with what you already run before buying a second one: we did that clause by clause for ISO 42001, and our AI Act risk checker settles the classification question.
Why does the 24-hour clock break on an AI supplier?
This is the part that survives contact with a real incident. Your early warning is due no later than 24 hours after you become aware of a significant incident, the fuller notification at 72 hours, and a final report within one month of the first report, to both your sectoral CSIRT and your supervisor. Entities also subject to DORA or the electricity Netcode have four hours instead of 24. Trust service providers have 24 hours in place of the 72. Whether an incident is significant is set in sector-specific ministerial regulations rather than in the law itself.
Every one of those deadlines runs from your awareness. Your AI supplier has no statutory clock, no CSIRT relationship and no supervisor. If a retrieval pipeline starts returning documents across tenant boundaries, the party that notices first is ordinarily the party with no legal duty to tell you quickly, and every hour between their noticing and your awareness is subtracted from your 24. We have argued before that an AI incident needs a named owner before 02:00. The Cbw converts that from good practice into a deadline with a fine attached to it.
Note the asymmetry with your ICT partner once more, because false comfort is easy to take here. If it is in scope, it does have its own 24-hour obligation. But that obligation runs on its own awareness, to its own supervisor, about its own services. It is a report to the state, not a notification to you.
Which clauses actually close the gap?
Four clauses do more work than any framework demand. One: a notification window shorter than your own, counted from the supplier's awareness rather than yours, with a named channel that is not a shared mailbox. Two, and this is the one that is actually specific to AI: a definition of what counts, because significant is defined for your sector and not for your system, so you name the events yourself. Unexpected cross-tenant retrieval. A prompt-injection path that reaches a write action. A silent model version change, which alters production behaviour with no release and no RFC, and we have set out which such changes belong in a CAB and which would drown it. An index rebuilt against the wrong source. None of those four events appears in a standard security questionnaire, because none of them is a security control.
Three: assessment rights in place of certificate rights, meaning an architecture walkthrough, access to secure-development evidence, and the right to re-ask after a material change, all of which beat an annual certificate that was true in January. Four: the naming of the other two parties, so that who tells whom, and in which order, is settled while the ICT partner's platform and the AI supplier's application are both still working. Where the supplier is Belgian and a certificate is genuinely on the table, the equivalent list runs differently.
None of that is exotic drafting. It is the recognition that for this one supplier the contract is the only instrument you have, because the regulator is not going to hand you a second one.
How is this different in Belgium?
Different country, different instrument. A Flemish organisation works to the Belgian transposition and the CCB's CyFun framework rather than to the Cbw, the supervisor is the CCB rather than the RDI, and certification has a standing there that Dutch law pointedly declines to give any framework. We wrote that version separately. One supplier pack will not satisfy both regulators, and the Dutch assumption that no certificate is required is exactly the assumption that travels worst across the border.
What should IT do in the next thirty days?
Four things, in order. Establish your own classification and registration state first, because essential or important decides who may arrive unannounced. Then split your AI suppliers into those who run something for you and those who built something for you: the first may be in scope in its own right, the second is not, and only the second needs the contract route above. Read your existing AI contracts for a notification window, which in our experience is either absent or measured in business days. And take the chain question to your ICT partner as a peer question rather than as a questionnaire: what is in scope on your side, what do you report, and to whom.
Multi-supplier estates are the Dutch norm rather than the exception, and the seam between two suppliers is where a 24-hour clock gets lost. We work alongside your ICT partner rather than in place of it, which is precisely why we think the scope question is worth settling in writing now, before an incident settles it for you. Our view on what an AI implementation partner should carry sets out where that line sits, and applied AI for mid-sized organisations covers the governance side.
Last updated: 19 October 2026.
A consultant tells you where AI pays off; Crux Digits also builds it. A fixed price per step, one named expert, from Utrecht.
AI consultancy in the Netherlands →
