Netherlands Software Supply Chain and AI Security Rules: A 90-Day Plan

Since 15 August 2026, Dutch organisations that provide essential or important services must register with the NCSC, manage the security risks of their network and information systems, including their software suppliers, and report significant incidents with a first warning within 24 hours. That is the Cyberbeveiligingswet (Cbw), the Dutch law that implements the EU NIS2 Directive, and it took effect on the same day as the Wet weerbaarheid kritieke entiteiten (Wwke). Banks, insurers and investment firms answer to DORA through DNB and the AFM, hospitals and care providers work to NEN 7510, government bodies must apply ISO/IEC 27001 and the BIO2, and anyone who sells software or connected products into the EU now has Cyber Resilience Act reporting duties.

This guide is for the CISO, AppSec and engineering leads, GRC, vendor risk and the privacy officer in a Dutch organisation, and for foreign software makers selling into the Netherlands. It covers each rule from its primary source as checked in late October 2026, what the rules ask of software, open source and AI, two recent incidents, and a 30/60/90-day plan that works with the tools you already have. This is not legal advice; read the texts with your counsel.

Key takeaways

• The Cbw and the Wwke apply from 15 August 2026. The Cbw replaces the Wbni and, per the government, covers more than 8,000 organisations in 18 sectors: register with the NCSC, meet the duty of care, report significant incidents.
• Reporting is phased: an early warning within 24 hours (four hours for DORA entities, per the NCSC), a notification within 72 hours and a final report within one month.
• Sector baselines are concrete. Essential government entities must apply ISO/IEC 27001:2023 and BIO2 v1.3; NEN 7510-1:2024 and NEN 7510-2:2024+A1:2026 apply in healthcare from 1 June 2026; financial firms follow DORA under DNB and the AFM.
• EU product and AI rules are live. CRA reporting applies from 11 September 2026 and SBOM duties from 11 December 2027. The AI Act applies from 2 August 2026, with high-risk rules moved to 2 December 2027 and 2 August 2028; the Dutch AI supervision bill is still a proposal.
• Safeguard capabilities covered (all GA): SBOM generation and analysis, software composition analysis, vulnerability management with EPSS and KEV, reachability analysis, policies and gates, autonomous remediation (ships switched off), TPRM, CSAF and VEX upload, the compliance and GRC suite with NIS2, DORA and NEN 7510 frameworks, Trust Center, AI-BOM discovery, Package Firewall, the CLI and local runner, on-prem and air-gapped deployment, and Zero AI mode.

Who this applies to in the Netherlands

The Netherlands is an EU member state, so EU regulations such as DORA, the Cyber Resilience Act and the AI Act apply directly, and EU directives such as NIS2 and the Critical Entities Resilience (CER) Directive apply through Dutch implementing laws. The table shows who is in scope and who supervises.

The rules, regulator by regulator

Every status below was checked on the primary source (the Staatscourant, the government's own pages, the regulator or the European Commission) in late October 2026.

Cyberbeveiligingswet (Cbw): in force since 15 August 2026

Status. The Eerste Kamer approved the Cyberbeveiligingswet on 7 July 2026, and the government announced that day that it would take effect on 15 August 2026. On 15 August 2026 the government confirmed that the Cbw and the Wwke apply from that date. The Cbw implements NIS2 and replaces the Wbni.

Scope. The Cbw applies to organisations that provide essential or important services in 18 sectors. The government's 7 July announcement put the number at more than 8,000 organisations. There is no letter from a regulator telling you that you are in scope; you must assess it yourself.

Duties. The government lists five headline duties:

1. Registration (registratieplicht). Register in the national entity register managed by the Nationaal Cyber Security Centrum (NCSC) through mijn.ncsc.nl. This was mandatory from 15 August 2026. After registering, you can use the services of the NCSC or your sector CSIRT, including threat information and incident support.
2. Duty of care (zorgplicht). Take appropriate and proportionate measures to manage the risks to the security of your network and information systems, and to prevent incidents or limit their effects. The government sector regulation refers to this duty as Article 21, first paragraph, of the Cbw, which mirrors Article 21 of NIS2. Under NIS2 Article 21(2), those measures include supply chain security (point d) and security in acquisition, development and maintenance, including vulnerability handling and disclosure (point e).
3. Reporting (meldplicht). Report significant incidents within the legal deadlines to your CSIRT and your competent authority, through the NCSC reporting portal. Thresholds for "significant" are set in ministerial regulations per sector and may differ, so read the one for your sector.
4. Board responsibility. The board approves the duty of care measures and oversees them. Directors need enough knowledge to assess risks and measures, and must take suitable training.

The reporting clock. The NCSC's infosheet on the meldplicht describes a phased duty: an early warning as soon as possible and at the latest within 24 hours of detecting the incident, a notification with an assessment of severity and impact within 72 hours, updates on request, and a final report at the latest within one month (or a progress report if the incident is still running). The infosheet adds two exceptions: entities that also fall under DORA or the network code on cybersecurity for cross-border electricity flows give their early warning within four hours, and trust service providers file a notification within 24 hours. A significant incident report goes automatically to the sector CSIRT and the competent supervisor; a voluntary report goes only to the CSIRT.

Wet weerbaarheid kritieke entiteiten (Wwke): in force since 15 August 2026

Status. Approved by the Eerste Kamer on 7 July 2026 and in force since 15 August 2026. The Wwke implements the EU CER Directive. Organisations become critical entities when the responsible minister designates them, and the government said designations took formal effect from 15 August 2026.

Scope. Around 500 organisations, in sectors that include energy, transport, banking, healthcare, drinking water, digital infrastructure, government and food.

Duties and clocks. According to the government:

• Risk assessment within 9 months of designation, covering the risks that could disrupt the continuity of essential services.
• Measures within 10 months of designation: appropriate technical, organisational and physical measures to raise resilience.
• Incident notification within 24 hours for incidents that significantly disrupt, or could disrupt, essential services, to the competent authority (the ministry and the supervisor).

If your designation took effect on 15 August 2026, those clocks point to around mid-May 2027 for the risk assessment and mid-June 2027 for the measures. Use the date on your own designation, not this estimate. Software and ICT suppliers sit inside "continuity of essential services", so your inventory and supplier list feed the risk assessment.

Government: the Cyberbeveiligingsregeling sector overheid and BIO2

Status. The Cyberbeveiligingsregeling sector overheid is a ministerial regulation of the State Secretary for the Interior and Kingdom Relations dated 3 July 2026, published in the Staatscourant on 5 August 2026 (Stcrt. 2026, 27679). It is based on Articles 19 and 23(1) of the Cyberbeveiligingsbesluit, the decree under the Cbw.

Scope. Article 2: essential entities in the government sector listed in Annex 1 to the Cbw, excluding water boards.

What it requires.

• Article 3 (ISO 27001). Apply NEN-EN-ISO/IEC 27001:2023 to set up, implement, maintain and continually improve the management system for network and information security, and to set its scope.
• Article 4 (crucial systems). Keep an overview of your crucial network and information systems as part of that management system. For central government, a system is crucial at protection levels 1 to 3 of Annex 1; for decentralised government, at impact level "high" or "very high" of Annex 2.
• Article 5 (ISO 27002 and BIO2). Use at least the controls of NEN-EN-ISO/IEC 27002:2022 (except controls 5.32 and 5.34) when setting the measures required by Article 21(1) of the Cbw, and include at least the relevant government measures of the Baseline Informatiebeveiliging Overheid 2 (BIO2), version 1.3 (Stcrt. 2026, 7416), except measures 5.32.01 to 5.34.01.
• Article 6. Thresholds for the reporting duty.

This turns the Cbw's open wording into named standards, so ISO 27002 controls on supplier relationships, vulnerability management and secure development become part of the legal baseline for essential government entities.

Healthcare: NEN 7510

Status. By a decision published in the Staatscourant (Stcrt. 2026, 17743), the Minister for Long-term Care, Youth and Sport announced a new edition of NEN 7510 and made it applicable from 1 June 2026 to electronic exchange systems and care information systems as defined in Article 1 of the Besluit elektronische gegevensverwerking door zorgaanbieders. The legal basis is Article 7 of that decree. The editions are:

• NEN 7510-1:2024, Medical informatics, information security in healthcare, Part 1: management system
• NEN 7510-2:2024+A1:2026, Part 2

NEN 7510 follows the ISO 27001 and ISO 27002 structure, with health-specific additions. For software that means asset inventory, technical vulnerability management, supplier relationship controls and secure development, applied to systems that hold patient data. Healthcare providers that are essential or important entities under the Cbw also carry the Cbw duties on top.

Financial sector: DORA with DNB and the AFM

Status. DORA (Regulation (EU) 2022/2554) entered into force on 17 January 2023 and has applied since 17 January 2025, according to DNB. The AFM describes DORA as covering IT risk management, IT incident management, testing, oversight of critical IT service providers, and governance, and says the AFM and DNB supervise together.

What DNB asks for in practice.

• Register of information (Article 28(3)). DNB opened the 2026 reporting request in MyDNB on 2 March 2026, with reference date 31 December 2025 and a reporting period from 1 January 2025.
• Major ICT-related incidents (Article 19(1) and Article 23). Reported through Mijn DNB with DNB's template, as are voluntary notifications of significant cyber threats (Article 19(2)).
• Planned contracts for critical or important ICT services (Article 28(3)). Notified to DNB through Mijn DNB.
• NIS2 overlap. DNB states that financial institutions in NIS2 scope also report the incident to the NCSC.

For software, DORA's Article 28 on ICT third-party risk and Article 30 on key contract provisions apply to every ICT service provider, including the SaaS products and managed services your developers depend on. Article 8 asks you to identify and document ICT assets, which for software means components and versions.

Makers of products with digital elements: the EU Cyber Resilience Act

Status. The European Commission states that the CRA entered into force on 10 December 2024, that reporting obligations apply from 11 September 2026, and that the main obligations apply from 11 December 2027. On 27 July 2026 the Commission published practical guidance for manufacturers, developers and businesses.

What it means for a Dutch maker, or a foreign maker selling into the Netherlands.

• Reporting (Article 14), live now. Manufacturers notify actively exploited vulnerabilities and severe incidents affecting their products through the single reporting platform, with an early warning within 24 hours, a notification within 72 hours and a final report later.
• SBOM (Annex I, Part II, point 1), from 11 December 2027. Manufacturers identify and document the vulnerabilities and components in their products, including by drawing up a software bill of materials in a commonly used, machine-readable format covering at least the top-level dependencies.
• Due diligence on components (Article 13(5)). Manufacturers exercise due diligence when they integrate third-party components, including free and open source software.
• Vulnerability handling for the support period. Coordinated disclosure, security updates and a contact address for reports.

The CRA applies to products, so a Dutch app maker and a foreign device maker selling in the Netherlands face the same product duties. Our deeper posts on CRA Article 14 reporting and CRA SBOM obligations cover the details.

AI: the EU AI Act, the Dutch implementation bill and the AP

EU status. According to the European Commission, the AI Act entered into force on 1 August 2024 and became applicable on 2 August 2026, with exceptions. Prohibited practices and AI literacy obligations have applied since 2 February 2025. Transparency rules came into effect in August 2026. The AI Omnibus, which entered into force on 27 July 2026, moved the rules for high-risk use cases in sensitive areas (Annex III, such as critical infrastructure, employment and education) to 2 December 2027, and the rules for high-risk AI built into regulated products (Annex I) to 2 August 2028. From 2 August 2026 the AI Office and member state authorities are responsible for supervision and enforcement.

Dutch status. On 20 April 2026 the government put the draft uitvoeringswet AI-verordening (the AI Act implementation bill) out to public consultation until 1 June 2026. The proposal is a cooperative model: existing supervisors oversee AI within their own domains, the Autoriteit Persoonsgegevens is proposed as the supervisor where no clear supervisor exists, and the AP and the RDI coordinate. The bill had not been enacted when we checked, so treat the national supervision structure as proposed, not final.

The AP's role today. The AP is already the Dutch data protection authority and publishes guidance on algorithms and AI. Whatever the final AI supervision structure, any AI system that processes personal data sits under the GDPR and the AP now.

GDPR and the Autoriteit Persoonsgegevens

The GDPR applies to every Dutch organisation that processes personal data. The parts that touch software supply chains are the processor contract under Article 28, security of processing under Article 32, and breach notification to the AP within 72 hours under Article 33. A software supplier that processes personal data on your behalf is a processor, so your vendor risk and privacy work overlap.

What the rules ask of software and open source

The texts use different words, but the same six asks keep coming back.

Know what software you run and ship

The Cbw duty of care starts with risk analysis, and NIS2 Article 21(2)(a) asks for policies on risk analysis and information system security. The government sector regulation makes it explicit: keep an overview of crucial systems (Article 4) and apply ISO 27002, whose controls include an inventory of information and assets. DORA Article 8 asks for ICT assets to be identified and documented. NEN 7510 has an asset management chapter. The CRA, from December 2027, asks for an SBOM. An SBOM per product is the cheapest way to answer "which of our systems contain this component?"

Handle vulnerabilities on a clock

NIS2 Article 21(2)(e) covers vulnerability handling and disclosure, ISO 27002 control 8.8 sits in BIO2 and NEN 7510, and the CRA asks makers to fix and report exploited vulnerabilities. Supervisors will look for advisory intake, triage against your inventory, fix timelines and recorded exceptions.

Manage software and ICT suppliers

NIS2 Article 21(2)(d) covers supply chain security, including relationships with direct suppliers. ISO 27002 controls 5.19 to 5.22 cover supplier relationships and ICT supply chain security. DORA Articles 28 to 30 add a register of information, pre-contract assessment and mandatory contract terms. The GDPR adds processor contracts. Open source sits awkwardly here: maintainers are not your suppliers in a contractual sense, so the evidence you hold for open source is your own inventory, your monitoring and your fix process, not a contract.

Report incidents fast

The clocks differ by regime. Build one runbook that meets the strictest one that applies to you.

The 24-hour Cbw early warning only needs to say whether the incident may be malicious and may have significant effects. You can only say that quickly if you know which systems and which software versions are affected.

Build software securely

ISO 27002 controls 8.25 to 8.31 (secure development life cycle, application security requirements, secure architecture, secure coding, security testing, outsourced development and separation of environments) apply through BIO2 and NEN 7510. The CRA's Annex I sets essential requirements for products. NIS2 Article 21(2)(e) covers security in development and maintenance.

Data residency, transfers and AI

No Dutch cyber law in this guide requires security data to be stored in the Netherlands; the GDPR governs personal data leaving the EEA. Procurement will still ask where a tool runs and whether an AI model sees source code. For AI, start with an inventory of systems and uses, screened for prohibited practices and Annex III areas.

Requirement to evidence map

Real public incidents in or affecting the Netherlands

These two incidents come from official or primary reporting. We draw no conclusions about what the organisations involved should have done beyond what the sources say.

Zero-day exploitation of a remote access gateway at critical Dutch organisations (2025)

On 13 August 2025 the NCSC published an update on its investigation into CVE-2025-6543, a vulnerability in a widely used application delivery controller and remote access gateway. The NCSC concluded that several critical organisations in the Netherlands had been successfully attacked through it. Its timeline puts first exploitation in early May 2025, advisories from the vendor and the NCSC on 25 June 2025, the NCSC's discovery of possible abuse at Dutch organisations on 16 July 2025, reports of compromise from several organisations on 18 July, and a check script on the NCSC's GitHub page from 21 July.

The NCSC described the attackers as advanced, said the vulnerability was exploited as a zero-day and that traces were actively wiped, and stated that updating systems was not enough to remove the risk of abuse. It advised defence-in-depth measures and follow-up investigation where indicators of compromise were found.

What it shows for software supply chain work. The vulnerable component was a vendor appliance, not code the victims wrote. The useful questions in the first hours were inventory questions: where do we run this product, which versions, and which of those faced the internet? Under the Cbw, that same inventory now drives the 24-hour early warning.

Laboratory breach exposes cervical cancer screening data (July and August 2025)

On 12 August 2025, Bevolkingsonderzoek Nederland, which runs the national screening programmes, wrote to participants in the cervical cancer screening programme. Its letter said that hackers had gained access to the ICT systems of Clinical Diagnostics NMDL, a laboratory in Rijswijk that processed screening samples, and that data of more than 485,000 participants had been viewed and copied. The data included names, addresses, dates of birth, citizen service numbers (BSN), test results and the names of care providers, and for a limited number of people email addresses or phone numbers. The letter said samples were now going to the programme's two other laboratories.

What it shows for supplier risk. The screening organisation was not the breached party; its processing supplier was. This is the pattern that NIS2 Article 21(2)(d), ISO 27002 supplier controls, NEN 7510 and GDPR Article 28 all address: an organisation remains accountable for data it hands to a supplier, and it needs to know which suppliers hold what, and how quickly they will tell it about an incident.

The personas who own the problem

CISO

Needs one picture of the organisation against the Cbw (and the Wwke, DORA or NEN 7510 where they apply), an incident runbook that meets the 24-hour or 4-hour clock, and a board briefing, because the board must approve the measures and take training. When: now, before the first supervisor information request and the next board meeting.

Head of AppSec, product security or VP Engineering

Needs an SBOM per product and release, vulnerability intake with timelines, CI gates that stop known bad versions, and for makers a CRA reporting runbook that works today, without slowing releases. When: CRA reporting has applied since 11 September 2026; SBOM documentation follows on 11 December 2027.

GRC and compliance lead

Needs a control mapping from the Cbw duty of care to ISO 27001 and 27002, BIO2, NEN 7510 or DORA, with evidence per control and one calendar of deadlines. When: the ISO 27001 internal audit, the NEN 7510 certification audit, the DNB register cycle and the first Cbw inquiry.

Procurement and vendor risk owner

Needs a supplier register with risk tiers, contract clauses on incident notice and SBOMs, and for financial entities the DORA register of information. When: every renewal, and straight after any supplier incident like the laboratory breach above.

Data protection officer (functionaris gegevensbescherming)

Needs processor agreements that match security reality, breach rules that line up the GDPR 72-hour clock with the Cbw 24-hour clock, and an inventory of AI systems that process personal data. When: the first incident that triggers both regimes.

Step by step: a 30/60/90-day plan that works with or without Safeguard

This plan assumes you are in Cbw scope, possibly also under the Wwke, DORA, NEN 7510 or the CRA. Skip the parts that do not apply.

Days 1 to 30: scope, register and inventory

1. Confirm scope in writing. Use the government's scope check for the Cbw and record your sector, your size class and whether you are essential or important. Note any Wwke designation and its date. Record whether DORA, NEN 7510, the government sector regulation or the CRA also apply.
2. Confirm registration. If you have not registered in the NCSC entity register at mijn.ncsc.nl, do it now and keep the confirmation.
3. Find your sector thresholds. Read the ministerial regulation for your sector and copy its significant-incident thresholds into your incident runbook.
4. Build the software inventory. Generate an SBOM for each product or system you build, starting with the crucial systems. For the software you buy, list the supplier, product, version and where it runs. Mark anything internet-facing.
5. List suppliers by impact. For each supplier, record what data and services it touches and whether a breach at that supplier would trigger your own report.
6. Brief the board on the duty of care, the clock and training, and schedule approval of the measures.

Days 31 to 60: controls, contracts and the drill

1. Map controls. Map the Cbw duty of care to ISO 27001 and 27002. Government entities add BIO2 v1.3; care providers add NEN 7510-2; financial entities add DORA Articles 5 to 30.
2. Set vulnerability timelines. Write down how quickly you fix critical and high findings in internet-facing and crucial systems, how you use exploit signals such as CISA KEV and EPSS, and who approves exceptions.
3. Add CI checks. Fail builds on known critical vulnerabilities in new dependencies, and on licences you cannot use.
4. Update supplier contracts. At renewal, add incident notice within a time that lets you meet your own clock, a right to receive an SBOM or equivalent component list, and vulnerability disclosure terms. Financial entities check the DORA Article 30 list.
5. Run a tabletop. Use a scenario like the gateway zero-day above: a vendor product you run is being exploited. Time how long it takes to say where you run it, which versions, and whether to file the 24-hour early warning.
6. Makers: test CRA reporting. Walk through a mock actively exploited vulnerability report, from intake to the 24-hour early warning.

Days 61 to 90: evidence, monitoring and review

1. Collect evidence per control. For each mapped control, store the artefact a supervisor would ask for: policy, inventory, scan result, ticket or minutes, with a date.
2. Monitor continuously. Re-scan inventories on every build and on new advisories, not once a quarter.
3. Close the board loop. Get the measures approved and record the directors' training.
4. Review AI use. List AI systems and models in use, screen for prohibited practices, record AI literacy measures, and note any Annex III area use ahead of 2 December 2027.
5. Set the next review. Put the next management review, internal audit and DNB register cycle on one calendar.

Template: Cbw supplier clause checklist

Use this at contract renewal. It is a checklist, not contract language; your counsel drafts the clause.

Checklist: the first hour after a supplier or product incident

1. Identify the product or supplier and confirm the advisory or notice.
2. Query your inventory for every system running the product or component, with versions.
3. Mark internet-facing and crucial systems.
4. Decide whether the incident may be significant under your sector thresholds.
5. If yes or unsure, prepare the 24-hour early warning (4 hours for DORA entities per the NCSC).
6. Check whether personal data is involved for the GDPR 72-hour clock.
7. Record who decided what, and when.

What changes for a foreign software maker selling into the Netherlands?

The CRA applies to you directly for products placed on the EU market, and the Cbw reaches you through your Dutch customers' supplier security duties: expect SBOM requests, vulnerability process questions and incident notice terms. If you provide digital infrastructure or managed ICT services in the Netherlands, check whether you are a Cbw entity yourself.

How Safeguard does this

Safeguard keeps the inventory, supplier requests, gates, fixes and evidence in one place. Commands and YAML below are copied from docs.safeguard.sh as checked in October 2026 and were not run for this post.

1. Inventory the software you build. SBOM generation and analysis (GA) and software composition analysis (GA) produce an SBOM per project across the full transitive dependency tree, in CycloneDX or SPDX. This is the software layer of the Cbw risk analysis, the government regulation's crucial systems overview and the NEN 7510 asset inventory.

2. Scan where code cannot leave your environment. The Safeguard CLI (GA) includes a local runner (GA). The docs say the runner polls the platform over outbound HTTPS that it opens, nothing connects to it, it runs scan jobs locally and uploads only the result files (SBOM and findings). Install and sign in as the docs show:

# macOS and Linux
curl -fsSL https://cli.safeguard.sh/install | bash
safeguard

Then type /login and approve the session in your browser. For a one-off scan of a directory or an existing SBOM:

safeguard scan --dir .
safeguard scan --sbom sbom.json

3. Validate supplier SBOMs. The CLI checks SBOMs against their specifications:

safeguard validate sbom.json --strict -o report.json

4. Run supplier intake in TPRM. In TPRM (GA), add suppliers and request SBOMs. From a vendor, click Request SBOM, select products, set a deadline and send. The docs describe status tracking through to Validated or Rejected, and automatic reminders, the first one 7 days before the deadline. Risk assessment scores suppliers from their SBOM analysis, and monitoring flags new vulnerability disclosures across suppliers. For a DORA entity this feeds, but does not replace, the register of information.

5. Load supplier advisories. With CSAF and VEX upload (GA), a supplier's "not affected" statement sits next to the findings for that product version.

6. Map to the Dutch and EU frameworks. The compliance and GRC suite (GA) includes framework pages for EU NIS2, EU DORA and Netherlands NEN 7510. Each scan checks scan requirements such as supply chain security (NIS2-21.2D), vulnerability handling (NIS2-21.2E), ICT asset identification (EU-DORA-8), the third-party provider register (EU-DORA-28) and, for NEN 7510, asset inventory and supplier relationships, and each framework adds catalog controls and policy templates. The docs list no framework page for the Cbw, the Wwke or BIO2 by name; use NIS2 as the base for the Cbw and map ISO 27001 and BIO2 controls yourself.

7. Gate what you ship. With policies and gates (GA), create policies on conditions such as vulnerability severity, CVSS, EPSS or licence. The docs define three actions: Block (the gate fails), Warn (the gate passes with a warning naming the policy) and Notify (the gate passes and a notification is sent). Legitimate exceptions go through the exception workflow with approval. In GitHub Actions, the docs show:

name: Safeguard
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - name: Safeguard scan
        env:
          SAFEGUARD_API_KEY: ${{ secrets.SAFEGUARD_API_KEY }}
          SAFEGUARD_INSTALL_DIR: ${{ runner.temp }}/safeguard-bin
        run: |
          set -eu
          curl -fsSL https://cli.safeguard.sh/install | bash
          "$SAFEGUARD_INSTALL_DIR/safeguard" ci scan --wait --fail-on critical

The docs add that --fail-on-gate all fails the job on a policy gate instead of a severity threshold.

8. Stop risky packages at install time. Package Firewall (GA) is an install-time proxy for npm and pip that blocks malicious, typosquatted and dependency-confusion packages before they reach a developer machine or build.

9. Rank by real exposure. Vulnerability management (GA) adds EPSS and CISA KEV, and reachability analysis (GA) labels findings reachable, conditionally reachable, unreachable or unknown.

10. Fix with pull requests. Autonomous remediation (GA) uses Griffin to open tested, policy gated pull requests that move a vulnerable dependency to a fixed version, one repository at a time or in bulk. It ships switched off, with every category set to Manual, so nothing changes until your team turns it on.

11. Inventory AI. AI-BOM discovery (GA) inventories AI assets, the starting list for AI Act work.

12. Share security documents with customers. Trust Center (GA) publishes a public page you manage in Compliance, Trust Center; nothing goes live until you publish it.

13. Choose where it runs. SaaS runs in US, EU and Gov regions. For residency or a no-code-leaves policy, the options are private VPC or dedicated tenancy, full on-prem, fully air-gapped with the AI models inside your environment, the local runner (source code never leaves your machine; only encrypted results are sent) and Zero AI mode (GA), with no LLM in the loop.

Safeguard becomes one of your suppliers once you adopt it, so assess it under the same procedures. Safeguard is designed for FedRAMP High, and its SOC 2 Type II audit is in progress. Safeguard holds no Dutch or EU certification or assessment for these regimes; it helps you produce and keep the evidence they ask for.

What Safeguard does not do

• It does not decide whether you are in scope or whether an incident is significant. Scope under the Cbw is your own assessment, and significance depends on your sector's ministerial thresholds. Safeguard gives you the inventory to decide fast; the decision and the report are yours.
• It does not file reports for you. Early warnings go through the NCSC portal, DORA incident reports through Mijn DNB, CRA reports through the single reporting platform and GDPR notifications to the AP. You file them.
• It does not certify you. There is no Cbw, BIO2, NEN 7510 or DORA certificate from Safeguard. NEN 7510 certification comes from an accredited certification body, and supervisors judge Cbw and DORA compliance.
• It does not cover the physical and organisational measures in the Wwke, such as site security, staff vetting and continuity planning for non-ICT hazards.
• It does not fix vendor appliances or hosted services. When the vulnerable code sits in a product you buy, like the gateway in the 2025 incident, the fix comes from the vendor. Safeguard helps you find where you run it.
• It does not offer an in-country Dutch SaaS region. SaaS regions are US, EU and Gov. For stricter residency needs use private VPC, on-prem, air-gapped, the local runner or Zero AI mode. Safeguard's EU region is in Frankfurt, Germany, so data stays in the EU.

Common mistakes

• Waiting for a letter. No regulator will tell you that you are in Cbw scope; the assessment is yours.
• Building three incident runbooks. One runbook with the strictest clock (4 hours for DORA entities, 24 hours otherwise) and a branch per recipient beats separate processes for the NCSC, DNB and the AP.
• Leaving open source out of supplier risk. Maintainers are not contracted suppliers, but their code is in your supply chain. Your inventory and fix process are the control.
• Reading BIO2 as optional. For essential government entities, the relevant BIO2 v1.3 measures are the minimum.
• Assuming the CRA starts in 2027. Reporting has applied since 11 September 2026.
• Assuming the AI Act was postponed in full. Only the high-risk rules moved. Prohibitions, AI literacy and transparency rules already apply.

FAQ

When did the Dutch Cyberbeveiligingswet take effect?

On 15 August 2026. The Eerste Kamer approved it on 7 July 2026, and the government confirmed on 15 August 2026 that it applied from that day. It replaces the Wbni.

What is the incident reporting deadline under the Cbw?

The NCSC describes an early warning as soon as possible and at the latest within 24 hours, a notification within 72 hours, and a final report within one month. Entities also under DORA give their early warning within four hours, per the NCSC.

Does BIO2 apply to municipalities?

The Cyberbeveiligingsregeling sector overheid applies to essential entities in the government sector except water boards, and requires the relevant measures of BIO2 version 1.3. Check whether your body is an essential entity under Annex 1 to the Cbw.

Which version of NEN 7510 applies in 2026?

NEN 7510-1:2024 and NEN 7510-2:2024+A1:2026, applicable from 1 June 2026 to electronic exchange systems and care information systems under the Besluit elektronische gegevensverwerking door zorgaanbieders.

Do Dutch banks report incidents to DNB or the NCSC?

Major ICT-related incidents under DORA go to DNB through Mijn DNB. DNB states that financial institutions within NIS2 scope also report the incident to the NCSC.

Does the Netherlands require SBOMs?

No Dutch national law in this guide names SBOMs. The EU Cyber Resilience Act requires manufacturers to draw one up from 11 December 2027, and SBOMs are the practical evidence for asset inventory and vulnerability handling under the Cbw, BIO2, NEN 7510 and DORA.

Who supervises AI in the Netherlands?

The national structure is still a bill. The draft implementation act, consulted from 20 April to 1 June 2026, proposes that existing supervisors oversee AI in their own domains, that the AP supervise where no clear supervisor exists, and that the AP and the RDI coordinate. The AP already supervises AI that processes personal data under the GDPR.

Does Safeguard have a Dutch data centre?

No. SaaS runs in US, EU and Gov regions. Safeguard's EU region is in Frankfurt, Germany, so data stays in the EU. For residency, use private VPC, on-prem or air-gapped deployment, the local runner or Zero AI mode.

Most of the plan above comes down to two things: knowing which software and components you run, and closing the gap between a published fix and the fix running in production. The block below describes how Safeguard closes that gap for the open source you build on, which is also where a supervisor's question about vulnerability handling usually lands.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo shows the local runner: you set it up on your own machine, approve it with its device code, then scan from the terminal. For a Dutch hospital, bank or ministry with a policy against granting a cloud service repository access, this is the route to an SBOM and findings for crucial systems.

Click through it at your own pace, or open it full screen.

The second demo is a real CLI session: asked to fix the lodash CVE in a repository, it reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. The same flow fits the vulnerability timelines you set in days 31 to 60 of the plan.

Click through it at your own pace, or open it full screen.

Quick check

Related reading

• NIS2 in the Netherlands: the Cyberbeveiligingswet
• DORA for financial services: third-party ICT risk
• CRA Article 14 vulnerability reporting
• EU Cyber Resilience Act SBOM obligations
• NIS2 supply chain evidence for EU operators

Sources

• Rijksoverheid, Cbw and Wwke in force from 15 August 2026 (15 August 2026)
• Rijksoverheid, Eerste Kamer approves Cbw and Wwke (7 July 2026)
• Staatscourant 2026, 27679, Cyberbeveiligingsregeling sector overheid
• Staatscourant 2026, 17743, new edition of NEN 7510
• NCSC infosheet on the Cbw reporting duty
• NCSC case page on CVE-2025-6543 exploitation
• Bevolkingsonderzoek Nederland, letter to participants on the laboratory data breach (12 August 2025)
• DNB, DORA
• AFM, Digital Operational Resilience Act
• Rijksoverheid, consultation on AI Act supervision (20 April 2026)
• Autoriteit Persoonsgegevens, Algorithms and AI
• European Commission, AI Act regulatory framework and timeline
• European Commission, Cyber Resilience Act
• Safeguard docs, EU NIS2 Directive framework
• Safeguard docs, EU DORA framework
• Safeguard docs, Netherlands NEN 7510 framework
• Safeguard docs, Local Runner
• Safeguard docs, CLI usage
• Safeguard docs, GitHub Actions
• Safeguard docs, Policies and Gates
• Safeguard docs, TPRM SBOM Requests
• Safeguard docs, Generate SBOM
• Safeguard docs, CSAF/VEX Upload
• Safeguard docs, Reachability Analysis
• Safeguard docs, AI Remediate
• Safeguard docs, Trust Center
• Safeguard docs, Air-Gapped Deployment

Start with the free tier at safeguard.sh/download and read the Safeguard docs.

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.