That was one of the clearest takeaways for us after attending the INCIDENTRON launch in Brussels on 25 February 2026. As contributors behind DORApp, we did not leave that event thinking about software features first. We left thinking about operational reality — what actually happens inside an organisation when a serious cyber incident hits, multiple reporting clocks start running, and the business is still trying to contain the damage.
The European regulatory environment is becoming more demanding, not less. NIS2 establishes a common cybersecurity framework across 18 critical sectors in the EU, and DORA has applied to financial entities since 17 January 2025.
For software vendors and the organisations that depend on them, that matters in a very practical way: it raises the bar for what "responsible cooperation" looks like when something goes wrong. The compliance question is no longer hypothetical — it's already shaping procurement decisions, audit findings, and vendor evaluations across critical sectors.
What INCIDENTRON is built to solve.
The INCIDENTRON project itself is built around exactly that challenge. According to the project's official description, it aims to streamline cyber incident reporting across Europe under multiple overlapping frameworks, with a modular open-source approach to end-to-end reporting support.
That ambition is what made the Brussels event so relevant to us: it validated a problem we already see in the market — that incident reporting in 2026 is not a single conversation with a single regulator, it's a parallel set of conversations, each with its own clock and its own format.
The most important message from Brussels.
The most important message we took home was simple, and it's worth quoting in full:
One incident should be handled as one operational event inside the organisation, even if it creates multiple legal obligations outside it.
The Brussels presentation illustrated this with a scenario every regulated company will recognise: a critical incident lands, and within minutes it has raised questions across five separate functions — each with its own clock, vocabulary, and reporting obligation.
Each of those questions has a different audience and a different deadline. If they're answered in parallel by separate teams reading from separate playbooks, the organisation ends up paying twice — once in coordination overhead, once in inconsistency between reports.
A grounded conclusion: promising, but still developing.
We also came away with a practical conclusion. Projects like INCIDENTRON are promising, but they are still developing. The official project site describes an open-source, policy-driven infrastructure, and the Brussels event positioned it as a future operational layer — one that could complement a "single entry point" style submission model rather than replace all national or sector-specific realities overnight.
That makes the direction interesting, but it also means buyers and vendors should stay grounded. The need is real today, even while some of the broader ecosystem is still taking shape. The organisations that get ahead won't be the ones waiting for a perfect platform — they'll be the ones who treat their internal incident handling as one connected operational story right now, regardless of what tools eventually arrive to support it.
Evaluate vendors by what they understand, not just by what they can build.
Do not evaluate software vendors only by what they can build. Evaluate them by whether they understand the environment you operate in when things go wrong. In the NIS2 and DORA era, resilience is not just about infrastructure, and compliance is not just about forms.
We design and build for the moment things go wrong — not just for the demo.
At U-centrix, we build software for organisations operating under NIS2, DORA and overlapping regimes — including DORApp, our incident reporting platform already used by 30+ institutions across Slovenia, Germany, and Latvia. Let's talk about where your incident process actually breaks under pressure.
Talk to us about your incident process