SOURCE 0 - THE DORA NOTIFICATION PARADOX

WHY A BANK CANNOT PROVE ITS OWN INCIDENT TIMELINE, AND WHAT CLOSES THE GAP

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]

Under Regulation (EU) 2022/2554 (DORA), a financial entity facing a major ICT-related incident must state, to the competent authority, the exact moment it became aware of the event and the exact moment that event was classified as major, then meet fixed deadlines measured from those two moments. Both moments are recorded, exclusively, by the entity whose conduct is later scrutinised. Threat-led penetration testing, internal audit, and third-party oversight — the mechanisms usually invoked as independent verification — each test a different question, at a different time, and none of them fixes the antecedent state of a specific system before a specific incident occurs. This article sets out why that gap persists under the current DORA architecture, and what an independent, pre-execution fixation adds to it.

[/AI-SNIPPET]

1 - THE THREE INSTANTS DORA ASKS A BANK TO PROVE

Under Regulation (EU) 2022/2554, an in-scope financial entity facing a major ICT-related incident must establish three distinct instants: the moment it became aware of the event, the moment the event was classified as major, and the moment the initial notification reached the competent authority. Article 19, together with the applicable technical standards, fixes the initial notification within four hours of classification and no later than twenty-four hours from awareness, followed by an intermediate report at seventy-two hours and a final report within one month. Each of these three instants is a fact a regulator, a court, or an insurer can later dispute. Describing a fact and proving a fact are different operations, and the text of DORA specifies the first without supplying a mechanism for the second.

2 - WHO WRITES THE CLOCK

The instant of awareness is recorded in the entity's own incident management system. The instant of classification is recorded in the same system, by the same personnel, under the same operational authority. Of the three instants, only the notification itself is attested by an actor outside the entity: the competent authority's portal, which issues a server-side timestamp on submission. That third instant proves a message left the bank's systems at a stated time. It does not corroborate when the bank became aware of the incident, nor when it classified it as major — the two determinations a regulator actually disputes when notification appears to have taken longer than the rule allows. The instant that matters most to the regulatory clock is written entirely by the party under scrutiny.

3 - WHY THREAT-LED PENETRATION TESTING DOES NOT ANSWER THE QUESTION

DORA's testing chapter requires financial entities identified as significant to undergo threat-led penetration testing (TLPT) at least once every three years, under Articles 26 and 27, using threat intelligence from an independent provider and, at least once in every three testing cycles, an external red team operating against live production systems. This is a genuine test of resilience, not a documentary exercise. It answers a different question, however, than the one a regulator asks after a specific incident. TLPT establishes what an entity's defences withstood on the date of the exercise. It does not establish, for an incident occurring at any other date, what the entity's system state was at the moment awareness or classification is later claimed to have occurred. A three-yearly assessment of resilience is deterministic testing of a system; it is not cryptographic fixation of a specific decision at a specific moment. The two guarantees answer different questions, and the first does not supply the second.

4 - WHY INTERNAL AUDIT AND THIRD-PARTY OVERSIGHT DO NOT SUPPLY A WITNESS

Article 6 requires the ICT risk management framework itself — the governance document, not any individual incident — to be reviewed at least annually and subjected to internal audit by personnel with sufficient ICT expertise and independence from the function under review. Articles 28 to 44 extend a comparable oversight to critical ICT third-party providers, through registers of information and, for providers designated critical, direct examination by the European Supervisory Authorities. Both mechanisms audit whether a governance structure exists and functions as documented. Neither mechanism, by design, examines whether the antecedent state of one specific system, at the specific moment a later-disputed incident is claimed to have occurred, was independently fixed before the dispute arose. A system-level dossier answering "was this bank governed" is not a decision-level proof answering "what was true of this system at a stated moment on a stated day."

5 - THE POST-EXECUTION FALLACY, APPLIED TO A COMPROMISED BANK

Where the incident itself involves compromise of internal servers, the difficulty compounds rather than resolves. Reconstructing the moment of awareness from logs generated by the same environment that was compromised assumes the reliability of the very infrastructure whose integrity the incident places in question. Out-of-band sources — off-site backups, endpoint telemetry, identity-provider logs — can corroborate a compromised environment's account after the fact, where such sources happen to exist and happen to have survived the incident untouched. None of this was fixed in advance for the purpose of proving the incident timeline; it was fixed for operational continuity, backup policy, or an entirely different regulatory purpose, and its evidentiary use is fortunate rather than designed. Where the incident involves ransomware or an advanced persistent threat, this is not a hypothetical risk: erasing or altering the event logs that would reveal an intrusion's timeline is a standard step in such an attack. Post-hoc reconstruction from potentially compromised infrastructure does not merely rest on weaker evidence; in this case it frequently rests on evidence the attacker has already shaped. It does not substitute for an independent record sealed before the incident occurred.

6 - WHAT A QUALIFIED TIMESTAMP DOES AND DOES NOT SETTLE

A qualified electronic timestamp issued under Article 41 of the eIDAS Regulation benefits from a legal presumption that a given hash existed, unaltered, at a stated time. It does not verify the data underlying that hash, because the qualified trust service provider never receives that data — only its cryptographic fingerprint, submitted by the entity itself. A bank can therefore timestamp its own incident log at the moment of classification and demonstrate, to a legal presumption, that the log existed in that exact form at that exact time. What the timestamp does not establish is whether the classification decision recorded in that log was made when the log says it was made, rather than reconstructed and backdated before submission for timestamping. Under Belgian law, this distinction has an explicit statutory basis: the Law of 21 July 2016 transposing eIDAS expressly prohibits timestamping providers from claiming that a qualified timestamp produces date certaine. Date certaine, under Book 8 of the Belgian New Civil Code, is established exclusively through deposit with a Belgian huissier de justice — an actor who did not write the record and has no interest in what it says.

Automating the submission does not close this gap. Where an incident management system pushes a hash of each new log entry to a qualified timestamping provider in real time, the risk of a human deliberately backdating a record after the fact is reduced, but the system performing that push remains inside the entity's own control perimeter. An administrator with sufficient privilege can desynchronise the system clock feeding that pipeline, or alter the underlying database entry before the automated push fires, and no step in that sequence is visible to the timestamping provider, which only ever receives a hash. Depositing the configuration of the logging infrastructure itself with an independent third party at T-0 forecloses that specific manipulation path; tightening the automation of the push does not.

7 - THE GEOGRAPHY DORA ALREADY OCCUPIES

Three features of the present regulatory geography are worth stating plainly, without overstating what follows from them. DORA is a directly applicable EU regulation whose supervisory architecture runs through the European Supervisory Authorities and, for the euro area's significant institutions, the European Central Bank's Single Supervisory Mechanism, within a legislative process whose institutional origin sits in Brussels. SWIFT, the interbank messaging network that external forensic accounts of ICT incidents routinely cite as a corroborating source, has been headquartered in La Hulpe, Belgium, since 1973. And a substantial share of the European Union's fund and private-banking industry operates through entities domiciled in Luxembourg, a jurisdiction whose civil law, like Belgium's, descends from the Napoleonic Code. None of this makes a Belgian huissier deposit automatically opposable before a Luxembourg court or any jurisdiction outside Belgium — recognition outside Belgium remains, as stated throughout this doctrine, assessed case by case under the evidentiary rules of the forum seized. What it does establish is narrower and more precise: a Belgian evidentiary deposit is not a foreign import into this ecosystem. It sits inside the same geography DORA, SWIFT, and the Luxembourg-domiciled financial sector already occupy.

8 - WHAT THE HISTORICAL REALITY DOSSIER ADDS TO THE DORA TIMELINE

SOURCE 0 fixes the state of a defined system perimeter at T-0, before any incident, and deposits the resulting Historical Reality Dossier with a Belgian huissier de justice. Where a bank's ICT risk management framework, its configuration baseline, or its incident-detection tooling has been fixed in this manner in advance, the awareness and classification instants a later incident report must state can be tested against a record sealed by an actor independent of the bank — with no stake in what the record says — before the incident occurred, rather than reconstructed from the same infrastructure the incident has placed in doubt. This does not test whether the bank's cyber defences held; TLPT already does that. It does not test whether the bank's governance framework exists; Article 6 already does that. It answers a narrower and, once an incident has occurred, more consequential question: what was independently established to be true of this system before anything happened.

The mechanism is narrower than a general assurance of good faith, and should not be read as more than it is. Fixing the baseline configuration, the reference logs, and the alert-correlation rules at T-0 does not certify that the awareness or classification timestamp later recorded for a specific incident is accurate. What it forecloses is the entity's ability to alter, after the incident, the same detection rules and thresholds it will rely on to argue when it could or could not reasonably have known. The fixation bears on the antecedent capacity to detect, not on the incident timeline itself — but a regulator disputing an incident timeline disputes it precisely by asking whether the entity could have known sooner, which is the question the antecedent fixation answers.

9 - WHAT SOURCE 0 DOES NOT CLAIM

SOURCE 0 does not replace any obligation DORA imposes. The ICT risk management framework, the testing regime, the third-party oversight, and the reporting timelines under Articles 17 to 23 remain fully in force and are not substituted by this architecture. SOURCE 0 CERTIFIED denotes an attestation, delivered by Jean-François ELSEN, that the SOURCE 0 procedure was followed in a given engagement; it is not an independent third-party certification, since Jean-François ELSEN provides the service being certified. All engagements are governed by an obligation de moyens. Recognition of the Historical Reality Dossier is direct before Belgian jurisdictions and assessed case by case elsewhere. Operational decisions remain the sole responsibility of the client organisation.

CLOSING AXIOM

A clock that only the accused can read does not prove the hour. SOURCE 0 seals the read before the question is asked.

REFERENCE NOTE

This article is part of the SOURCE 0 Doctrine Series and does not reproduce direct quotations from any court, regulator, or third party. SOURCE 0 is a registered trademark, BOIP/OBPI No. 1548293, Benelux.

REGULATORY NOTICE

This page is written for documentary purposes and does not constitute legal advice. SOURCE 0 is a proprietary pre-execution cryptographic attestation architecture, developed by Jean-François ELSEN. Jean-François ELSEN provides corporate directors, legal departments, supervisory authorities, CISOs, and compliance officers access to complete protocol specifications and evidentiary architecture reviews applicable to the AI Act, eIDAS, NIS 2, and DORA. For formal doctrinal consultations or evidentiary governance reviews, inquiries may be addressed to Jean-François ELSEN.