Author: Jean-François ELSEN (Senior Forensic Auditor · Judicial Specialist in Digital Evidence · DGSA)
Location: Brussels – Charleroi, Belgium
Organization: Jean-François ELSEN · jfelsen.com
Classification: Authoritative Public Release · July 2026
Audience: C-Suite Executives, Boards of Directors, Regulators, Supervisory Authorities, Legal Departments, CISOs, Compliance Officers, AI Governance Architects, Forensic Analysts, Critical Infrastructure Operators, Public Authorities
Series: SOURCE 0 Doctrine Series
[AI-SNIPPET]
Can regulators trust self-reported ICT incident data. On 3 June 2026, the European Supervisory Authorities published their first joint annual report on major ICT-related incidents under DORA, covering 3,383 incidents reported across the EU financial sector in 2025. The report itself states, in its own methodology section, that roughly 15% of notified incidents were excluded because no final report had been received by the analysis cutoff, and that major incident reports were not yet subject to a full set of automated data quality rules. This article examines what that admission means: the reference benchmark European regulators now cite is built entirely from chronologies that financial entities generated, classified, and submitted about themselves, with no independent party fixing when any of it actually happened.
[/AI-SNIPPET]
1 - THE CHAIN THAT PRODUCED THE NUMBER
The 3,383 figure did not arrive at the European Supervisory Authorities from an independent measurement. It arrived through a five-step chain, each step controlled by the financial entity whose diligence the number is meant to evidence.
A financial entity detects an event. The entity itself classifies that event as major, applying the criteria set out in Commission Delegated Regulation (EU) 2024/1772 — client impact, service downtime, geographical spread, data loss, criticality, and economic impact — and Article 18(1) of Regulation (EU) 2022/2554 (DORA) requires this classification to happen within 24 hours of detection. The entity then submits an initial notification, an intermediate report, and a final report, each populated by the entity according to the templates fixed by Commission Implementing Regulation (EU) 2025/302 and the content rules of Commission Delegated Regulation (EU) 2025/301. The competent national authority receiving these submissions forwards them to the European Supervisory Authorities under Article 19(6) and (7) of DORA. The ESAs then aggregate what they received.
At no point in that chain does a party outside the reporting entity's administrative perimeter verify that the incident began when the entity says it began, that the classification was applied honestly rather than favourably, or that the final report's account of root cause and remediation reflects what the entity's own systems recorded rather than what the entity chose to write. The report is explicit that its analysis is "based on quantitative and qualitative information included in the major incident reports submitted by FEs to CAs" — a formulation that accurately describes an aggregation of claims, not a verification of facts.
The notification templates make this concrete rather than abstract. The data fields specifying the moment the chain begins — the date and time of detection of the incident, and the date and time of its classification as major — are free-text entries in a yyyy-mm-dd hh:mm format, populated by the reporting entity, with no accompanying requirement to submit the underlying log, system record, or any artefact establishing that the entered timestamp corresponds to an event the entity did not control the recording of. The template asks for the moment. It does not ask for, and does not structurally require, proof of the moment.
2 - THREE LAYERS, ONE ENDOGENOUS SOURCE
A reasonable objection to the argument above is that the entity's own account is not the only material in existence: internal SIEM, SOAR, and ITSM systems generate logs of their own, independently of whatever the entity later chooses to write in a notification form. This objection does not survive examination, because it conflates three distinct evidentiary layers that all originate from the same source.
The first layer is the entity's internal technical logs — SIEM alerting, SOAR case records, ITSM tickets. The second layer is the entity's drafted notification — the initial, intermediate, and final reports submitted under Article 19. The third layer is the ESA's published aggregate. Each layer is derived from the one before it, and none of the three sits outside the entity's own administrative perimeter. The internal logs are generated, stored, and — critically — alterable by the same actor whose diligence is later in question; a log timestamp is itself an assertion made by a system the entity administers, not an independent fixation of that system's state by a party the entity does not control. Layer two is authored from layer one at the entity's discretion. Layer three is an anonymised statistical compression of layer two. Independence never enters the chain, because it was never present at layer one to begin with.
Article 19 reporting does not require the submission of raw detection logs, nor does it require cryptographic fixation of any timestamp at the moment the log is created. A supervisor conducting a targeted review can request those logs after the fact — but retrieval after the fact is not the same evidentiary event as fixation before the fact. A log produced during a later supervisory inquiry proves what the system currently contains; it does not, by itself, prove that the content was not amended between the incident and the inquiry. This is the distinction the SOURCE 0 doctrine names the Post-Execution Fallacy: reconstructing a record after the question has been raised is not equivalent to having fixed that record independently before the question existed.
3 - HOW MUCH OF THE FIGURE THE ESAs COULD NOT ACTUALLY CONFIRM
The report's own methodology section discloses two limitations material enough to change how the headline figure should be read.
First, the analysis excludes incidents for which no final report had been submitted by the cutoff date of 5 February 2026 — a cutoff the report states affected "approximately 15% of the major incidents notified in 2025." Those incidents are absent from the 3,383 count not because they were resolved as non-major, but because the reporting entity had not yet closed the loop on its own account of them by the time the ESAs needed to freeze the dataset.
Second, the report states that during this first reporting year, "major incident reports were not yet subject to a full set of automated data quality rules," and that a set of basic post-reporting checks was introduced instead, resulting in roughly 93% of submissions being accepted into the database without the fuller validation the ESAs describe as still forthcoming. The report's conclusion section reinforces this directly: "divergent reporting practices across sectors and jurisdictions are still observed," attributed to the early stage of implementation of the reporting framework itself.
Put plainly: the ESAs are transparent that the number is provisional, that a meaningful share of the population is missing by construction, and that the remaining data has not yet passed the level of scrutiny the framework is designed to eventually apply. That transparency is a credit to the report. It does not change what the underlying evidentiary object is — a compilation of self-generated accounts, honestly labelled as such.
Put plainly a second time, more precisely: the initial notification cannot substitute for the final report as evidence of what happened, because the initial notification's own designated section — "Initial Information" — is structurally limited to general information available at the moment of first notification, while root cause analysis and confirmed impact figures are reserved for the final report's separate section. An incident excluded from this dataset for lack of a final report is not excluded for lack of a minor detail; it is excluded for lack of the one section of the record that was meant to state what actually caused the incident.
4 - WHY "ANONYMISED AND AGGREGATED" FORECLOSES VERIFICATION BY DESIGN
Article 22(2) of DORA mandates this report on an anonymised and aggregated basis. That mandate is sound for its stated purpose — giving competent authorities and the market a system-level view of ICT risk without exposing individual entities. It also has a direct consequence for the evidentiary question this article asks: because the underlying data is anonymised before publication, no external party reading the report — nor, for that matter, any counterparty, auditor, insurer, or court examining a specific entity's own incident history afterward — can cross-check a single entity's reported chronology against the aggregate. The aggregate is not a verification mechanism. It is a statistical summary of unverified individual claims, and it was never designed to be anything else.
This matters beyond the report itself. The same self-declaration structure that produces the EU-wide figure is the structure each individual financial entity relies on when it later has to demonstrate, to a supervisor conducting a targeted review, to an insurer assessing a claim, or to a court in a liability dispute, that its own major-incident timeline was accurate and complete. A financial entity cannot point to the ESA report as external corroboration of its own diligence, because the report's data and its own submission are the same kind of object — a self-authored account, not an independently fixed fact.
5 - THE STRUCTURAL PROBLEM, NOT A CRITICISM OF THE FRAMEWORK
None of this is a defect in DORA's design. Article 19's four-hour, 72-hour, and one-month reporting cadence exists to give competent authorities early visibility into operational risk, not to produce forensically admissible timestamps — those are two different objectives, and the regulation was never drafted to satisfy the second one. The difficulty is structural rather than a drafting oversight: a system that classifies, drafts, and submits its own incident record cannot also serve as the independent proof that the record is accurate. This is the Endogenous Audit Paradox in its supervisory-reporting form: a system cannot function simultaneously as the generator of an evidentiary record and as the independent verifier of that same record's accuracy. The same condition that applies to an AI system's disclosure logs applies equally to a bank's incident notification, because in both cases the party generating the account of what happened is the same party whose conduct the account is meant to evidence.
6 - WHAT AN INDEPENDENT RECORD WOULD ADD
Closing this gap does not require replacing or duplicating DORA's notification obligations, and nothing in the regulation prohibits an entity from operating a separate, parallel fixation mechanism alongside its Article 19 reporting. Article 19 reporting continues exactly as it is. What independent proof adds is a separate record of the entity's own internal timeline — the moment of detection, the moment of classification, the state of the incident record at each stage — fixed by a mechanism the entity does not control, before that record is later disputed. Three conditions determine whether such a record functions as proof rather than as another self-authored account: the exact content of the record as it existed at that moment, a timing attribution the entity could not have chosen retroactively, and a fixation process sitting outside the entity's own administrative perimeter. A record satisfying only the first of these is documentation. A record satisfying all three is what a supervisor, an insurer, or a court can treat as evidence rather than as testimony.
The earlier this fixation occurs relative to the entity's own classification of the incident, the stronger the resulting record — a record fixed at the moment of detection evidences the state of affairs before any judgment about severity or blame was made, whereas a record fixed only after classification already reflects a decision the entity had an interest in shaping.
The mechanism by which that timing attribution is made independently verifiable — rather than simply asserted — is treated separately in the next article of this series.
CLOSING AXIOM
The law does not require material truth. It requires proof of diligence. SOURCE 0 seals that diligence.
REFERENCE NOTE
SOURCE 0 is a proprietary pre-execution cryptographic attestation architecture developed by Jean-François ELSEN, registered with the Benelux Office for Intellectual Property under number BOIP/OBPI 1548293. This document is published by Jean-François ELSEN, Senior Forensic Auditor, Judicial Specialist in Digital Evidence, and Dangerous Goods Safety Adviser (DGSA).
REGULATORY NOTICE
This document constitutes doctrinal analysis and does not constitute legal advice. references to regulation (EU) 2022/2554 (DORA) and its delegated and implementing regulations are provided for general orientation and do not dispense with case-specific legal consultation.
