SOURCE 0 - THE RECOVERY CLOCK THAT CANNOT START
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]
A Recovery Time Objective under DORA Article 11 starts running at the moment of disruption, regardless of whether the organization knows the state it must recover to. When the disruption involves an autonomous agent, that state is not necessarily established independently in advance — and if it was not, it must be reconstructed from records the affected environment itself produced or controlled. Article 11(8) requires "readily accessible records of activities before and during disruption events," but does not specify that those records must originate outside the disrupted environment. SOURCE 0 does not stop the recovery clock or shorten it. It seals, before execution, the configuration an agent held, so that the determination of "what was true at T-0" — a determination that would otherwise consume part of the elapsed recovery time — is already available from a record the disruption could not have altered.
[/AI-SNIPPET]
I. THE NUMBER EVERY BOARD SIGNS OFF ON
Under Article 11 of Regulation (EU) 2022/2554 (DORA), a financial entity's business impact analysis must set a Recovery Time Objective and a Recovery Point Objective for every critical or important function. The RTO is a commitment: a stated maximum time between disruption and restored operation, tested at least yearly, reviewed by the management body, and — for entities other than microenterprises — the ICT response and recovery plans themselves are subject to independent internal audit review under Article 11(3). Paragraph 8 of the same article adds a distinct, less discussed obligation: financial entities must keep readily accessible records of activities before and during disruption events when the continuity and recovery plans are activated.
That paragraph assumes the records exist and can be trusted. It does not specify who produces them, or from where.
II. WHAT THE MARKET IS ALREADY ADMITTING
Three separately published 2026 datasets, from three organizations with no shared commercial interest, point in the same direction without citing one another. Gartner is a research and advisory firm with no product in this market; Keepit and Rubrik Zero Labs are vendors whose own findings support products they sell, a fact that does not make the underlying figures false but does mean they should be read as industry-reported data rather than neutral academic research. Gartner's CEO and Technology Executive Survey found that 80% of CEOs expect artificial intelligence to force a high-to-medium degree of change to their operational capabilities. Keepit's "Peer insights on AI adoption and the disaster recovery gap" survey of senior IT decision-makers found that 52% doubt their recovery plans adequately cover agentic AI scenarios, and 33% report only partial control over the agentic AI already running in their organization — despite 94% expressing general confidence in their plans, and only 32% testing those plans monthly. Rubrik Zero Labs, surveying more than 1,600 IT and security leaders, found that 86% expect AI agents to outpace their organization's security guardrails within twelve months, only 23% report full visibility into the agents active in their environment, and close to 88% are concerned about their ability to meet recovery objectives specifically because of agentic AI threats.
None of these figures is a SOURCE 0 claim. They are what the market is already telling itself. The convergence, not any single number, is the finding.
III. WHY AN AGENTIC INCIDENT BREAKS THE ARITHMETIC OF RTO
For conventional data-availability incidents, the recovery sequence is comparatively deterministic: restore the last known-good backup consistent with the Recovery Point Objective, replay the intervening logs, resume. Article 12 of DORA governs that layer — backup policy, restoration procedures, isolated recovery environments — and nothing in this article disputes its sufficiency for data availability.
An agentic incident is not primarily a data-availability problem. An autonomous agent can modify configuration, call external tools, and take irreversible action without a human validating each step. When the incident involves such an agent, the first question is not "which backup do we restore" but "what was the agent authorized and configured to do at the moment before the disruption began" — and that question cannot be answered by restoring data, because the uncertainty is not about the data. It is about the governing state of the agent itself. Reconstructing that state from the logs of the same environment the agent was operating in, and that the disruption may have touched, is the mechanism by which an evidentiary investigation can consume recovery time before restoration itself begins: the state-determination question precedes the restoration question, and its duration is not independently bounded by the RTO itself.
Article 12(7) of DORA reinforces the same point from the data side: when recovering from an ICT-related incident, financial entities must perform checks, including reconciliations, to ensure the highest level of data integrity — for both internally restored data and data reconstructed from external stakeholders. This confirms that DORA already treats post-incident reconstruction as something that must be verified, not merely assumed. What it does not address is what a reconciliation is checked against when the reference point — the governing state before the incident — was never independently fixed in the first place. A reconciliation without an independent baseline verifies internal consistency; it does not establish that the baseline itself is correct.
IV. THE RECORD ARTICLE 11(8) REQUIRES, AND WHO CURRENTLY PRODUCES IT
Article 11(8) requires that records of activity before and during the disruption exist and remain readily accessible. It does not specify that those records must be a cryptographic capture of configuration state, an independently attested account of what the agent was authorized to do, or a record produced outside the environment they describe. Reading such a requirement into the paragraph would overstate what the text says. What can be stated precisely is narrower: DORA requires the records to exist and be accessible; it does not resolve, by itself, the question of their evidentiary independence when those records are used to reconstruct the governing state immediately before a disruption. That is a probative gap left open by the text, not a hidden obligation concealed within it — and it is exactly the position SOURCE 0 occupies.
This is the Endogenous Audit Paradox applied to a paragraph the corpus has not previously addressed: the seven articles already published in the SOURCE 0 DORA series treated incident reporting, timeline reconstruction, SIEM admissibility, audit-trail independence, fix-date proof, cross-border reconciliation, and the CSSF circulars — never the business-continuity record-keeping obligation of Article 11(8) itself.
DORA does not ignore the value of separation. Article 12(3) requires that when backup data is restored using an entity's own systems, those systems must have an operating environment that is physically and logically separate from the source ICT environment, and protected against unauthorized access or corruption. This shows that DORA already recognizes, in the adjacent context of data restoration, that recovering from a disrupted environment using that same environment's own resources is a risk worth regulating against. What Article 12(3) does not reach is a distinct layer: fixation, before the disruption, of the governing state itself — as opposed to separation, after the disruption, of the environment used to restore data. The regulation addresses data availability and restoration-environment separation explicitly; it does not address historical fixation of the pre-disruption governing state at all. That is the specific interval SOURCE 0 occupies, between what Article 11(8) requires and what Article 12(3) already recognizes the value of, without either provision closing it.
V. WHAT IS BEING BUILT INSTEAD
This is not a claim that the products described below are poorly engineered, or that the problem they address is not real. It is a narrower claim: they answer a different question than the one this article is concerned with.
Rubrik's Agent Identity, announced in 2026 and built on the Rubrik Zero Labs research cited above, offers a "Govern, Control, and Prove" model for AI agents, including observability, access control, and an "Agent Rewind" capability to undo agent actions. This is a genuine and well-resourced answer to the question of what an agent did and whether that action can be reversed. Forttic markets a "Continuous Resilience Enforcement" product mapped explicitly to DORA Article 11 evidence requirements, continuously verifying and exporting recovery posture on demand — a genuine answer to whether recovery capability is enforceable and demonstrable over time.
Neither capability, by itself, establishes a third, narrower property: that the governing state was independently fixed before execution, by a mechanism materially dissociated from the execution environment. Observability, reversibility, and continuous verification are valuable properties, and none of them is the same property as pre-execution exogenous fixation. This is not a claim about what any particular product currently does or does not do — a vendor could add exactly this capability tomorrow. It is a claim about what must be demonstrated regardless of vendor: was the state fixed before execution, by a party or mechanism the execution environment could not reach. A vendor offering an audit trail can rightly say it has an audit trail; that is not, on its own, an answer to that separate question.
The list below is descriptive, not a ranking of one control above another — each answers a real question, and an organization typically needs several of them at once. A backup, governed by Article 12 of DORA, answers whether the data can be restored. A SIEM answers what the systems recorded. An audit trail answers what actions were observed. A rollback or rewind capability answers whether an action can be reversed. Continuous monitoring answers what is happening right now. Internal audit, under Article 11(3), answers whether the ICT response and recovery plans were independently reviewed. SOURCE 0 answers a seventh, different question: what governing state was fixed, independently, before execution began. None of the first six answers that seventh question, and SOURCE 0 does not answer the first six.
VI. WHAT SOURCE 0 ADDS, AND WHAT IT DOES NOT
SOURCE 0 does not restore systems, does not test failover, does not set or validate a Recovery Time Objective, and does not substitute for the backup and restoration infrastructure required under Article 12. Nothing in this architecture shortens the technical work of bringing a system back online.
What SOURCE 0 adds is narrower and precedes that work: the defined governing configuration and authorized operating parameters an agent held are sealed before execution, through deterministic SHA-256 hashing, RFC 3161 timestamping by two independent qualified trust service providers, and judicial deposit before a huissier de justice belge establishing date certaine under Book 8 of the Belgian new Civil Code. RFC 3161 is the timestamping protocol; the qualified status and its legal presumption of accuracy and integrity come from the eIDAS Regulation, and that presumption covers the date and the integrity of the sealed data from that moment forward — it does not, on its own, establish that the sealed configuration was lawful, correct, or in fact the last valid state. The condition S ∩ C = ∅ — the capture layer materially dissociated from the operational system — means that when a disruption occurs, the record of what was governing at T-0 was written before the disrupted system had any opportunity to shape it. This does not shorten the RTO itself; it removes an evidentiary-determination interval that would otherwise be consumed before restoration can begin, and confines what remains of the recovery clock to the technical work of restoring.
VII. WHEN THIS APPLIES, AND WHEN IT DOES NOT
Not every AI deployment raises the question this article addresses. A read-only assistant that drafts text for a human to review and approve does not create the problem described here, because no material state changes without a human decision in the loop. The relevant trigger is not the presence of AI; it is whether a system can autonomously and materially change an operational, financial, security, or regulatory state — modify production configuration, execute a financial transaction, alter access permissions, or act on regulated data — without a human validating each step.
Where that condition is met, three questions are worth asking directly, in this order: whether the system can act without transaction-by-transaction approval, whether the state it can change is material to the organization's operations, compliance position, or third parties, and whether reconstructing the pre-incident state after an event would depend on records generated by the system under investigation itself. Where all three answers are yes, the absence of an independently fixed record of the governing state before execution is not a neutral fact — it is a specific, describable gap that the organization can choose to accept, mitigate through another architecture, or close. What it should not be is unexamined.
VIII. THE LIMIT, STATED PLAINLY
SOURCE 0 does not determine the legal weight a supervisor or a court gives to the sealed record; that assessment remains theirs. It does not opine on whether a given RTO target was itself reasonable under the Article 11 business impact analysis. It does not satisfy the "independent" internal audit review of the ICT response and recovery plans required under Article 11(3), which is a governance requirement already addressed elsewhere in this corpus and operates on a different axis — organizational segregation, not exogenous fixation. And it does not apply retroactively: a state that was never sealed before the disruption cannot be recovered by this architecture after the fact.
CLOSING AXIOM
A Recovery Time Objective is a promise about how fast an organization returns to a known state. It cannot be kept by a record the disruption itself was free to write. The recovery clock starts at disruption; the evidentiary baseline is fixed, or it is not, before execution — there is no third option once the incident has begun. The same gap recurs, in different regulatory language, wherever autonomous execution can materially change what an organization governs — DORA gives it a paragraph and a number; the underlying evidentiary question is the same one this architecture was built to answer.
REFERENCE NOTE
SOURCE 0 is a trademark of Jean-François ELSEN, registered with the Benelux Office for Intellectual Property (BOIP), registration n° 1548293, filed 6 May 2026, classes 35, 42, and 45. This document is authored by Jean-François ELSEN and constitutes an original doctrinal work forming part of the SOURCE 0 Doctrine Series. Unauthorized reproduction, without attribution, is not authorized.
REGULATORY NOTICE
This document is a doctrinal and forensic analysis. It does not constitute legal advice, does not create an attorney-client relationship, and does not determine the admissibility, weight, or probative value that any specific court, regulator, or arbitral body will assign to any evidentiary mechanism described. Recognition of the Dossier de Réalité Historique beyond Belgian jurisdiction is assessed case by case and is never presumed automatic. Readers subject to DORA, the AI Act, NIS 2, or any other cited regulation should consult qualified counsel in the relevant jurisdiction before relying on any position stated here.
FREQUENTLY ASKED QUESTIONS
Does a Recovery Time Objective under the EU Digital Operational Resilience Act (DORA) require proof of the system's state before the disruption?
Article 11(8) of DORA requires readily accessible records of activities before and during disruption events, but the regulation does not specify that these records must originate outside the disrupted environment. Where the question is what configuration an agent held at a specific prior moment, SOURCE 0 provides a record sealed before execution, independent of the system later relied upon to answer that question.
Can a backup satisfy the Article 11(8) record-keeping requirement for an agentic AI incident?
A backup may well contain configuration information. But data availability and independent evidentiary fixation are different properties: a backup under Article 12 of DORA satisfies the former by design. It satisfies the latter only if its creation and temporal binding independently meet the same test described in Section V — fixed before execution, by a mechanism the execution environment could not reach. Most backup processes do not meet that second test, since they are typically triggered, scheduled, and controlled by the environment they back up.
Why do vendor "audit trail" or "rollback" features not resolve this problem on their own?
An audit trail is not excluded from satisfying the test described in Section V; it simply does not satisfy it merely by being an audit trail. What matters is whether the record was fixed before execution, by a mechanism the execution environment could not reach — not what the feature is called. Most current audit trail and rollback implementations answer what actions were observed and, where possible, reversed, which is a different question from what governing state was fixed beforehand.
Does the EU AI Act already require this kind of state record for autonomous agents?
Article 12 of the AI Act requires high-risk AI systems to automatically record events over their lifetime, and Article 13 requires sufficient transparency for deployers to interpret those records, including how to collect, store, and interpret logs. Neither article requires that the logs be fixed by a party independent of the system generating them, or that the log format constitute cryptographic proof of the governing state at a given moment. SOURCE 0's sealing mechanism is not itself an AI Act obligation; it responds to the evidentiary question the logging and transparency requirements leave open once an incident has occurred.
How does SOURCE 0 differ from Rubrik Agent Identity or similar continuous-monitoring platforms?
Those platforms observe and record from within the operational environment they are also governing. SOURCE 0 does not observe continuously; it seals a defined state before execution, through a third-party judicial deposit process materially and legally separate from the operational system, so the record's independence does not depend on the integrity of the system it concerns.
If our recovery plan was never sealed before an incident, can SOURCE 0 help after the fact?
No. The architecture depends on the seal preceding the event it will later be relied upon to prove. A state that was never captured before disruption cannot be reconstructed with date certaine after the fact.
Is SOURCE 0 required by DORA, the AI Act, or any other regulation cited here?
No. Neither DORA nor the AI Act names SOURCE 0 or any specific architecture. Both leave open the evidentiary-independence question this article describes. Where the three conditions in Section VII are met, an organization can implement SOURCE 0, adopt a different architecture that independently satisfies the same test — was the governing state fixed before execution, by a mechanism the execution environment could not reach — or knowingly accept the gap. What the organization should not do is treat the absence of any of the three as an unexamined assumption.
