From 15 August 2026, the Dutch Cyberbeveiligingswet (Cbw) is in force. It transposes the EU NIS2 Directive, brings roughly 8,000 organisations across eighteen sectors into scope, and does something a registration deadline can obscure: it makes the board accountable for managing cyber risk, not merely for signing up. Registration proves you exist in the register. It does not prove you understand the risk you are now answerable for.
A controls checklist, on its own, leaves that gap open. The clearest recent evidence is a United States criminal case: prosecutors allege that a member of the group Scattered Spider compromised a multibillion-dollar retailer without defeating any of its controls, by routing the attack through the company’s own people, roles and reset processes. The input NIS2 does not ask for, and that the case suggests decides the outcome, is an outside-in map of what an attacker can already see about your organisation, its staff and its suppliers.
What the Cbw actually requires
Two laws cleared the Eerste Kamer together on 7 July 2026, and both take effect on 15 August 2026. The Cbw transposes NIS2 and carries the cyber-risk duties. The Wet weerbaarheid kritieke entiteiten (Wwke) transposes the separate CER Directive on the physical resilience of critical entities and covers about 500 of them. They are named in the same breath but are different instruments; this piece is about the Cbw, because that is the one boards will have to reason about.
Under the Cbw, an in-scope organisation must register in the national entity register through the NCSC, meet a duty of care (zorgplicht) to manage the risks to its network and information systems, report significant incidents within statutory deadlines (meldplicht), and place final accountability for cyber-risk management with the board (bestuurlijke verantwoordelijkheid). Regulators supervise all of it. What the law does not spell out is what an organisation is expected to know about its own risk, which is where the evidence from the United States becomes useful.
Why controls alone don’t answer the Cbw risk question
The case that makes the point concrete is the FBI’s superseding criminal complaint against an alleged Scattered Spider member (also tracked as Octo Tempest and UNC3944). In May 2025, according to the affidavit, a multibillion-dollar luxury retailer lost control of its network in about two to three hours. The attackers did not break its multi-factor authentication. Prosecutors allege they made phishing calls to its IT help desk, posed as the company’s own employees, and asked for the passwords and MFA devices to be reset; three accounts fell in that window, two of them belonging to IT administrators. The ransom demand was around eight million dollars, and the alleged member facing charges is nineteen years old. The affidavit describes an earlier intrusion by the same group that began when an attacker “obtained a business partner’s credentials and, using social engineering,” had an employee’s two-factor authentication reset: a supplier relationship as the way in.
Scattered Spider’s method is documented well beyond this one case. A US CISA advisory and prior convictions describe the same help-desk-and-impersonation pattern in other intrusions. What the complaint adds is a sworn, itemised account of it working against a large, presumably well-resourced target. Every control was present. The attack went around them, through the people who operate them.
A control framework describes what you have installed. It does not describe what an attacker can already see about the people who run those controls.
What most organisations will do first
The first response to a compliance deadline is procedural, and reasonably so. Over the coming weeks in-scope Dutch organisations will register with the NCSC and confirm whether they count as an essential or important entity, assign an internal owner, update their incident-response and reporting process to hit the statutory windows, brief the board, and refresh policies, access controls and awareness training.
None of this is wrong. All of it is necessary. But it is the part every NIS2 checklist already covers, and the retailer in the affidavit almost certainly had most of it in place. It had MFA. It had a help desk with a reset process. It still lost administrator accounts in an afternoon.
The three maps a board needs
A NIS2 programme, done well, produces two pictures of the organisation. The Cbw, and the checklists written around it, ask for a third that the law never names.
The Compliance Map: what you have declared. Registration in the entity register, incident-reporting routes, governance, policies, the board briefing. It proves the obligations are addressed on paper.
The Control Map: what you have protected. The systems, accounts, MFA, backups and vendor register behind those policies: the technical and operational reality the compliance map refers to.
The Exposure Map: what you have revealed. What an attacker can infer before touching anything you own: staff roles and the language of your help desk, credentials already circulating in breach and stealer-log markets, supplier relationships, executive detail, the tools named in your job postings, and the domains you have forgotten.
Most NIS2 programmes build the first two carefully and never draw the third. The intrusion in the affidavit happened entirely on the third: it turned on knowing which people to impersonate, which help-desk request would sound routine, and which supplier relationship could be used as a path in. That is external exposure, and a control-maturity review does not surface it. This is what an exposure map covers, and why each item matters under the Cbw:
| Exposure | Why it matters under the Cbw |
|---|---|
| Staff profiles on LinkedIn and similar | Names roles and reporting lines: the raw material for a convincing help-desk impersonation |
| Leaked credentials and stealer-log entries | Turns one person’s personal compromise into a working path into corporate systems |
| Publicly visible vendor and partner relationships | A supplier or business partner becomes the way in, as it did in the affidavit’s earlier intrusion |
| Job postings that name specific tools | Reveals the stack, the versions and the likely attack paths |
| Executive exposure (home, family, contact) | Enables pressure, impersonation and the joining of digital risk to physical risk |
| Forgotten domains and dormant accounts | Creates unmanaged access paths nobody is watching |
| Consultant and third-party visibility | Extends the attackable surface beyond the assets you own and control |
None of these are findings your firewall produces. They sit outside the perimeter, in public, legible to anyone who looks. The board question that follows is therefore not only whether the organisation is NIS2 ready. It is whether someone outside it could assemble enough context to make the organisation’s own controls behave against it.
If your NIS2 programme has a compliance map and a control map but no exposure map, that is the gap a board is now accountable for. A Corporate Audit draws the third one.
Talk to an AnalystBoard responsibility means being able to explain the risk
The Cbw does not ask directors to become technical analysts. It asks them to understand, approve and oversee the management of cyber risk, and it makes that accountability personal and final. That is a governance duty rather than an engineering one.
But a board cannot oversee a risk it has never seen mapped. It is straightforward to approve a policy. It is harder, and more to the point, to say what external exposure that policy is supposed to reduce, and whether it is actually reducing it. When the Odido breach put the personal data of Dutch government ministers into a criminal dataset, it made the point at the level of the state: exposure does not respect seniority, and the people most worth impersonating are usually the most exposed.
The question a supervisor, an insurer or an incident review will eventually ask is not whether the board can recite the policy. It is whether the organisation can show what it knew about its own exposure, and when. An approved policy with no underlying picture of the attack surface is a decision made without the evidence it was supposed to rest on.
A recurring review, before and after 15 August
The date is a threshold, not the work. Exposure changes every time you hire, publish a job post, onboard a supplier or suffer a breach elsewhere, so it works best as a standing review, refreshed as those things happen. The same short set of checks works before the deadline as preparation and after it as evidence of the duty being met:
- Map what is public. Which of our entities, domains and accounts are visible and reachable from outside?
- Check the credentials. Have we looked for our corporate credentials in breach and stealer-log markets, not just assumed MFA covers it?
- See the supply chain from outside. Can an attacker identify our vendors and partners and use one as a way in?
- Weigh the people. Are our executives, and our finance, HR and IT staff, overexposed relative to their privilege?
- Close the tell-tales. Do our public job postings leak stack and tooling detail?
- Test the help-desk assumption. Would our reset process survive a caller who already knows the names, roles and language of the person they are impersonating?
- Sequence it right. Is exposure reviewed before we design phishing simulations and awareness campaigns, so those campaigns test the real attack surface rather than a generic one?
Before 15 August, this is preparation. After 15 August, it is the record of a duty you are now accountable for.
Where a Corporate Audit fits
To be precise about the boundary: a Corporate Audit does not replace NIS2 legal compliance, an ISO control programme or an incident-response capability, and it is not a legal assessment of whether an organisation meets the Cbw. Those stay with the organisation, its advisers and its regulators.
What it does is answer the reconnaissance question the checklist leaves open: what can an attacker already infer about your organisation, your people and your suppliers from outside, before a single control is tested? It draws the third map, the Exposure Map, that the zorgplicht assumes exists and that a board needs in order to oversee the risk it is now personally accountable for. A board cannot govern only the system it owns; it also has to understand the version of the organisation that exists outside its perimeter. In the affidavit, the whole intrusion depended on information the attacker could assemble before making a single phone call. That is the information a Corporate Audit surfaces first.
The Cbw makes the board accountable for a risk most organisations have never mapped from the attacker’s side. A Corporate Audit produces that map before it becomes the incident you have to report.
Talk to an AnalystCommon questions
When does the Dutch Cyberbeveiligingswet take effect?
The Cyberbeveiligingswet (Cbw) and the Wet weerbaarheid kritieke entiteiten (Wwke) both take effect on 15 August 2026, after the Eerste Kamer approved the two laws together on 7 July 2026. From that date, organisations in scope of the Cbw must be registered and meet its duty of care, incident-reporting and board-accountability obligations.
Does the Cbw apply to my organisation?
The Cbw brings roughly 8,000 Dutch organisations across eighteen sectors into scope, and each must determine through the NCSC whether it counts as an essential or important entity and register accordingly. Whether a specific organisation qualifies is a legal determination for the organisation and its advisers; this article is analysis, not legal advice.
Is the Wwke the same as NIS2?
No. The Cbw transposes the EU NIS2 Directive and carries the cyber-risk duties. The Wet weerbaarheid kritieke entiteiten (Wwke) transposes the separate CER Directive on the physical and organisational resilience of critical entities. They took effect on the same day but are different instruments.
Does a Corporate Audit make us NIS2 compliant?
No. A Corporate Audit does not replace legal compliance, an ISO control programme or incident response, and it is not a legal assessment of the Cbw. It maps the external exposure an attacker can see before any control is tested, so a board can oversee that part of the risk. Compliance itself stays with the organisation and its advisers.
Sources
- Federal Bureau of Investigation, superseding criminal complaint and affidavit, United States v. Stokes, U.S. District Court, Northern District of Illinois (April 2026). Help-desk social engineering, MFA-reset account takeover, and the business-partner-credential intrusion attributed to Scattered Spider / Octo Tempest / UNC3944. justice.gov.
- Cybersecurity and Infrastructure Security Agency (CISA), advisory AA23-320A, Scattered Spider. Corroborates the help-desk impersonation and social-engineering pattern. cisa.gov.
- Nationaal Cyber Security Centrum (NCSC), “Cbw en Wwke vanaf 15 augustus 2026 van kracht” (7 July 2026). Eerste Kamer approval, effective date, scope (~8,000 Cbw / ~500 Wwke) and duties. ncsc.nl.