Custom Wwke software development for critical entities
The Wwke works differently from most obligations: you don't fall under it automatically. A ministry designates you as a critical entity, and only from that moment do the clocks start. Nine months for the risk assessment, ten for the measures. That may sound generous, but it isn't, because physical measures for buildings, sites and staff have lead times that take no notice of your deadlines.
Why designation is the decisive moment
The Critical Entities Resilience Act (Wet weerbaarheid kritieke entiteiten) came into force on 15 August 2026, alongside the Cybersecurity Act. It implements the European CER Directive and concerns something different from cyber: resilience against sabotage, terrorism, natural disasters, outages and other major disruptions. Around five hundred organisations are expected to be designated, across sectors such as energy, drinking water, transport, healthcare, banking and government.
The difference from the Cybersecurity Act lies in how you come to be covered. Under the Cbw you assess that yourself and register. Under the Wwke the responsible ministry designates you, and only then do the obligations arise. From that designation you have, in principle, nine months to complete a risk assessment and ten months to implement technical, organisational and physical measures.
Herein lies the trap. If you wait for designation, you start with ten months for work that takes longer: camera installations, access control, background screening of staff, changes to sites and continuity arrangements with suppliers. The organisations handling this well are already mapping their resilience now, so that designation becomes an administrative event rather than a starting signal.
How we build this
Here the critical process is the unit, not the department. Once you know which process must not fail and what it depends on, the rest follows from that.
Which service must under no circumstances fail, and what is needed to deliver it? Buildings, installations, people, suppliers and systems. In most organisations, that picture does not exist in one place.
Not just cyber, but power outages, water damage, sabotage, the loss of a key person and the failure of a single supplier. The Act asks for a broad view, and that is the hardest part. If you already have a RI&E with action plan, we reuse that methodology.
Every measure gets an owner and a realistic lead time. Physical measures carry delivery times and permits, which don't always fit within ten months.
We build the schedule as if designation falls today. Whatever proves unachievable is precisely what you need to set in motion now.
What the software actually does
The register of critical processes and their dependencies underpins everything. Which components you need depends on your sector and on how many locations you manage.
Critical processes and their dependencies
Per service, which locations, installations, people and suppliers are needed to deliver it. This integration makes visible where a single failure affects multiple processes, which is exactly what the risk assessment needs to demonstrate.
Tracking the nine- and ten-month clock
From designation, two deadlines run in parallel, each measure with its own lead time. The system shows which measure will miss its deadline while there is still time to accelerate.
Measures per location and asset
Physical resilience is location-bound. Access control, CCTV, emergency power and perimeter security are recorded per location, along with their current condition.
Personnel resilience recorded
Background screening, access rights to sensitive locations, and the question of which roles are indispensable. If a key person is lost, what matters is whether you had identified that risk in advance.
Incidents and disruptions recorded
A disruption with significant consequences must reach the competent authority quickly. Recording starts at the moment itself, with an app on site, and not when the report is drafted.
Exercises and reassessments retained
When exercises took place, what went wrong and what was done about it. A resilience plan that has never been tested is, under supervision, just a paper plan.
Who we build for
The sectors that are designated differ greatly in what determines their resilience. Four situations.
Drinking water and energy
Your critical processes depend on physical installations at dispersed locations, often unmanned. The resilience question here concerns access, outages and recovery, and much less about offices.
Transport and logistics
Your service runs across hubs and through parties that are not yours. Dependency on suppliers is the core of the risk assessment here and the hardest to pin down.
Healthcare
Continuity here means care carries on while something fails. Alongside the physical side, the question is which systems and which people are indispensable, and both belong in the same file. You set up the reporting chain separately; see the incident reporting portal.
Government and public services
You often manage many locations with varying functions and security levels. The challenge is not to arrange something building by building, but to determine which buildings are critical for which service.
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
Which organisations are precisely designated, and which requirements apply to each sector, will be filled in after entry into force. Everything connected to that should be configurable.
Why Appfront
The clock starts at designation, the work starts earlier
Physical measures have lead times and sometimes permits. We plan as though designation falls today, so it becomes visible what you need to start now.
Physical and digital in one file
The Wwke covers sabotage and natural disasters, the Cbw covers cyber. If both apply to you, you want one dependency overview and two accountability records, not two separate systems.
Connecting to what you already manage
Location data, access systems and maintenance schedules already exist. We connect to them through integrations instead of retyping them.
Honest about what is not yet settled
Exactly who will be designated and which requirements apply per sector is still being determined. We build the structure and make no claims about the detailed rules.
Security and privacy
This file describes where your organisation is vulnerable and which locations matter. That is more sensitive than an ordinary security file, because it concerns physical objects that someone could approach. We therefore set access by role and by location, so that a manager of one site does not get the picture of the whole, and we log every inspection.
The personnel side needs extra care. Data on background checks and on which roles are indispensable touches the private lives of your staff, and the privacy legislation applies to it in full. We keep only the minimum there: the outcome and its validity date, not the investigation itself. How we ourselves handle security is set out in our information security policy; reports from outside come through our CVD policy.
Frequently asked questions about the Wwke
The House of Lords adopted the bill on 7 July 2026, and the Act came into force on 15 August 2026, at the same time as the Cybersecurity Act. It transposes the European CER Directive. Unlike under the Cbw, the obligations do not apply to everyone straight away, but only once an entity has been designated.
The ministry responsible for your sector designates critical entities; it is expected to involve several hundred organisations. You cannot determine this yourself, and you do not need to register. If you provide a service whose disruption would have a severe societal impact, the likelihood is real. Preparing before you know is the most sensible stance under this instrument.
In principle, nine months for the risk assessment and ten months to implement the technical, organisational and physical measures. These deadlines run in parallel, not one after the other. For physical measures with long lead times or permit requirements, ten months is tight, which is why you should not postpone the inventory.
The Cbw concerns digital resilience, applies to over eight thousand organisations and works through self-registration. The Wwke concerns physical resilience, applies to several hundred organisations and works through designation. If you fall under both, these are two separate files with their own deadlines, but with largely the same underlying dependencies.
An incident that causes a significant disruption to your service must be reported to the competent authority within twenty-four hours. What counts as significant depends on your sector and on the detailed rules. In practice, this means the documentation must be made during the disruption, not afterwards, because reconstructing events after the fact takes longer than you have.
It is a good start and saves a lot of work. What the law requires on top of that is that you make dependencies explicit for each critical process, that measures are linked to identified threats, and that you can demonstrate that you have exercised. A plan that sits in a drawer and has never been tested does not meet that requirement.
The obligation rests with you, but your resilience depends on parties outside your organisation. The risk assessment must make that dependency visible, which in practice means you will need to record continuity agreements with suppliers you currently contract on trust. That is usually the longest-running part of the work.
That depends on the number of locations, how much is already in place and whether integrations with existing systems are needed. The register of critical processes with dependencies is usually quick to put to use and gives immediate insight; location management and integrations cost more. We give a reasoned estimate after the discovery phase.
Preparing for designation?
Take one service that must not fail and try to write down what it depends on: which locations, which people, which suppliers. Where that list becomes vague is where your risk assessment lies. We build this both as a standalone application and as part of a broader custom software project.