AI tools, shadow IT and your duty of care: the Dutch Cybersecurity Act has applied since 15 August

What took effect on 15 August

The Cyberbeveiligingswet (Cbw) replaces the Wet beveiliging netwerk- en informatiesystemen (Dutch Network and Information Systems Security Act) and implements the NIS2 Directive. At the same time, the Wet weerbaarheid kritieke entiteiten (Wwke) entered into force. It implements the European CER Directive and focuses on the physical and organisational resilience of around 500 organisations. That second Act works differently: an organisation only comes under it once the responsible minister has designated it as a critical entity, and only then do deadlines start to run, such as the nine months allowed after designation for its own risk assessment. The Cyberbeveiligingswet waits for nothing and no one.

The Cbw rests on four obligations. You register your organisation in the national entity register via MijnNCSC (the online portal of the NCSC, the Dutch National Cyber Security Centre). You meet a duty of care: a risk analysis and, on that basis, appropriate and proportionate measures to manage the risks to your network and information systems. You report significant incidents within statutory deadlines to your CSIRT and your supervisory authority. And the board approves those measures and oversees their implementation.

On one point the Act does allow a lead-in period. According to the RDI (Dutch Authority for Digital Infrastructure), board members must have the right knowledge and skills within two years of entry into force, so by mid-2028 at the latest. That leniency does not extend to the duty of care, the reporting obligation or the registration obligation. Any organisation that came under the Act on 15 August came under it in full that day.

Does the Act cover your organisation? Sector alone is not enough

The test consists of two steps, and the first is the better known. Your organisation must fall within one of the sectors in Annex 1 or Annex 2 to the Act. Annex 1 contains the sectors of high criticality: energy, transport, banking, financial market infrastructures, health, drinking water, waste water, digital infrastructure, ICT service management, public administration and space. Annex 2 contains the other critical sectors: postal and courier services, waste management, chemicals, food, manufacturing, digital providers and research. Eighteen in total.

The second step is size. According to the NCSC, you meet the size criterion if you have fifty or more employees, counted in FTE, or if you have fewer than fifty employees but both your annual turnover and your balance sheet total exceed €10 million. For a small number of services, such as trust service providers and top-level domain name registries, the Act applies regardless of size.

The step most often skipped sits between those two. The annexes name not only sectors but also, for each subsector, the types of entity that are covered. That is exactly where it becomes interesting for logistics and food, and where a quick conclusion can prove costly, in either direction.

Transport and food: where the line actually falls

The transport sector in Annex 1 breaks down into air, rail, water and road transport, each with its own entity types. For air transport these include air carriers and airport managing bodies; for rail transport, infrastructure managers and railway undertakings; and for water transport, passenger and freight water transport companies and the managing bodies of ports. For road transport, the Directive names road authorities and operators of intelligent transport systems.

That last point is why Transport en Logistiek Nederland (TLN, the Dutch transport and logistics trade association) explicitly warns its members against a hasty conclusion. In TLN's current dossier on the Cyberbeveiligingswet, the parties in transport and logistics that fall into the essential category are mainly air carriers, railway undertakings, inland shipping, coastal and maritime shipping and road authorities; according to TLN, road haulage companies and logistics service providers such as warehousing companies and freight forwarders are not among them. Traditional road haulage for hire or reward, warehousing and freight forwarding are therefore not automatically covered by the Act. They can, however, end up in the important category, and TLN names four routes into it: postal and courier services; waste management, including collection, transport and sorting; distribution of chemicals; and distribution of food. The size test applies there too. TLN adds the caveat that the government's self-assessment is not a good fit for logistics services, because many businesses are part of several supply chains. The supervisory authority for the transport sectors is the Inspectie Leefomgeving en Transport (Human Environment and Transport Inspectorate).

For food, the description is narrower than the sector name suggests. It covers food businesses as defined in Article 3, point (2), of Regulation (EC) No 178/2002 that are engaged in wholesale distribution and industrial production and processing. A production or processing site and a food wholesaler come under it if they are large enough; the supervisory authority is the NVWA (Netherlands Food and Consumer Product Safety Authority), which has set up a dedicated page for this.

That also answers the question for the third sector in which we work, a question that has too often been settled with an assumption. Primary production is not the same as industrial production and processing. A grower who cultivates and harvests crops and sells them through a marketing organisation is not engaged in wholesale distribution or industrial processing, and so does not come under the food sector by that route. As soon as the same business does sort, process or pack, or carries out wholesale distribution itself, the picture changes, and the size test then comes into play as well. So test this instead of assuming it: the Dutch central government provides the NIS2 self-assessment for the purpose, and the NCSC describes the test step by step. If you are covered, you register via MijnNCSC; that registration is your own responsibility and nobody will send you a letter about it.

Even if you are not covered, you will get the questions

There is a reason why this Act also matters to companies that fall just outside the test. One of the ten duty-of-care measures is securing the supply chain: entities covered by the Act must establish how secure their direct suppliers and service providers are and take that into account. They cannot pass that obligation on to you, but they do have to form a view.

TLN puts the consequence for the sector in matter-of-fact terms: tens of thousands of suppliers, including companies in transport and logistics, are facing new requirements through their large customers, and that makes cybersecurity a precondition for doing business. That is not a legal obligation but a commercial one. In practice it arrives as a questionnaire in a tender, a clause in a framework agreement or a customer audit.

For your preparation, that makes the distinction between being covered and not being covered less sharp than it seems. The question you will be asked either way is which systems and which suppliers affect your operations. And that is where the subject of this article begins.

Why your AI tools come into this

In the companies we work with, AI has long been in use, with or without permission. A planner has a customer email rewritten, QA summarises an audit report, a team leader builds a shift roster in a free assistant, someone connects a note-taking tool to the calendar. We wrote about this earlier in our piece on using ChatGPT and Copilot safely in the workplace, with the GDPR and the AI Act as the framework. The Cyberbeveiligingswet adds a third framework, and for the board it is the weightiest of the three.

That this is not a theoretical point is clear from a publication of 7 September 2026 by the UK National Cyber Security Centre on the hidden risks of shadow AI. The UK NCSC describes shadow AI as the use of AI technology that is not included in an organisation's approved systems and processes, and refers to research by Microsoft showing that 71 percent of the employees surveyed use AI tools their employer has not approved. That is a British figure from a single study and not a Dutch measurement; we include it here as an indication of scale, not as a benchmark for your organisation.

More important than the percentage are the three risks the UK NCSC identifies. Sensitive business or customer information can leak, resulting in loss of intellectual property and regulatory breaches. The organisation loses sight of its own information, because data that ends up in consumer services can be stored there or used to improve models, outside its own security and governance arrangements. And AI agents are software with vulnerabilities: anyone who compromises such an agent gains access to the same data, services and permissions as the agent itself.

The UK NCSC draws a conclusion from this that we share and that was already at the heart of our policy article: a ban does not work. As long as security policy does not match what employees need, they will keep acquiring new AI services. The aim is to reduce the risk, not to pretend it can be eliminated.

The ten duty-of-care measures, read with an AI tool in hand

The Cyberbeveiligingswet lays down ten duty-of-care measures that organisations must meet as a minimum. The Dutch NCSC summarises them as: carrying out a risk analysis, setting up incident response, preparing for outages, securing your supply chain, getting cyber hygiene in order, securing network and information systems, strengthening personnel, access and asset management, using passkeys for authentication, drawing up a cryptography policy and assessing the effectiveness of measures. The eighth of these is worded more sharply than the usual summary suggests: the NCSC recommends passkeys based on the FIDO2 standard instead of passwords, and multi-factor authentication wherever passwords are still needed. What exactly is appropriate is for you to determine on the basis of your risk analysis.

Set those ten against an AI tool that an employee started using on their own initiative last week, and the problem becomes visible. Not because AI is a separate category of risk, but because a tool nobody knows about appears in none of the ten measures:

• Risk analysis: a system that is out of sight cannot be weighed. The analysis you show your supervisory authority is then missing precisely the application that business data passes through.
• Personnel, access and asset management: asset management starts with knowing what you have. An account in an employee's name, paid for with a personal credit card, appears on no list and is not revoked when that employee leaves either.
• Supply chain security: an AI service is a supplier. Without a procurement route there is no data processing agreement, no assessment and no point of contact if something goes wrong.
• Passkeys and authentication: the NCSC asks for passkeys, and for multi-factor authentication where passwords are still in use, at least on accounts that can be reached from the internet. On a business account you can enforce that. On a personal account that happens to be used for work, you cannot.
• Cyber hygiene and training: this measure explicitly includes cybersecurity training. Employees who do not know what data is allowed where, and what is not, cannot make that judgement either.
• Incident response: if nobody knows a tool exists, nobody reports it when that tool does something wrong. And then the clock only starts running when it comes to light by some other route.

Twenty-four hours, and the clock starts as soon as you know

According to the NCSC, the reporting obligation has three steps. Within 24 hours you send an early warning, stating whether the incident is suspected to be malicious and whether there are cross-border effects. Within 72 hours the actual incident notification follows, with an initial assessment of severity and impact. And within one month of that notification comes the final report, with a description of the incident, the cause and the measures taken. Note what that month is tied to: your notification, not the moment you resolved the incident. Only if the incident is still ongoing after that month do you send a progress report at that point, and the final report then follows within one month after you have handled the incident. Your CSIRT or your supervisory authority can also ask for an intermediate report along the way.

Two details determine whether that timetable is achievable. First, the deadlines run from the moment you become aware of the incident, not from the moment the cause is clear. Second, you report in a single action via the MijnNCSC portal to both your sectoral CSIRT and your supervisory authority. When an incident counts as significant is set out not in the Act itself but in thresholds in ministerial regulations that differ by sector; you should therefore look these up for your own sector and not copy them from a general checklist.

Twenty-four hours is not long when the incident occurs in a system that is on your network diagram. It is unworkable when it occurs in a service whose existence the management team first hears of that morning. On top of that, a single event can trigger two reporting obligations at once: if a customer file ends up in a public chatbot, that may also be a personal data breach under the GDPR, with its own assessment and its own 72-hour deadline for notifying the Autoriteit Persoonsgegevens (Dutch Data Protection Authority). That does not mean two separate processes, but it does mean one procedure that provides for both routes.

The board cannot delegate this away

This is the point at which the Cyberbeveiligingswet goes further than most of the regulation that has come the way of logistics and food in recent years. The board must approve the measures the organisation takes to meet the duty of care, and must oversee their implementation. The NCTV (Dutch National Coordinator for Counterterrorism and Security) is explicit about this: even when the implementation of cybersecurity has been assigned to, for example, a CISO, the board remains responsible for its statutory duties. The RDI puts it in similar terms: the board bears ultimate responsibility for governance and risk management, even when tasks have been delegated.

This comes with a training obligation. All board members must take a training course on cybersecurity, with a certificate as proof, and must have the right knowledge and skills within two years of entry into force. That knowledge must then be kept demonstrably up to date. This ties in closely with an obligation you probably already know: since 2 February 2025, Article 4 of the EU AI Act has asked for AI literacy among everyone who works with AI systems in a professional capacity, and since 27 July 2026 it has done so in the form of supporting measures with no required level. Two laws, two legal bases, but in practice largely the same room and the same afternoon.

The penalties are to match. According to the NCTV, the rules provide for an administrative fine of up to €10 million or 2 percent of worldwide annual turnover for essential entities, and up to €7 million or 1.4 percent for important entities, whichever amount is higher. According to the RDI, the Cbw also makes it possible to impose a fine or an order subject to a penalty payment on individual directors. Supervision also differs by category: essential entities are supervised proactively, even without an incident, while important entities are looked at reactively, for example in response to signals or after an incident.

In boardroom terms: the question of which AI tools are running in your organisation is no longer an IT question that can be left with the system administrator. It is a question the board itself must be able to answer, and one it implicitly answers when it approves the measures.

What to do this month: from shadow to register

You do not need to set up a programme for this. Five steps can already be taken in September, and they build on one another.

• First establish whether you are covered by the Act, using the central government's NIS2 self-assessment and the sector description from your own supervisory authority, and if the answer is yes, register in the entity register. If you are not covered, the rest of this list is still worthwhile, because your customers are asking the same questions.
• Draw up an inventory of the AI tools actually in use. Ask department by department and without repercussions, because a list that people do not dare to add to is worthless. For each tool, note who uses it, what data goes into it, in whose name the account is held and who pays for it.
• Set that list against the ten duty-of-care measures and flag for each tool what is missing: whether it is in the risk analysis, in the asset register and on the supplier list, and whether the account has passkeys or at least multi-factor authentication.
• Translate the outcome into the ground rules with tool levels from our piece on ChatGPT and Copilot in the workplace, and make sure an approved alternative is ready for every use you want to restrict. Without an alternative, the use moves to personal phones.
• Do one dry run of the first 24 hours, with an AI scenario instead of a ransomware scenario. Who establishes that it is an incident, who assesses whether it is significant, who submits the notification via MijnNCSC, and who assesses at the same time whether there is also a personal data breach under the GDPR?

The human decides and signs, and here that is the board

At AIBA, our starting point is that the human decides and signs. On this subject, that human can be identified by name. The Act places the approval of the measures and the oversight of their implementation with the board, and leaves that responsibility there even when the implementation has been assigned elsewhere. A supplier can help you, a CISO can do the work, but the signature remains yours.

That also makes this subject a good reason to bring the separate obligations together instead of continuing to treat them in isolation. The inventory the duty of care asks of you is largely the same inventory that the classification and documentation of AI in operational processes requires. The training obligation for directors under the Cbw and the AI literacy obligation under the AI Act overlap in practice. And the agreements on data access that you record when buying machines and systems, which we wrote about in connection with the Data Act of 12 September, belong in the same supplier assessment that the duty of care requires of you.

So start with the list, not with the text of the Act. Once you have established which tools are running, what data passes through them and who signs for them, you have done most of the work, whether or not the supervisory authority ever calls.