Dutch Cybersecurity Act: requirements your clients will push

On 7 July 2026 the Dutch Senate approved the Cyberbeveiligingswet, the Dutch implementation of the European NIS2 directive. The law has been in force since 15 August 2026 and directly affects an estimated eight thousand plus Dutch organisations: from energy companies and hospitals to carriers, data centres and larger manufacturers. They face a duty of care, a registration duty and a reporting duty for serious incidents.

We wrote earlier about what this means for software companies that fall under the law themselves in our article on NIS2 and software suppliers. This article covers the other side, which affects far more companies: your client is in scope and pushes the requirements onto you through contracts, questionnaires and audits. Even if your company appears nowhere in any annex of the law, security has been a condition of doing business since 15 August. We already see it happening with our own clients in and around Haarlem, and this is what you can expect.

The Cybersecurity Act imposes three core obligations on organisations across eighteen sectors. The duty of care: taking appropriate technical and organisational measures to secure network and information systems, including the security of the supply chain. The registration duty: registering in the entity register at the NCSC. And the reporting duty: reporting serious incidents to the CSIRT within 24 hours of discovery, followed by an interim update and a final report.

For board members the law is personal: they must approve the measures, supervise their implementation and are required to complete training on cyber risks. That explains why the topic suddenly sits on boardroom tables instead of only with the IT department. A director who is personally accountable for the chain will start checking that chain.

The word that changes everything for suppliers is "chain". The duty of care explicitly covers risks entering through suppliers and service providers. A hospital, carrier or energy company can have its own systems in perfect order; if the custom portal built by an external developer has a leak, that is their problem under the law. So they make it your problem by contract.

The trickle-down to suppliers almost always follows the same pattern. First comes the supplier questionnaire: a spreadsheet or portal form with thirty to one hundred fifty questions about your security measures, often based on ISO 27001 or the NIS2 measures catalogue. Then follows a contract annex or addendum to the existing agreement, with security requirements, notification windows and audit rights. And for larger or long-running relationships, eventually the audit itself: a request for evidence, a conversation with your developers or an external assessment.

At one of our clients, a supplier to a logistics company in scope of the law, exactly this sequence played out this spring. First a questionnaire with 92 questions, at least twenty of which concerned the client portal we had built for them: how is access secured, who can reach which data, how long are logs retained, how quickly are vulnerabilities patched. Because we could pull those answers from existing documentation and logging, the list was completed in two afternoons. The alternative, reconstructing after the fact how a system works, takes weeks.

Important to realise: you cannot ignore these questionnaires or answer them too optimistically without consequences. The answers become part of your client's contract file. If an incident later reveals that your actual situation differs from what you declared, you have a contractual problem on top of the technical one. Answering honestly, including "we have not arranged that yet, this is our plan", is almost always the better strategy.

Multi-factor authentication tops the list. Clients expect MFA on all administrative access and increasingly also for end users of portals that expose business data. Right after that comes authorisation: can your software assign roles and permissions at a fine-grained level, in other words role-based access control (RBAC)? A portal where every logged-in user sees everything no longer passes any assessment.

Logging and monitoring form the third block. Who logged in when, what was changed, which data was exported? Clients ask for central, tamper-evident logging with a retention period, usually at least twelve months, precisely because they need those logs for their own reporting duty. The fourth block is encryption: data in transit over TLS is a given by now, but encryption of data at rest, of backups and of sensitive database fields is also asked for as standard.

Block five is patching policy. How quickly do you process security updates in dependencies and frameworks, and can you prove it? After incidents such as the wp2shell flaw in WordPress, clients explicitly ask about the maintenance status of everything that touches their data. And block six is incident response: do you have a documented process, a point of contact and a recovery time? Whoever has these six topics in order passes the vast majority of any supplier assessment.

Your client's reporting duty is counted in hours: an early warning to the CSIRT within 24 hours of discovering a serious incident. They can only meet that if their suppliers pass on what is happening at least as fast. So expect contract clauses with a pass-through obligation of 24 hours or less for incidents affecting the client's services, including the duty to cooperate with the investigation and the follow-up reports.

Do not sign such a clause blindly. Watch three things. First, the definition of "incident": it should concern actual or likely impact on the client's services, not every failed login attempt in your logs. Second, the starting point: the window should run from the moment you discover the incident, not from the moment it occurred. Third, liability: committing to a notification window is reasonable, unlimited liability for all chain damage is not.

Our experience is that clients are open to negotiation here, because their legal teams need to place the same clauses with dozens of suppliers and benefit from workable agreements. What is not negotiable: having a functioning incident process. A contact person, an escalation path, and the technical ability to see within a day what happened. That last point brings us to the role of the software itself.

There is a fundamental difference between being secure and being able to prove it. For your clients' questionnaires and audits, the second matters most, and well-built custom software has a structural advantage there. In a custom portal or dashboard you decide which events are logged, how roles are structured and which reports exist. Demonstrability becomes an export button, not an archaeology project.

Concretely, in security-sensitive projects at MG Software we build in four things as standard that make audits almost frictionless: an audit trail of all changes and access, a permissions overview showing per role who can do what, automated dependency updates through the CI pipeline with a log of applied patches, and MFA plus session management on all access. For a client in scope of the Cybersecurity Act, such a system is not a risk item in the chain but a piece of evidence.

The mirror image also holds. Outdated custom systems, built in an era when nobody asked for logging or MFA, become a liability under the law. We now see clients explicitly asking about the life cycle of software: which framework, which version, is it still maintained? If a critical system at your company runs on an end-of-life framework, then redeveloping that software is no longer a luxury but the condition for keeping certain clients at all.

Start with your client list, not with your technology. Which clients likely fall under the law? The sectors are listed on the NCSC website, which also offers a self-assessment tool. Every client in energy, healthcare, transport, digital infrastructure, manufacturing or government is a candidate to send you a questionnaire this autumn. For those clients, map which systems and services you supply and which data you process in doing so.

Then record your own baseline before the first questionnaire arrives. Document per system how authentication and authorisation work, what is logged, how backups and encryption are arranged and how the patching process runs. Write out your incident process on a single page: who discovers, who decides, who notifies the client, within which window. That document is half of every questionnaire answer you will give in the coming years.

Finish with the gaps. Usually there are three: missing MFA on older systems, logging that exists but is not centrally searchable, and an outdated system everyone knows should really be replaced. For that last one, not everything has to happen at once: a phased rebuild, starting with the access layer and the logging, often makes you audit-ready within a few months. How to specify such a project before you start building is covered in our functional design template.

The Cybersecurity Act has been in force since 15 August 2026, and its influence does not stop at the eight thousand plus organisations that must register with the NCSC. Through the duty of care and chain responsibility, the law is now the de facto security standard for everyone supplying those organisations. The suppliers who will feel it least are those who can already demonstrate MFA, roles, logging, encryption, patching policy and an incident process today.

Do you supply companies in scope of the law and want to know where your software stands? Get in touch for a level-headed assessment. Often that means MFA, logging and integrations in a web application or via existing systems. And if the conclusion is that a critical system needs replacing, our calculator gives you a first range within two minutes.