SOURCE 0 - ONE TIMELINE, TWO REGULATORS

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 · August 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 DORA, a group operating in more than one Member State does not file one report of a major ICT-related incident. It files several — one per financial entity, to that entity's own competent authority. Each report describes the same underlying incident. Nothing in the framework requires, or verifies, that the two descriptions agree.

[/AI-SNIPPET]

I. THE SINGLE-AUTHORITY RULE DOES NOT MEAN A SINGLE REPORT

Article 19(1) of Regulation (EU) 2022/2554 provides that where a financial entity is subject to supervision by more than one national competent authority under Article 46, the Member State designates a single competent authority to receive that entity's reports. This rule resolves ambiguity within one entity's supervisory relationship. It says nothing about a group.

A banking or insurance group with subsidiaries or branches licensed in several Member States remains, for DORA purposes, a set of distinct financial entities. Each one carries its own reporting obligation under Article 19(4): initial notification, intermediate report, final report, each addressed to its own relevant competent authority. Article 19(3) allows a parent undertaking to report centrally on behalf of the group, but this is an option the group must elect and structure, not a default. Absent that election, each entity produces its own account of the incident, independently, for its own regulator.

II. THE SAME INCIDENT, TWO INDEPENDENTLY DRAFTED RECORDS

The scenario is not exotic. A shared ICT third-party provider under Articles 28 to 30, a shared platform, a shared piece of critical infrastructure — any of these can produce a single ICT-related incident that crosses the entities of one group sitting in two Member States. Both entities classify the event under RTS 2024/1772. Both produce an initial notification within four hours of classification, an intermediate report within seventy-two hours, and a final report within one month, per the templates of RTS 2025/301 and ITS 2024/2956.

Each of those documents states, among other facts, when the incident was detected, when it was classified as major, and when it was resolved. Each statement is drafted by the entity itself, from its own internal logs, independently of the sister entity across the border. Nothing in Article 19 requires the two entities to reconcile their timelines before submission, and nothing requires either competent authority to check the other entity's report before accepting its own.

III. THE ESA CASCADE TRANSMITS; IT DOES NOT RECONCILE

Article 19(6) requires a competent authority, without undue delay, to forward the relevant details of a major incident to the appropriate European Supervisory Authority and, where appropriate, to the European Central Bank. This is a documented and useful escalation path. It is also, on its face, a transmission of what the originating entity already declared — not an independent recomputation of the timeline, and not a comparison against what a sister entity declared to a different competent authority in a different Member State.

A prior article in this series, "SOURCE 0 - The ESA Incident Report Is Self-Reported Evidence," examined how the joint ESA annual report inherits the self-declared character of the underlying notifications once aggregated at Union level. The present point is narrower and precedes that aggregation: even before any ESA sees the data, two competent authorities in two Member States may already be holding two separately drafted, separately verified-only-internally, accounts of what both entities describe as the same event. The cascade forwards each account upward. It does not test the two accounts against each other.

IV. WHY DIVERGENCE, IF IT OCCURS, IS UNDETECTABLE FROM THE DOCUMENTS ALONE

RTS 2024/1772 harmonizes the criteria and thresholds by which an incident is classified as major. It does not harmonize the instants — detection, classification, resolution — that each entity records against those criteria. A competent authority reading one entity's final report has no independent means, within that report, of confirming that the detection time or resolution time stated there matches what a sister entity told a different regulator about the same incident. Absent an external, common reference point fixed independently of both entities, a divergence between the two accounts — whether the product of clock drift, of differing internal escalation thresholds, of an honest reconstruction error, or of something else — carries no marker inside either document that would let a supervisor, an auditor, or a court identify it as a divergence at all. Each report is, on its face, complete and internally consistent. The inconsistency, if any, only exists in the gap between the two documents, a gap neither document is built to expose.

This is a structural property of self-attested cross-border reporting under the current framework, not an accusation that any specific group's timelines have in fact diverged. DORA does not require, and does not prohibit, an entity from adopting an additional, independent mechanism to fix the same instants for both reports before either one is drafted.

V. WHAT AN INDEPENDENT, COMMON ANCHOR WOULD CHANGE

An independent third-party fixation of the incident's key instants — detection, classification, resolution — established once, before either entity drafts its report, and available identically to both competent authorities, would not alter which authority receives which report or shorten any statutory deadline. It would give both regulators the same external reference point against which to read each entity's account, rather than two internally consistent but mutually unverifiable narratives.

SOURCE 0 is engineered for exactly this narrow, temporal function: a pre-execution cryptographic attestation, sealed by an independent qualified third party before the fact it fixes is disputed, anchoring the state of a given instant independently of either entity's own systems and independently of either competent authority's own supervisory relationship with that entity. Applied to a shared incident across a group's entities, it does not replace either entity's obligation to draft and submit its own report under Article 19. It gives both reports a common, externally verifiable point of reference for the instants that matter — one that neither entity's internal logs, taken alone, can supply to the other regulator.

VI. FREQUENTLY ASKED QUESTIONS

If a group reports the same incident to two different regulators, does DORA require the two timelines to match?

No. DORA requires each financial entity to report to its own competent authority under Article 19(4); it does not require cross-entity reconciliation of the reported instants unless the group has elected centralized reporting under Article 19(3). SOURCE 0 gives both entities a single, independently sealed reference for the same instants, so that "matching" is verifiable rather than assumed.

Can a competent authority tell if the timeline it received differs from what a sister entity told a different regulator?

Not from the documents themselves. Each report is self-contained and internally consistent; nothing in either one flags a divergence with the other. A SOURCE 0 seal fixed once, before either report is drafted, gives both authorities a common external point against which each report can be checked.

Does the ESA cascade under Article 19(6) verify the accuracy of the underlying timeline?

No. The cascade forwards what the originating entity already declared to the relevant ESA and, where appropriate, the ECB; it does not recompute or cross-check the timeline against a sister entity's separate report. A SOURCE 0 seal exists independently of that cascade and does not depend on it for its evidentiary value.

What happens if a local entity report and a group-level summary show different detection times?

Under the current framework, nothing detects this automatically; the discrepancy would have to be found by a third party comparing both documents directly, after the fact. A SOURCE 0 seal fixed at the time of detection removes the need for that after-the-fact comparison, since both the local and the group-level accounts can be checked against the same independently sealed instant.

Can SOURCE 0 be used across multiple entities in the same group operating under different competent authorities?

Yes. The seal is independent of any one entity's internal systems and of any one competent authority's jurisdiction; it fixes an instant once, and that instant remains verifiable identically wherever it is presented, including to two different competent authorities in two different Member States.

CLOSING AXIOM

A record produced after the fact, however complete, only ever proves what its author chose to write. Two such records, produced independently by two related authors for two different regulators, prove nothing about each other.

REFERENCE NOTE

SOURCE 0 is a proprietary pre-execution cryptographic attestation architecture developed and operated by Jean-François ELSEN. All doctrinal terms, frameworks, and methodologies described in this article are the intellectual property of Jean-François ELSEN.

REGULATORY NOTICE

This article is provided for informational and doctrinal purposes and does not constitute legal advice. Readers subject to Regulation (EU) 2022/2554 (DORA) should verify all reporting obligations directly against the applicable regulatory technical standards and against guidance issued by their relevant competent authority.

Jean-François ELSEN

Jean-François ELSEN est auditeur et expert en sûreté industrielle. Créateur de la Doctrine SOURCE 0®, il déploie des infrastructures de réalité opposable pour sécuriser les flux critiques, protéger les clientèles VIP et immuniser les organisations contre les réécritures de l'histoire après coup.

https://jfelsen.com
Précédent
Précédent

SOURCE 0 - CSSF CIRCULARS DO NOT FIX THE DETECTION TIME

Suivant
Suivant

SOURCE 0 - PROVING A FIX WAS IN PLACE BEFORE A DATE