NIS2, DORA and software vendors: what the INCIDENTRON launch in Brussels confirmed for us
Choosing a software vendor is no longer just a technology decision. In regulated environments, it is also a resilience decision, a governance decision, and increasingly a compliance decision. 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.
That matters because 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. In practice, this means that a single operational event can trigger different reporting and governance obligations at once, often with different thresholds, authorities, timelines and national interpretations.
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 frameworks such as NIS2, DORA, GDPR, the Cyber Resilience Act and the evolving Digital Omnibus discussion, with a modular open-source approach to end-to-end reporting support. That is why the event was so relevant to us: it validated a problem we already see in the market.
One incident, many obligations
The most important message from Brussels was simple: one incident should be handled as one operational event inside the organisation, even if it creates multiple legal obligations outside it. At the event, this was illustrated very clearly through a scenario where a critical incident immediately raised questions across security, legal, privacy, continuity and executive functions. Who leads? Which regulation applies? Which deadline starts first? Which authority needs to be informed? What data is missing? Those are not abstract compliance questions. They are the questions that appear while systems are down and the primary goal is still containment and recovery.
Copy of INCIDENTRON Launch
That is also why software selection in regulated sectors has changed. A polished demo, a competitive offer and a fast delivery promise are no longer enough. The real question is whether the vendor understands what happens after go-live, under pressure, when the organisation needs not just functionality, but structure, clarity and auditability.
What this confirmed for us as part of the DORApp journey
From our perspective, the event strongly confirmed that the direction behind DORApp’s incident reporting approach is the right one. The real pain point is not simply “submitting a report.” It is navigating overlapping legislative frameworks during operational chaos, while different teams need different pieces of information at different times. That is exactly why incident reporting cannot be treated as a simple form-filling exercise. It has to be treated as a guided operational workflow.
Copy of INCIDENTRON Launch
One of the more striking points raised at the event was that a significant share of financial entities reportedly spend between 4 and 24 hours on reporting activities alone during an incident, not on solving the incident itself, but on reporting it. If that is the case, the burden is not merely administrative. It directly competes with response capacity at the worst possible moment.
Copy of INCIDENTRON Launch
This is where we believe the market still underestimates the problem. During a major incident, the first instinct is naturally to restore services, limit damage and regain control. But the reporting burden does not wait politely in the background. It increases pressure exactly when internal clarity is lowest. Any vendor building for regulated sectors needs to understand that reality. Incident management and incident reporting cannot remain separate worlds forever.
The software-vendor questions that now matter most
After Brussels, we would frame the vendor-evaluation question slightly differently than before.
It is still important to ask how a vendor handles security during design, development, deployment and maintenance. It is still important to ask how they manage changes, releases, logs, dependencies and support. But for regulated buyers, that is no longer enough. The more revealing questions are these:
Can the vendor support structured decision-making during an incident, not just normal-day operations? Can they help define ownership, escalation paths and required data before an incident occurs? Can they reduce confusion across legal, compliance, ICT, privacy and executive stakeholders? Can they design a system that produces consistency under pressure rather than forcing teams back into email chains, spreadsheets and manually assembled reports? Those are the questions that now separate a useful vendor from a merely capable one.
Copy of INCIDENTRON Launch
In other words, buyers should not ask only whether the system works. They should ask whether the system helps the organisation remain in control when time, information and accountability are all under stress.
A note of caution from the event
One nuance we took away from the launch is that much of the discussion and many of the examples were GDPR-oriented, which makes sense given the composition of the roundtable and the stakeholders present. But for us, that also raised an important strategic question: how much of the current market conversation is truly centred on the operational realities of DORA-regulated financial institutions, and how much is still being shaped by broader data-breach reporting experience? That is not a criticism of the initiative. It is simply an important distinction for product positioning and for any partnership decisions we make in this space.
Copy of INCIDENTRON Launch
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 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.
Final thought
The lesson for regulated companies is straightforward: 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. It is about whether your organisation can move from incident detection to coordinated action, evidence gathering, reporting and follow-up without losing control of the situation.
For us, the Brussels event did not change the direction. It clarified it. The future of incident reporting in Europe will likely become more connected, more automated and more policy-aware. But the companies that benefit most will be the ones that prepare now: by defining ownership, structuring workflows, and choosing software partners that understand that one incident is never just one technical event. It is an operational, regulatory and organisational stress test all at once.
