NIS2 and the Dutch Cybersecurity Act: What It Changes for Software Suppliers

Introduction

A law is coming that many software companies underestimate because they assume it does not apply to them. The Dutch Cybersecurity Act, the national transposition of the European NIS2 directive, is expected to take effect in the second quarter of 2026. The bill was submitted to the House of Representatives on 4 June 2025. Entry into force was previously pushed from the third quarter of 2025 to 2026 due to the complexity of implementation.

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 organization, that organization must be able to demonstrate that you do not weaken its security. As a result, an estimated 50,000 Dutch companies fall indirectly under the law. This article explains what that concretely means for software and how to build now so you can prove compliance later.

What NIS2 and the Cybersecurity Act actually are

"NIS2 does not apply to organizations directly. Only once the Cybersecurity Act is adopted by both chambers of parliament do the concrete obligations arise in the Netherlands."

— Summary from Digitale Overheid on the Cybersecurity Act, consulted May 2026

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 current Network and Information Systems Security Act. 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. Essential entities have major societal impact if they fail, think payment systems or energy supply. Important entities are a broader group, including many digital service providers, manufacturers and online service operators. NIS2 substantially expanded the number of sectors compared with the first directive, to eighteen sectors including manufacturing and digital infrastructure.

Supply-chain responsibility: why this affects you

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 that starts before the law formally takes effect. Large clients will send their suppliers questionnaires, contractual requirements and demands for security evidence. 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.

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 three core obligations

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 full report to the supervisory authority or the National Cyber Security Centre. Three: the registration obligation. Entities under the law must register, creating a European overview.

On top of that sits an element directors often underestimate: management accountability. The board is responsible for approving and overseeing the risk measures and can be held personally liable. 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.

What this means for how software is built

The duty of care sounds abstract, but translates into concrete technical measures you build into software. Multi-factor authentication on all accounts, because it is the cheapest measure with the biggest impact. 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.

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, because that framework covers a large part of the duty-of-care requirements. For suppliers there is also a lighter NIS2 supply-chain certificate achievable within a few months.

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.

A practical timeline towards entry into force

Start with a gap analysis. Map which of your clients are essential or important entities, which software you supply to them and where your security stands relative to the duty of care. This overview sets your priorities and is exactly the document you need when a large client sends you a questionnaire.

Then tackle the baseline measures that cover the most risk: MFA everywhere, cleaning up access rights, testing backups, an incident response plan on paper and logging in order. These are high-impact, relatively low-cost measures. In parallel, plan for demonstrability: document policies, keep incident logs and map your data flows. Expect large clients to actively approach their suppliers during 2026, so do not wait for that.

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 and the AI Act together: compliance by design

NIS2 does not stand alone. For many software companies the entry into force of the Cybersecurity Act falls in the same period as the enforcement of the EU AI Act on 2 August 2026. 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.

Do you have software supplying an essential or important entity, or want to know whether your portfolio is NIS2-ready? Tell us your situation. We run a gap analysis and build in the measures and evidence where needed.

Conclusion

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.

Those who start now with a gap analysis, baseline measures and demonstrability will sit on the right side of both the tender and the law. Those who wait until clients start asking will be running behind. Security taken into account from the architecture is not a cost. It is a selling point.