The Measurement Failure Inside Europe’s Incident Reporting Regime
Europe’s cyber information sharing problem is usually framed as a coordination failure, but the more expensive consequence is that mandatory incident data flows upward to supervisors and almost never returns as a rate.
Coordination Failure Is the Visible Problem
The European Court of Auditors, in findings reported by Infosecurity Magazine on 23 September 2026, named “insufficient exchange of information” as the weak point of the EU’s ability to respond to major cyber incidents. The detail is institutional friction: a lack of formally defined roles is hampering cooperation between national CSIRTs and the European Cyber Crisis Liaison Organisation Network (EU-CyCLONe), national security laws restrict what information can be shared, slow transposition of NIS2 into national law is having a negative impact, and two hubs of the European Cybersecurity Alert System had not begun operations due to procurement delays.
Every one of those findings is about response. The frame is coordination: who knows what, when, and whether the right bodies can act on it together in a crisis. When a major incident crosses borders and the picture does not, the cost is immediate and attributable.
But there is a second failure underneath it, and it is quieter and more expensive. Response needs shared indicators. Estimation needs shared rates. The two are not the same artifact, and the EU’s reporting architecture is currently optimized for the first while discarding the second. The consequence falls on every financial entity that must estimate loss event frequency for its own capital, insurance and control-investment decisions. That estimate is the single hardest input to source locally, because few individual organizations see enough loss events in their own history to establish a stable frequency distribution. Mandatory incident reporting regimes already generate exactly that input. The data exists. It flows upward to supervisors and almost never flows back down.
The Plumbing Was Costed, the Data Was Not
The clearest evidence is in the European Supervisory Authorities’ feasibility report on further centralizing major ICT incident reporting, produced under DORA Article 21. The report compares three scenarios: Baseline, built on the joint reporting tool that became mandatory from 17 January 2025; Data Sharing, feasible from roughly three years onward; and a Centralized EU Hub where entities report directly to one EU system, feasible from roughly five years onward because it needs legislative amendment. The comparison is expressed in CAPEX and OPEX. Baseline costs EUR 11.7 million in CAPEX and EUR 2.34 million per year in OPEX; Data Sharing costs EUR 9.3 million in CAPEX and EUR 1.86 million per year in OPEX; the Centralized Hub costs EUR 9.5 million in CAPEX and EUR 1.9 million per year in OPEX. Because Baseline costs are already sunk, the report concluded the Centralized Hub is the most expensive option in relative terms, with savings materializing only after roughly 20 years, if ever.
Two details in that analysis deserve more attention than the cost tables. First, the report scoped its cost analysis around named known unknowns, including the unknown total volume of incidents. The very quantity the regime is designed to observe was listed as an unknown in the paper evaluating the regime. Second, the options were compared only in CAPEX and OPEX, never as a reduction in loss exposure. A reporting architecture that sharpens every participant’s frequency estimate improves every control and capital decision built on it. That benefit does not appear anywhere in the comparison, because it was never quantified. The plumbing was costed. What the data would let anyone estimate was not.
This is the pattern worth naming. A regime that collects incident reports and returns nothing quantitative has not built a measurement system. It has built a filing system with a very expensive inbox.
What Gets Published Is Not a Frequency
The numbers that do reach the public illustrate the gap. A separate ENISA threat landscape report, cited in the same Infosecurity Magazine coverage, analyzed 8,257 incidents in the 2025 calendar year. Low-impact DDoS attacks accounted for 51 percent of recorded incidents, driven mainly by geopolitical tensions. Public administration was the most impacted sector at 32 percent; finance and banking was 6 percent. The reporting does not state how the incidents were collected.
That last sentence is the whole problem. A count of 8,257 without a collection mechanism and without a population denominator cannot be converted into a per-organization frequency. Without a denominator there is no rate, and a rate is what a quantitative risk model consumes. Loss event frequency is not “how many incidents were recorded somewhere in Europe last year”. It is the expected number of loss events per unit of exposure, per entity, per period. Counts without denominators cannot produce it.
There is a second distortion. The category that dominates the recorded count, low-impact DDoS, is not the category that dominates loss. Share of recorded incidents is not frequency of loss events, and most recorded is not most costly. Any analyst who feeds sector shares into a quantitative risk analysis as though they were loss event frequencies will systematically over-weight high-volume, low-severity noise and under-weight the low-volume, high-severity tail. The result is a loss exceedance curve with the wrong shape at exactly the end that matters for capital and insurance decisions.
Article 18 Is Already an Exceedance Rule
Read DORA’s major-incident classification as what it statistically is. Chapter III of Regulation (EU) 2022/2554, Articles 17 to 23, covers ICT-related incident management, classification and mandatory reporting of major incidents. Article 18 requires classification against six criteria: clients or counterparts affected, including transaction volume and reputational impact; duration; geographic spread; data losses across availability, authenticity, integrity and confidentiality; criticality of the services affected; and economic impact in direct and indirect costs and losses. The numeric thresholds for “major” were delegated to joint regulatory technical standards of the European Supervisory Authorities under Article 18(3).
Those six criteria plus a materiality threshold do something specific. They turn every reported major incident into an exceedance event: an incident whose measured impact crossed a defined severity line. A count of exceedances over a period is one point on a loss exceedance curve. That is precisely the tail that organizations find hardest to calibrate from internal history, because tail events are rare by construction. The classification log is therefore already a frequency dataset with a severity axis, provided the organization keeps the whole log rather than only what it filed.
Two habits determine whether that dataset is usable. Below-threshold incidents must be retained alongside major ones, and the criterion values must be recorded as values, not collapsed into a yes/no “major” flag. A flag discards the severity axis. A value preserves it, and the values are what allow an annualized loss exposure to be decomposed into loss event frequency and loss magnitude rather than guessed as a single number.
Magnitude is already attached to the same events. Joint ESA Guidelines JC 2024 34 on aggregated annual costs and losses of major ICT-related incidents require entities to estimate gross costs and losses per major incident, then recoveries, and the template links each incident to its DORA final report through the incident reference number. Frequency and magnitude are therefore recorded against a common key. That is the structure a Monte Carlo simulation needs: a frequency distribution on one axis, a severity distribution on the other, joined at the event.
The fix is two-sided. Organizations should treat their own classification records as the frequency and severity evidence for the quantitative risk model, rather than treating the filing as a compliance artifact and then commissioning a separate estimation exercise. Supervisors should publish aggregated counts with denominators: how many entities of each type reported, over what period, above which threshold. Shared indicators help response. Shared rates help estimation. DORA’s voluntary information-sharing chapter, Chapter VI at Articles 45 and 46, is built around the first.
One caveat matters more than any modeling choice: the criterion values are recorded by incident managers and control owners in the middle of an incident, under time pressure, with incomplete information. The analyst’s job is to turn their records into a rate. The estimate is only as good as that collaboration, and no amount of downstream modeling repairs a classification log where duration, geographic spread or economic impact were entered as guesses rather than observations. Quantification here is not a modeling problem. It is a record-keeping discipline shared between the people who see the incident and the people who price the risk.
A supervisory system that collects frequency but returns only anecdotes asks every organization to re-estimate from scratch the number it has already handed over.