Custom software for the duty of care under the Cybersecurity Act
The Cybersecurity Act has applied since 15 August 2026 and affects over eight thousand organisations. Most of them do take security seriously; what they cannot do is show that they do. The duty of care is not a list of measures but an obligation to make reasoned choices, and for most companies that reasoning lives in people's heads, email threads and loose documents.
Why the duty of care is a documentation issue
The Cybersecurity Act is the Dutch implementation of the European NIS2 Directive and came into force on 15 August 2026. It applies to essential and important entities in eighteen sectors, from energy and drinking water to healthcare, transport, digital infrastructure and government. Organisations within its scope must register in the national entity register managed by the NCSC.
At its core is the duty of care: taking appropriate and proportionate measures to manage the risks to your network and information systems. Appropriate and proportionate are not technical terms but judgements, which means a supervisor will not ask which measures you have, but why these particular ones and why not more. There is also a three-stage reporting obligation, and board members bear personal ultimate responsibility.
That shifts the problem. You can buy the technology or already have it; what is missing is the trail of reasoning. Which risks have you identified, which measure belongs to which risk, who decided that and when, and what has changed since. Without that trail your security is not necessarily weak, but it is unprovable, and under this law that amounts to the same problem.
If you are a healthcare provider, you also have a separate obligation towards the patient: electronic access and the right to inspect the logging. See Wabvpz software.
If you provide services to other organisations, they often ask for an assurance report on the same measures. See ISAE 3402 and SOC reporting.
How we build this
The link between risk and control carries the whole file. If that link is solid, accountability follows from it; if it isn't, every overview is just a snapshot.
We begin with what you already have, however incomplete. An existing assessment with gaps is a better starting point than a new model, because your people will recognise it.
Every measure gets a reason and an owner. That sounds administrative, and it is the only way to later explain why you did not do something.
We pull evidence from the systems you already use rather than asking people to gather it. Evidence that requires manual effort goes out of date within a quarter.
We have the system answer one sector or supervisory question as if it arrived today. What is missing from that answer is your real backlog.
What the software actually does
The register of risks and measures carries everything. Which components you need depends on your size, your sector, and whether you are an essential or an important entity.
Risks and controls linked together
For each risk: which control mitigates it, who owns it and when it's reassessed. The link is the point: a list of controls without risks explains nothing, and a list of risks without controls is just a problem overview.
Justification kept for each choice
Why this measure and not that one, who decided, and on what date. In supervision it is rarely the measure itself that matters, and almost always the reasoning behind it.
Evidence from your own systems
Patch status, backup checks, access reviews and exercises come in through integrations rather than a round of emails. What arrives automatically stays current.
Deadlines and reassessments monitored
Registration, periodic reassessment of risks, exercises and the training obligation for board members each run on their own clock. The system monitors them and gives warning in advance, not after the fact.
The supply chain side documented
The law also looks at your suppliers. A portal where they submit their own measures and statements works better than an annual questionnaire whose answers nobody can find again.
Deviations with follow-up
A measure that does not work, a control that fails, a supplier that does not deliver. Each of these becomes an action with an owner and a deadline, because an identified shortcoming without follow-up counts against you in supervision rather than reassuring.
Who we build for
The eighteen sectors differ greatly in what they already have in place. Four situations.
Healthcare providers
You often already have an information security standard and therefore plenty of material. The bottleneck is that it is spread across different systems and departments, whereas the law asks for one coherent account of the organisation as a whole.
Drinking water, energy and grid operators
Here office automation and process automation overlap, and each follows different habits. The hardest part is not the technology but explaining why a measure in the process environment is implemented differently from one in the office.
Transport, logistics and supply
Your greatest risk lies with parties outside your own walls. The supply chain side of the duty of care is therefore no side issue, and requesting measures from suppliers is the bulk of the work.
Government and public organisations
For central government there is also a separate baseline, and digital accessibility and archiving set their own requirements. That calls for a file that can account for several frameworks side by side without blending them together.
Test your idea first: a working prototype in 1 day
With OneDayBuild, we turn your idea into something tangible in one day for €1,150, so you can see whether further development is worth the investment. Decide to go ahead with the full build? Then we credit the full cost.
Explore OneDayBuild →Technology and integrations
The sector-specific details are set out in ministerial regulations, which will be supplemented after entry into force. Everything connected with this should be configurable and retained per version.
Why Appfront
Demonstrability is the problem, not security
Most organisations already do a great deal. We build the trail that shows you are doing it, and why it is done that way, because that is what the supervisory authority asks for.
Evidence that gathers itself
What people have to supply by hand goes stale. We gather evidence through integrations with the systems you already use.
Your security file is itself sensitive
An overview of your weak spots is more valuable to an attacker than the weak spots themselves. That is why we keep access and logging tight, and here that is no mere formality.
Incident reporting is a separate system
Reporting under time pressure requires its own set-up. We keep it deliberately separate; see the incident reporting portal.
Security and privacy
With this file, the content itself is the risk. A system that brings together your risk assessment, your open shortcomings and your supplier dependencies amounts, for an attacker, to a playbook. We therefore keep access tightly controlled by role, show board members summaries without technical detail, and log every instance of access. Your own administrators do not automatically see everything either.
On the evidence side a particular requirement applies. Accountability is only worth something if it can be established that it has not been updated after the fact. We record assessments, decisions and supporting documents in a tamper-proof way, with time and person, so that you can show the supervisory authority what you knew at the moment you decided. A file that only holds the current state cannot answer that question. How we handle security ourselves is set out in our information security policy; reports from outside reach us via our coordinated vulnerability disclosure policy.
Frequently asked questions about the Cybersecurity Act
The Act entered into force on 15 August 2026, at the same time as the Critical Entities Resilience Act. It replaces the former Network and Information Systems Security Act and transposes the European NIS2 Directive into Dutch law. Over eight thousand organisations fall under it, considerably more than under the old law.
NIS2 is the European directive; the Cybersecurity Act is the Dutch law that implements it. For you, the Dutch text counts, including the sector-specific detail in ministerial regulations. If you want to know what the directive itself means for bespoke software you commission, see NIS2-compliant software development.
Yes. Organisations that fall under the Act must register in the national entity register managed by the NCSC. You determine for yourself whether you fall under it; no letter will designate you. After registration you receive threat information and support from the CSIRT for your sector, which is one of the few direct benefits of the Act.
In three stages: an early warning within twenty-four hours, a fuller incident notification within seventy-two hours, and a final report no later than one month afterwards. Note from when that month runs: from the first notification, not from the moment you discovered the incident. This is often misread and in practice costs days.
Board members bear ultimate responsibility for risk management, must approve the measures and supervise their implementation. In addition, there is a training obligation, for which a two-year transitional period applies after entry into force. How liability will ultimately play out is a legal question; what you can do is ensure that it is demonstrable what the board approved and when.
Certification helps considerably, as a lot of the material overlaps. But the law requires measures that are appropriate and proportionate to your specific services, which is not the same as passing a standard. The duty of care also explicitly extends to your supply chain. We reuse what you already have; what's usually missing is the link between your control measures and the risks the law is aiming at.
The Cybersecurity Act concerns digital resilience and applies to over eight thousand organisations that must register themselves. The Critical Entities Resilience Act concerns physical resilience, applies to a few hundred organisations and works through designation by a ministry. Some organisations fall under both and therefore have two files with different deadlines.
That depends on your size, how much is already in place, and whether the supplier portal and evidence integrations need to be included. The risk and measures register is usually quick to put to use and gives you an immediate overview; the integrations and portal cost more. We provide a reasoned estimate after the discovery phase.
Making your duty of care demonstrable?
Take one measure you have implemented and try to write down which risk it covers, who decided that and when. If you cannot do that within a few minutes, that is where the work lies. We build this both as a standalone application and as part of a broader custom software development project.