Dutch Cybersecurity Act (NIS2): What Changes for Software

The Cybersecurity Act (Cbw), the Dutch implementation of the European NIS2 directive, has applied since 15 August 2026. According to the Dutch government (Rijksoverheid), more than 8,000 organisations fall directly under the act. They must take appropriate security measures, report serious incidents and register with the NCSC. Because that duty of care also covers the supply chain, software suppliers to those organisations are affected indirectly.

Since 15 August 2026 there has been a law that many software companies underestimate because they assume it does not apply to them. The Senate (Eerste Kamer) approved it on 7 July 2026. The misconception sits in the word essential. Many SME owners read that the law applies to essential and important entities such as energy, water, healthcare and banks, and conclude that they are out of scope. But NIS2 works through the supply chain. If you supply software to such an organisation, that organisation must be able to demonstrate that you do not weaken its security. How many suppliers are affected indirectly has not been officially counted; expect every in-scope client to include requirements in contracts and procurement questionnaires. This article explains what that concretely means for software and how to build now so you can demonstrably comply.

Last updated: 14 October 2026. What changed: the Cybersecurity Act has been in force since 15 August 2026, so all expectations are now in the present tense. The claim about the number of indirectly affected companies has been removed because no neutral source exists for it. Registration with the NCSC, the timeline and the checklist for software suppliers have been added; the first version appeared on 22 May 2026.

Source: Staatsblad 2026, 189 (the Dutch Bulletin of Acts and Decrees, Article 35), Rijksoverheid, 7 July 2026 and Rijksoverheid, 15 August 2026. Wwke is the Critical Entities Resilience Act (Wet weerbaarheid kritieke entiteiten). There is no automatic designation: organisations assess for themselves whether they fall under the Cbw.

NIS2 stands for the second Network and Information Security Directive, a European directive in force since 16 January 2023. A directive does not apply directly: each member state must transpose it into national law. In the Netherlands this happens through the Cybersecurity Act, which replaces the Network and Information Systems Security Act (Wbni). The goal is to raise the digital resilience of essential services, because dependence on digital systems and the level of threat are both rising.

The law defines two categories of entity: essential and important. Which one applies depends on sector and size. Large organisations in sectors such as energy, transport, banking, drinking water and healthcare are essential entities; medium-sized organisations in those sectors are important entities. Medium-sized and large organisations in sectors such as digital providers, food, chemicals, research and manufacturing are also important entities. In total there are eighteen sectors. Your clients can check whether they fall under the act on the NCSC page Does my organisation fall under the Cybersecurity Act?

The most important mechanism for software companies is supply-chain responsibility. NIS2 requires entities to manage the security risks in their supply chain. In practice that means: if you supply software, hosting, integrations or maintenance to an essential or important entity, that client must be able to demonstrate that you do not undermine its security. You become part of its compliance.

This has a concrete consequence: in-scope clients include security requirements in contracts and procurement questionnaires. Anyone without a credible answer loses contracts long before a regulator appears. For a software studio or SaaS supplier, NIS2 is therefore not primarily a legal risk but a commercial one: you win or lose tenders on demonstrable security. You can read which questions to expect in requirements your clients will push.

If you develop a scheduling system for a hospital, an integration for a grid operator or a portal for a financial institution, you are already part of a NIS2 chain in practice. The question is not whether you have arranged things properly, but whether you can prove it.

The law imposes three main obligations on organizations that fall under it directly. One: the duty of care. You must systematically analyze your security and continuity risks, from cyberattacks to data theft and supply-chain risks, and take appropriate technical and organizational measures based on that analysis. Two: the reporting obligation. Significant incidents must be reported within 24 hours as an early warning and within 72 hours as a notification to your CSIRT and the competent authority, via the NCSC reporting portal (Articles 26 and 27 of the Cybersecurity Act; see also Article 23(4) of the NIS2 directive). Three: the registration obligation. Entities that fall under the law have had to register in the NCSC national entity register since 15 August 2026, via mijn.ncsc.nl.

On top of that sits an element directors often underestimate: the role of the board. The board approves the measures, oversees their implementation and must complete appropriate training. Cybersecurity has formally become a boardroom topic, not a task you can fully delegate to your IT supplier.

For indirect suppliers this translates into contractual and evidence requirements. You often do not have to register yourself, but you must be able to show that your software and processes support your client's duty of care rather than undermine it.

The duty of care sounds abstract, but translates into concrete technical measures you build into software. Multi-factor authentication on all accounts (two-factor authentication), because it is a high-impact measure at a relatively low cost. Role-based access control, so users only reach what they need. Encryption of data at rest and in transit. Structured logging and monitoring, so you can detect incidents and reconstruct them within the reporting windows. Patch management, so known vulnerabilities are closed quickly. And for integrations: API security. A broader overview of the basics is in securing your business software.

The second part is demonstrability. NIS2 does not only require that you are secure, but that you can prove it. That means security is not something you add afterwards, but something that lives in the architecture and in the documentation. An audit log that shows who did what and when. An overview of data flows and integrations. A documented incident procedure. A processing register. Many SMEs use ISO 27001 as a backbone for their information security.

At MG Software we build these measures in by default when a project has a NIS2 context. No black-box components without logging, no shared accounts, no hardcoded secrets. We deliver not just working software, but the evidence your client needs for its own duty of care.

This is what in-scope clients may, in our project experience, expect from you as a software supplier. It is an indication from our own projects, not a legal list.

1. Check whether your clients are essential or important entities.
2. Document an incident process that supports their 24-hour early warning.
3. Document access control, logging and backups.
4. Keep an up-to-date overview of the open-source dependencies you use.
5. Include security agreements in the data processing agreement or SLA.

Do not forget your own suppliers. NIS2 runs through the entire chain, so the hosting party, the external APIs and the open source components you use also fall under your responsibility. A software supplier that has not put its own supply chain in order cannot reassure its clients either.

NIS2 does not stand alone. For many software companies the Cybersecurity Act runs in parallel with the AI Act for SMEs: the AI Act transparency duty has applied since 2 August 2026, and the high-risk rules follow from 2 December 2027. If you build AI features into software that also supplies an essential chain, the requirements stack: NIS2 asks for logging, access control and incident response, the AI Act asks for risk management, transparency and human oversight. Many of those requirements overlap.

That is exactly why we use compliance by design rather than compliance after the fact. A good audit log serves both NIS2 and the AI Act. Good access control serves both security and governance. Anyone trying to bolt these frameworks on separately afterwards does the work twice and often ends up with a less coherent system. Anyone who takes them into account from the architecture gets more reliable software in return.

Want to know whether your software is ready for your clients' requirements? We will run a short security check.

The Cybersecurity Act turns security into a contractual and commercial topic, not just a technical one. For software companies supplying essential and important entities, the key shift is that you must not only have your security in order, but also be able to prove it to your clients. What clients ask of you is listed in requirements your clients will pass on.

Those who can demonstrate MFA, logging and an incident process sit on the right side of both the tender and the law. Those who wait until the questionnaire arrives will be running behind. Security taken into account from the architecture is not a cost. It is a selling point.

Sources (consulted 13 October 2026)

• Staatsblad 2026, 189 (Cybersecurity Decree), Article 35: entry into force on 15 August 2026.
• Rijksoverheid, news item of 7 July 2026: Senate approval, more than 8,000 organisations, registration via mijn.ncsc.nl.
• Rijksoverheid, news item of 15 August 2026: confirmation of entry into force, duty of care, reporting duty and role of the board.
• Cybersecurity Act (wetten.overheid.nl), Articles 26 and 27: reporting deadlines.
• NCSC: Does my organisation fall under the Cybersecurity Act?: sectors, size, essential and important entities.
• Directive (EU) 2022/2555 (NIS2), EUR-Lex, Article 23(4).