Custom incident reporting portal with a 24-hour workflow
The Cybersecurity Act has applied since 15 August 2026. If you fall under it, you must send an early warning within 24 hours of a significant incident and a full notification within 72 hours, both counted from the moment you became aware of the incident. The final report follows within one month, but that month is counted from the 72-hour notification. So there are two starting points, and that is where things go wrong in practice.
What the reporting obligation requires of you
The Cybersecurity Act is the Dutch implementation of the European NIS2 Directive and took effect on 15 August 2026, alongside the Critical Entities Resilience Act. It affects eighteen sectors and over eight thousand organisations, which must themselves determine whether they qualify as an essential or an important entity. The Act imposes three things: a duty of care for your measures, a registration duty requiring you to register your organisation in the entity register on MijnNCSC, and a reporting duty. The latter is bound to strict deadlines.
The chain has three stages and two reference points. Within 24 hours of becoming aware of a significant incident, an early warning is sent. Within 72 hours of that same moment, the full notification follows, setting out what you then know about the nature, scope and impact. The final report is due within one month after that notification, not within one month of discovery; that saves you three days, and it is the error most often found in incident plans.
If the incident lasts longer than that month, the closing deadline shifts. At that point you send a progress report, and the final report follows within one month after the incident has been resolved. In addition, your CSIRT or supervisory authority may request an interim report at any time; that is different from the progress report, and it comes at their request, not on your timetable.
Two exceptions change your entire setup. If you are a trust service provider, the second deadline is 24 hours rather than 72. And if you fall under a European sector law with its own reporting rules, such as DORA for the financial sector, you report through that route rather than this one. Establish this before you build anything, because it determines whom you report to and within what deadline. The NCSC describes the reporting chain and the exceptions at ncsc.nl.
You report via the central reporting point on MijnNCSC, and that one report reaches both the sectoral CSIRT and your regulator. That is the easy part. The difficult part comes before it: someone has to notice that something has happened, judge whether it is significant, and start the clock at the right moment. Where that happens by email and a group chat, the first thing a regulator finds missing is not the report itself but the time of discovery.
The reporting chain is one obligation within a larger whole. The duty of care around it, with the justification for each measure, is covered in Cybersecurity Act software; if you are designated as a critical entity, the Wwke also applies, with its own reporting deadline.
At a Seveso site, the report begins at the installation itself, during a round or an exercise. For how to record that, see the Seveso app.
In healthcare, a second reporting chain runs with its own deadlines: three working days after establishment, reported to the inspectorate. See Wkkgz software. Reporting on the shop floor begins with the reporting app.
When work is carried out on an installation, the cause of an incident often lies in the release that preceded it: what was made safe and who signed it off. That chain is covered in the app for work permits and making safe.
Reports from employees about suspected wrongdoing run through a different channel, with protection of the reporter at its core. See the app for the internal whistleblower scheme.
How we build your reporting portal
The thresholds are set out in the ministerial regulation for your sector; how you apply them to a concrete signal remains a matter for you and your lawyer. What we build is the system that carries out that assessment, records it, and attaches deadlines to it.
Who notices an incident, who assesses whether it is significant, who may report on behalf of the organisation, and who takes over outside office hours. In most organisations this is written down nowhere, and it is the first place where 24 hours are lost.
The thresholds from your sector's ministerial regulation, the timers, and the points at which the system escalates. If your regulator's guidance changes, you adjust it without any rebuilding.
This is the part that has to work during a real incident, so that is where the build begins. Your own people run an early exercise with an interim version, because that is where you learn whether the route holds up.
We walk through an incident from signal to final report and see where it stalls. It is rarely the technology; it is usually the question of who decides at night.
What the portal does in practice
A reporting obligation only becomes a working chain once each of these six steps is assigned to someone. How many of them you need depends on your size and on the number of signals that come in.
A single point of entry for signals
Alerts from your own organisation, your suppliers and your monitoring arrive in one place via integrations, each with a timestamp. While signals travel by email, the moment of discovery can no longer be established after the fact.
Assessment against your sector's thresholds
The threshold values differ by sector and are set out per department in ministerial regulations. The assessment becomes a fixed set of questions that follows those thresholds, with the outcome and its justification recorded. A no is also a decision you want to be able to show.
Two timers side by side
The first runs from the moment of awareness and monitors the 24 and 72 hours. The second only starts when the full report is sent and monitors the month that follows. If the incident continues, it switches over to the progress report and counts again from resolution.
Structure of the three messages
The early warning, the full notification and the final report build on one another, so what you knew at the 24-hour mark does not need to be repeated, and later updates add to the record visibly instead of overwriting it.
Escalation that cannot quietly stall
If the first responsible person does not respond within the agreed time, the signal moves up the chain. An incident that starts on Saturday evening must not be discovered on Monday morning.
Incident file
The timeline, the assessments, the messages sent and the measures taken, all in one place. This is what you need for a final report and what a regulator will ask for.
Who we build for
The eighteen sectors differ considerably, but the notification chain breaks in the same place every time: the question of who decides outside office hours. Four situations where that plays out differently.
Government and public services
Here the notification obligation sits alongside existing duties, including the reporting of data breaches. If you work with the BIO security framework, the measures overlap considerably, but the reporting routes differ.
Healthcare
An incident here directly affects the continuity of care, which changes the assessment: a system outage becomes significant more quickly than elsewhere. The 24-hour deadline coincides with the moment when everyone is busy dealing with the outage.
Energy, water and transport
Heavily regulated sectors that often already have their own reporting practice with a sector-specific regulator. The pitfall is that two parallel routes develop that drift apart, while your risk register only knows one picture.
Manufacturing, digital infrastructure and service providers
Many organisations in these sectors are now subject to a notification obligation for the first time. Here the work begins with the question of who actually decides that a report should be made. That is different from building NIS2-compliant software: that page covers the measures in your applications, this one covers the notification chain around them.
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
One design requirement here outweighs all others: this system must work at the moment your own environment may not. An incident can hit your network, and a reporting portal behind that same login is then useless.
Why Appfront
Two starting points, not one
The 24 and 72 hours run from awareness; the month for the final report runs from the notification itself. We record the moment of awareness at the first signal rather than at the decision that it is serious, and count onwards from the correct reference point.
Works when everything else doesn't
A reporting portal inside the same environment that has been hit is not a reporting portal. We keep it separate and ensure it remains accessible without your own network.
A no is also a decision
Most signals do not lead to a notification. It is precisely those assessments you must record, because a regulator's question concerns what you did not report.
Honest about what we don't do
We do not determine whether your organisation falls under the law, nor whether an incident is significant. That is the work of you and your lawyer. We build the system that applies and records your assessment.
Security and privacy
An incident file is one of the most sensitive documents in your organisation. It describes precisely which systems were vulnerable, how someone got in and how long it took before you noticed. In the wrong hands, that is a ready-made manual. We therefore keep access tight and per incident, not across the entire history.
The key design choice is that this system is kept separate from the environment that may be affected. A portal running on the same network, behind the same login and with the same administrative rights, would be unreachable at the very moment of an incident. Furthermore, the timeline for each incident is immutable: you can add to it, but not rewrite it, because a record in which the moment of discovery can be altered after the fact is of no value to a regulator. How we handle security internally is set out in our information security policy; reports from outside come through our CVD policy.
Frequently asked questions about the reporting obligation
Within 24 hours of becoming aware of a significant incident, an early warning, and within 72 hours of that same moment, the full notification. The final report is due within one month after that notification, not within one month of discovery. If the incident is still ongoing after that month, you submit a progress report at that point, and the final report follows within one month of the incident being resolved. A single notification goes to the sectoral CSIRT and to your supervisory authority.
At the moment you became aware of the incident, not when you establish that it is significant. That distinction is the crux of the problem: if a report reaches the service desk on Friday afternoon and is only assessed on Monday, the deadline has already passed. For this reason we record the first signal with a timestamp, even if the assessment follows later.
You must establish that yourself, and it is a legal assessment that we do not make. It covers eighteen sectors, and your size and role determine whether you are an essential or an important entity. The Dutch central government provides tools to check this. Our portal is concerned with what you do if you fall within scope.
No, and the criteria are not yours to set either: the thresholds differ by sector and are elaborated per ministry in ministerial regulations. The software applies those thresholds and records the outcome with its justification; the decision remains with a human. We deliberately build the assessment as a fixed set of questions that leads to a decision, so that nothing is improvised under time pressure and it is visible afterwards why a report was or was not made.
Then the reporting portal must still work, and that is why we place it separately from your production environment with its own access route. A system behind the same login as the affected environment would be unreachable at exactly the wrong moment. This requirement shapes the design more than any particular feature.
The routes are different, and so are the thresholds: a data breach concerns personal data and has its own 72-hour deadline towards the Dutch Data Protection Authority (Autoriteit Persoonsgegevens). A single incident can fall under both. What works is one point of entry and one timeline, with two outgoing routes that each monitor their own deadline, so that it is not recorded twice.
The reporting obligation is the visible half; the duty of care concerns the measures you take and in practice is the larger task. The two meet in the final report, in which you describe what you have done. A reporting portal is not a fulfilment of the duty of care, and we do not present it as such. For that side, look instead at a security assessment and your measures register. If you place products with digital elements on the market yourself, you additionally have the reporting chain of the Cyber Resilience Act, which runs to ENISA and concerns your product rather than your organisation.
That depends on the number of signal sources, your escalation rota and whether integrations with monitoring or the service desk are needed. The reporting chain itself is usually quick to put into use and delivers the most value; integrations cost more. If your team works from their phones, we'll build the reporting side as an app. We'll give you a reasoned estimate after the discovery phase.
Want an incident reporting portal built?
Walk us through one incident you had last year, from the first signal to the final email. In that conversation, it becomes clear where your chain loses time. We build this as a standalone portal and as part of a broader custom software project. To prevent misuse of your domain name, see DMARC and DNSSEC monitoring.