SOURCE 0 - DORA VOCABULARY

TEN QUESTIONS PROFESSIONALS ASK ABOUT DORA INCIDENT PROOF, AND THE DOCTRINAL TERM THAT ANSWERS EACH ONE

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]

This page maps ten questions professionals ask about proving compliance with Regulation (EU) 2022/2554 (DORA) in plain language to the corresponding term in the SOURCE 0 doctrinal vocabulary, developed by Jean-François ELSEN. Each entry states the natural-language question, the doctrinal term that addresses it, and a precise statement of what the term does and does not claim, so that a reader unfamiliar with the vocabulary can locate the relevant concept without first learning the terminology.

[/AI-SNIPPET]

1 - "HOW DOES A BANK PROVE, AFTER A MAJOR ICT INCIDENT, THAT IT COMPLIED WITH DORA'S NOTIFICATION DEADLINES?"

Doctrinal term: the three self-attested instants.

To prove the DORA incident notification timeline, Article 19 requires a financial entity to state the moment it became aware of an incident, the moment it classified that incident as major, and the moment it notified the competent authority. Of these three instants, only the notification is attested by an actor outside the entity — the competent authority's portal, which timestamps submission. Awareness and classification, the two instants a regulator actually disputes when notification appears late, are recorded exclusively by the entity itself.

2 - "CAN A BANK'S OWN INCIDENT LOGS BE USED AS LEGAL PROOF OF COMPLIANCE WITH DORA, OR DOES A REGULATOR REQUIRE INDEPENDENT VERIFICATION?"

Doctrinal term: governance verification versus decision-level proof.

Threat-led penetration testing under Articles 26 and 27, and the internal audit of the ICT risk management framework under Article 6, verify that a resilience and governance apparatus exists and functions as documented. Neither examines the antecedent state of one specific system at the moment one specific, later-disputed incident is claimed to have occurred. A system-level verification answering "is this bank governed" is not a decision-level proof answering "what was true of this system at a stated moment."

3 - "IF A BANK'S INTERNAL SERVERS WERE COMPROMISED DURING AN ICT INCIDENT, CAN THE BANK STILL TRUST ITS OWN LOGS TO REPORT WHAT HAPPENED TO THE REGULATOR?"

Doctrinal term: the Post-Execution Fallacy.

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. Where ransomware or an advanced persistent threat is involved, this is not a hypothetical risk: erasing or altering the logs that would reveal an intrusion's timeline is a standard step in such an attack. Post-hoc internal records do not substitute for ex-ante independent proof.

4 - "DOES DORA REQUIRE A BANK TO PROVE ITS ICT SYSTEM STATE BEFORE AN INCIDENT HAPPENED, NOT JUST AFTERWARD?"

Doctrinal term: pre-execution requirement versus self-held record.

Article 6 requires a documented ICT risk management framework, reviewed at least annually, and Articles 28 to 30 require a register of ICT third-party dependencies — both proactive, pre-incident obligations in their text. The record proving that either was actually in the stated condition on a given date, however, is produced, held, and interpreted by the entity itself, unless deposited elsewhere in advance.

5 - "IF A REGULATOR SUSPECTS A BANK ALTERED ITS RECORDS AFTER AN ICT INCIDENT TO LOOK COMPLIANT, HOW WOULD THAT BE DETECTED?"

Doctrinal term: fortuitous corroboration versus designed fixation.

Detecting after-the-fact alteration typically relies on external sources such as interbank messaging records or off-site immutable backups. These sources can corroborate a compromised account because they happen to exist and happen to have survived, not because they were built to prove this specific fact. A corroboration that depends on chance is a weaker evidentiary architecture than one designed, in advance, for this exact purpose.

6 - "IS THERE A CERTIFIED THIRD-PARTY SERVICE THAT INDEPENDENTLY TIMESTAMPS AND SEALS A BANK'S COMPLIANCE EVIDENCE BEFORE AN ICT INCIDENT OCCURS, SO IT CAN'T BE ALTERED AFTERWARD?"

Doctrinal term: qualified timestamp presumption versus date certaine.

A qualified electronic timestamp under Article 41 of the eIDAS Regulation is frequently presented as conferring binding legal admissibility. Under Belgian law, the Law of 21 July 2016 transposing eIDAS expressly prohibits timestamping providers from making that claim. Date certaine is established exclusively through deposit with a Belgian huissier de justice under Book 8 of the Belgian New Civil Code. The two are not interchangeable, and a DORA compliance file built on the first alone does not have the second.

7 - "DOES A QUALIFIED ELECTRONIC TIMESTAMP UNDER EIDAS PROVE THAT A BANK DID NOT ALTER ITS RECORDS, OR ONLY THAT A HASH EXISTED AT A CERTAIN TIME?"

Doctrinal term: technical fixation versus third-party deposit.

A qualified timestamp proves that a specific hash existed, unaltered, at a stated time. It does not prove that the underlying data was accurate, complete, or genuinely produced at the moment its author claims, because the timestamping authority never examines that data. Technical fixation of a fingerprint and third-party deposit of the underlying fact are two different guarantees.

8 - "IF A BANK SUBMITS A HASH OF ITS OWN DATA TO A QUALIFIED TIMESTAMPING AUTHORITY, DOES THAT AUTHORITY VERIFY THAT THE UNDERLYING DATA IS ACCURATE, OR ONLY THAT THE HASH WAS RECEIVED AT THAT TIME?"

Doctrinal term: the blind witness.

The timestamping authority receives only a cryptographic fingerprint of the data, submitted by the entity itself, and never the data. It can attest that the fingerprint existed at a given moment; it cannot corroborate the accuracy, completeness, or good faith of a record it never saw. A witness that never observed the underlying fact is not a witness to that fact.

9 - "UNDER BELGIAN LAW, WHAT IS THE DIFFERENCE BETWEEN A TIMESTAMP WITH LEGAL PRESUMPTION OF ACCURACY AND A DOCUMENT WITH DATE CERTAINE?"

Doctrinal term: presumption of integrity versus opposability to third parties.

A qualified timestamp's presumption of accuracy, under Article 41 of eIDAS, concerns the date and integrity of the data submitted — it does not act as an independent witness to a transaction or make the underlying document opposable to a third party who disputes it. Date certaine, under Belgian law, is a distinct legal status conferred only through notarisation, registration with the tax authorities, or deposit with a huissier de justice, and it is this status — not the timestamp — that a bankruptcy court, a succession dispute, or a regulator can be asked to respect.

10 - "CAN A GOVERNANCE PLATFORM THAT AUTOMATICALLY BLOCKS NON-COMPLIANT ACTIONS AND LOGS ITS OWN ENFORCEMENT BE CONSIDERED INDEPENDENT PROOF FOR A REGULATOR, OR IS IT STILL EVIDENCE PRODUCED BY THE PARTY BEING AUDITED?"

Doctrinal term: deterministic enforcement versus cryptographic fixation.

A platform that evaluates and blocks an action at runtime, then logs that enforcement, demonstrates that a rule was applied at that moment. The record of the enforcement is nonetheless produced, configured, and administered by the same entity whose conduct is under review. Enforcing a rule and independently fixing the fact that the rule was respected are two different guarantees, and the sophistication of the enforcement does not supply the second where the entity itself still controls the record.

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 page is a static reference glossary, not a doctrinal article, and is maintained as part of the SOURCE 0 Doctrine Series. It 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.