Custom app development for on-site resilience
Under the Wwke you must report a disruption to the competent authority within twenty-four hours. That clock does not start in the office but at the location where something goes wrong, often an unmanned site without signal. What is recorded there at the time determines whether the report is accurate. What is reconstructed afterwards takes time you do not have.
Why resilience starts on site
The Critical Entities Resilience Act has applied since 15 August 2026 and concerns physical resilience: sabotage, terrorism, natural disasters and other major disruptions. Critical entities are designated by their ministry and must then take and test technical, organisational and physical measures.
The word physical is decisive here. The measures the law refers to sit outside: fences, access doors, camera setups, emergency power, pumps, switching stations. They are checked by people who drive past them, not by a system that receives an alert. And those people work in places where the connection drops out.
The problem therefore shifts from the file to the recording. A resilience plan is of little value to supervisors without evidence that checks and exercises actually took place. And in the event of a disruption, what was recorded at the time matters, because the report within twenty-four hours must rest on it.
How we build this
The round is the unit here. If it is fixed which object was seen when and by whom, both the accountability and the report follow from it.
We go along to the sites to see how someone records things now and where coverage drops out. That shapes the design more than the legal framework does.
Which assets belong to which critical process, and what needs checking on each one. A round without that integration is just a walk, not evidence.
The app works without a connection and syncs later, with a visible status for each round. On unmanned sites, that is the requirement rather than the edge case.
We simulate a disruption and check whether everything the notification needs has been recorded on site. Whatever is missing then will also be missing later.
What the app does in practice
The app does little, and that little must always work, at night, in the rain and without signal. Which components you need depends on the number of sites and on who goes out.
Inspection rounds past critical assets
For each round, which assets are due and what must be checked. The app guides the round and records what was seen, so it is clear afterwards which asset was inspected when.
Demonstrable presence at the asset
A scan or tag at the asset proves that someone was actually there. Without it, a ticked-off round is just a claim, and under supervision that is the difference between evidence and paperwork.
Reporting a disruption from the site
If someone finds something, recording starts right there: what, where, when and with what consequences. That data forms the basis for the notification within twenty-four hours.
Photo with time and place
A damaged fence, an open door, water in a basement. For a disruption, a photo with time and location is the most convincing piece of evidence and the quickest to capture.
Fully offline operation
Rounds, reports and photos carry on without a connection and sync later, with each round showing whether that succeeded. Switching stations and pump houses rarely have any signal.
Access and visitors on site
Who was there, for what reason, and who let them in. After a disruption, the first question is who was on the site in the hours before, and you cannot answer that from a logbook in a cabin.
Who we build for
The nature of the sites determines what the app looks like. Four situations.
Drinking water and water boards
Scattered, unmanned assets that seldom see anyone. The round is the main means of control here, and there is usually no connection.
Energy, grid operators and installations
Switching stations, transformer buildings and sites with restricted access. Alongside inspection, what matters here is being able to demonstrate who was allowed in where, and when that access was used.
Government and public locations
Many buildings with varied functions and security levels. The challenge is knowing, for each building, which critical process depends on it, so that a round is tailored to it.
Healthcare and utilities on site
Emergency power, medical gases, cooling and access to wards. The checks often already exist, but they are on paper and therefore hard to trace under supervision. Resembles the work of an inspection app, with a different purpose.
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 app is the field side of the resilience file and not a separate administration. What it records ends up in the same register that carries the risk assessment and the measures.
Why Appfront
The 24-hour clock starts on site
What is recorded on site at the moment itself forms the notification. We build the recording in at the point of discovery, not when the notification is drafted.
No signal is the normal situation here
Unmanned sites and technical rooms rarely have a connection. Offline is therefore the starting point; an app that stops working there won't get used.
A round without evidence is just a claim
We link every check to an asset and to proof of presence, because in supervision that is the difference between demonstrating compliance and simply claiming it.
One file, not a second version of reality
The app writes in the same way as the office side, via integrations. See the Wwke software for that side.
Security and privacy
This app holds a map of your vulnerabilities: which assets are critical, where they are, when they are checked and where the fence is broken. On a device that leaves the building with someone, that is a real risk. We therefore limit what sits offline on the device to the current rounds, tie permissions to both the user and the location, and make sure a lost device can be disconnected remotely without stopping anyone else's work.
Recording people requires its own consideration. Access and visitor data are personal data and should not be kept longer than necessary for the purpose for which you collect them. We therefore set a retention period rather than keeping everything, and separate resilience records from personnel files. What the app records as evidence, photo, time and employee, must, by contrast, be tamper-proof. How we handle security ourselves is set out in our information security policy; reports from outside go through our vulnerability disclosure policy.
Frequently asked questions about the resilience app
A paper logbook in a site cabin does not prove that someone was at the object, and in the event of a disruption it cannot be searched quickly enough. The law requires you to test measures and to be able to demonstrate them; that calls for recording with time, place and person at the moment itself. That is precisely what a paper round does not deliver.
Not mandatory, but sensible. After designation you generally have nine months for the risk assessment and ten for the measures, and testing them is part of that. If you only start recording control rounds then, you will have no history at the moment you must account for them. Waiting therefore costs no money, but it does cost evidence.
Yes, that is the starting point. The app stores rounds, reports and photos locally and synchronises as soon as connectivity returns, with each round showing whether that succeeded. Without that capability, the app is bypassed on unmanned sites, and the record then does not exist after all.
The notification must describe what has happened and what its consequences are. If the finding was recorded on site with time, location and imagery, you do not have to reconstruct it, and the notification begins with facts. Drafting and submitting the notification remains human work; the app supplies the material.
Usually, yes. Rounds are often walked by an external party, and that party can work with the same app under its own roles, with access only to the locations it attends. What you want to avoid is the evidence of your resilience sitting in your security supplier's system rather than your own.
The actions look similar, the purpose does not. An inspection app tests against a standards framework and produces an inspection report. This app demonstrates that critical objects are being guarded and that measures are being tested, and it is tied to your critical processes rather than to a standard.
The Cbw concerns digital resilience and has its own reporting chain with different deadlines. The Wwke concerns the physical side. If you fall under both, it is sensible to maintain a single overview of dependencies and to draw two accountability records from it.
That depends on the number of sites and assets, whether access logging is needed and how demanding the offline functionality must be. Rounds with logging are usually quick to become usable; access logging and integrations cost more. We give a reasoned estimate after the discovery phase.
Recording patrols and disruptions in a verifiable way?
Join one patrol and count how much of what is observed actually gets recorded. That gap is what you miss in supervision. We build this as a standalone app and as part of a broader custom app or bespoke software project.