The Cyberbeveiligingswet Duty of Care Lands on the Board — and a Scanner Can’t Evidence It

The Cyberbeveiligingswet — the Dutch implementation of NIS2 — takes effect on 15 August 2026. Most of the coverage has been about that date. The date was never the hard part. The hard part is what the law puts on the board: a personal, non-delegable duty of care that a vulnerability scanner cannot evidence.

For the timeline, scope, and NCSC registration obligation, see the Cyberbeveiligingswet enters into force on 15 August 2026. This piece is about the obligation underneath it — the one directors underestimate.

Key takeaways

• The Cyberbeveiligingswet’s central change is a board-level duty of care: directors must approve security measures, oversee their implementation, and complete a training obligation — and can be barred for structural neglect.
• Duty of care is not a state you pass on an audit date. It is a state you maintain continuously — a much harder bar to fake and an easier one to quietly fall out of.
• “I did not understand the technical detail” stops being a defence once the training obligation applies.
• Vulnerability scanners (SAST, DAST, SBOM) prove which code and container flaws exist, but they do not evidence whether the architecture meets a duty-of-care standard.
• The evidence a newly accountable director actually needs is structured, current proof that architectural risk was assessed and governed — not a scan result.

What the duty of care actually puts on the board

The Cyberbeveiligingswet does something the old Wbni did not. It puts the duty of care on the board itself. Directors have to approve the security measures and oversee their implementation. There is a training obligation, so “I did not understand the technical detail” stops being a defence. And the supervisor will be able to bar a director who structurally neglected it.

This is a personal, non-delegable accountability. You can hand the implementation to a platform team; you cannot hand off the answerability. That is the shift most boards have not fully absorbed — they are treating a continuous obligation as a project with an end date.

You cannot oversee what you cannot see. You cannot evidence what was never documented.

This is where most Azure environments are exposed — and it is not where the scanners point.

Why a duty of care is a state you maintain, not a date you pass

Duty of care does not ask “were you compliant on the day of the audit.” It asks “were you exercising reasonable care continuously.” That is a much harder bar to fake and a much easier one to quietly fall out of.

You can be in good shape in March and out of care by September without a single decision that felt like a mistake — just an estate that drifted while the board assumed the readiness project had handled it. A storage account opened “just for a test” that became infrastructure. A service principal that kept its permissions after the migration ended. None of it looks like negligence in the moment. All of it is the kind of drift a duty-of-care standard is designed to catch.

For a director, the uncomfortable reframe is that signing off the readiness programme is not the finish line. It is the start of an obligation that does not have one.

Why vulnerability scanners aren’t enough

A SAST, DAST, and SBOM stack tells you which vulnerabilities exist in your code and your containers. You need that. It is part of Article 21. But it is not architectural evidence. It does not tell a board whether the system design — the segmentation, the resilience model, the third-party concentration risk, the recovery objectives — meets a duty-of-care standard. It does not produce the thing an auditor, or a newly accountable director, will actually ask for: structured, current evidence that architectural risk was assessed and governed.

Configuration is not evidence. A vulnerability report is not architecture.

The 15 August date is not a reprieve. It is the last quarter in which preparation costs less than remediation.

FAQ

What is the board-level duty of care under the Cyberbeveiligingswet?

The Cyberbeveiligingswet places the duty of care on the board itself. Directors must approve the organisation’s security measures and oversee their implementation, complete a training obligation, and can be barred by the supervisor if they structurally neglect it. It is a personal, non-delegable accountability the old Wbni did not impose.

Why aren’t vulnerability scanners enough for NIS2?

A SAST, DAST, and SBOM stack tells you which vulnerabilities exist in code and containers — necessary, and part of Article 21 — but it is not architectural evidence. It does not show whether the system design (segmentation, resilience, third-party concentration, recovery objectives) meets a duty-of-care standard, which is what a board or auditor will ask for.

What should directors do before 15 August 2026?

Treat the date as the last low-cost preparation window, not a reprieve. Produce structured, current evidence that architectural risk has been assessed and governed — segmentation, resilience model, third-party concentration, recovery objectives — so the board can demonstrate oversight. A vulnerability scan won’t satisfy that; an architecture assessment mapped to NIS2 will.

One honest question for the directors reading this: if you had to demonstrate, this quarter, that your Azure architecture meets a duty-of-care standard — could you put that evidence in front of the board? Not a scan. The architecture.

(This is the gap Platform Architecture Authority was built to close — a full Well-Architected assessment of your Azure environment, mapped to NIS2 and produced as audit-ready evidence, in hours. Link in the comments if the evidence template is useful. The question above holds whether or not you ever run it.)