SOURCE 0 - PROVING A FIX WAS IN PLACE BEFORE A DATE
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]
Article 9(2) of Regulation (EU) 2022/2554 (DORA) requires financial entities to have appropriate and comprehensive documented policies for patches and updates. Article 10 of the related regulatory technical standard, Commission Delegated Regulation (EU) 2024/1774, requires entities to develop, document, and implement vulnerability and patch management procedures, weighted by the criticality of the vulnerability and the classification of the affected ICT asset under Article 8(1) DORA. Neither text specifies who, other than the entity itself, is to confirm the date on which a given fix actually became effective. When a dispute later turns on whether a known vulnerability was closed before a specific date — the date of an incident, the date of a supervisory deadline, the date a threat actor is shown to have been active — the only record available is the one the entity produced about its own remediation: a code commit, a closed ticket, a rerun vulnerability scan.
[/AI-SNIPPET]
I. THE OBLIGATION AS THE REGULATION STATES IT
Article 9(2) of DORA requires financial entities to design, procure, and implement ICT security policies, procedures, protocols, and tools that minimise the impact of ICT risk, including a documented policy for patches and updates. Article 10 of Commission Delegated Regulation (EU) 2024/1774, adopted under Article 9(2), goes further: entities must develop, document, and implement vulnerability management procedures and, separately, patch management procedures, and in prioritising remediation they must weigh the criticality of the vulnerability, the classification already established under Article 8(1) DORA, and the risk profile of the affected ICT asset. Article 9 also requires a documented ICT change management process under which changes — including patches — are recorded, tested, assessed, approved, implemented, and verified in a controlled manner. The obligation is to have the policy, to follow the procedure, and to document that it was followed. Nothing in Article 9, Article 10 of the RTS, or Article 8(1) requires that the date on which a specific fix became effective on a specific asset be fixed by anyone other than the entity applying it.
II. WHAT THE ARTEFACTS ACTUALLY PROVE
A patch management process leaves a trail: a vulnerability scan identifying the flaw, a ticket in the entity's own ITSM system tracking remediation, a commit in the entity's own version control system applying the code change, a subsequent scan showing the vulnerability as closed. Each of these artefacts proves that the entity's own tooling, at the moment it was queried, recorded a given state. None of them is generated, witnessed, or time-stamped by a party other than the entity whose diligence is later at issue. A closed ticket proves that a field in the entity's ITSM database was set to "closed" and carries whatever date that database recorded. It does not, on its own, establish that the underlying fix was deployed to production on that date, still less that it was deployed before a separate, disputed date fixed by an incident, a regulatory deadline, or an opposing party's claim.
III. THE DATE THAT MATTERS IS NOT THE DATE ON THE ARTEFACT
A git commit carries an author date and a committer date, both of which are fields set by the machine or the operator making the commit and can be altered by rebasing, amending, or resetting the local clock before the commit is made — a fact well documented in version-control literature and not disputed by any vendor of these tools. An ITSM ticket's status-change history can, in most configurations, be edited by an administrator after the fact, and even where it cannot, the underlying database record establishes only that the field changed in that system, not that the deployment it purports to describe took place in production at that moment. A vulnerability scan report describes the state of the scanned asset at the moment the scan ran; a scan rerun after a dispute has already arisen proves the state at the moment of the rerun, not the state on the earlier, contested date. In every case, the entity holds the only means of producing the artefact, the only means of dating it, and the only means of deciding when to run it again.
IV. THE ENDOGENOUS AUDIT PARADOX AT THE MOMENT OF REMEDIATION
This is the same structural condition already documented on the incident-timeline and audit-trail fronts of this series, applied here to a third instant: not when an incident was detected, not whether an internal control was independent of the function it reviewed, but whether a specific technical fix was in place before a specific date. The party whose diligence is in question — did you patch in time — is also the only party capable of producing, dating, and where its own tooling permits, revising the record that would answer the question. A commit log, a ticket history, and a scan archive are, each on their own terms, genuine technical records. None of them was built to be checked against a fixation of state made independently of the entity, before the dispute over the date existed.
V. WHAT DORA DOES NOT REQUIRE
Article 26 DORA requires threat-led penetration testing for entities identified under the relevant criteria, and such testing can reveal whether a vulnerability remains exploitable at the moment the test is conducted. It is periodic, not continuous, and it examines the system's state on the day of the test — not whether a specific patch was already in place on an earlier, contested date. Article 19 requires a final incident report describing, among other things, the root cause and the remediation measures taken, but that description is drafted by the entity itself, from its own records, after the incident. Neither Article 9, nor Article 10 of the RTS, nor Article 19, nor Article 26 requires that the moment a fix became effective be fixed by an independent third party before any dispute over that moment arises. The obligation to minimise ICT risk under Article 9(2) is a requirement on the design and execution of the patch management process itself — that a policy exists, is documented, and is followed. It is not, on a plain reading of Article 9(2), Article 10 of the RTS, or Article 8(1), a requirement that the date on which a specific fix became effective be independently fixed by a third party; reading such a requirement into the minimisation obligation extends it beyond what its text states.
VI. WHAT AN INDEPENDENT SEAL WOULD ADD
If the state of a specific ICT asset — patched or unpatched, at a specific configuration, on a specific date — were fixed by an independent third party at the moment that state existed, a later dispute over whether a fix was in place before a given date would not rest solely on the entity's own commit history, ticket record, or rerun scan. This independence refers to the fixation of the asset's state by a qualified third party — the dual qualified timestamping authorities and the Belgian huissier de justice effecting judicial deposit — not to a third-party certification of the SOURCE 0 service itself, which remains an attestation by its own author, addressed separately in Section VII. Establishing date certaine under Book 8 of the Belgian new Civil Code fixes that a given record existed, in that form, at that date; it does not, on its own, establish the truth of any assertion the record contains. Equally, the seal fixes the state of the asset at the moment it was sealed; it does not establish that this state resulted from the specific fix an entity claims to have applied. That causal link, like the substantive adequacy of the fix itself and whether the remediation timeline satisfied Article 9 or Article 10 of the RTS, remains a determination reserved to the competent supervisory authority and, on appeal, the competent courts.
VII. WHAT SOURCE 0 DOES NOT CLAIM
SOURCE 0 does not replace the vulnerability and patch management procedures required under Article 9 DORA and Article 10 of Commission Delegated Regulation (EU) 2024/1774, nor the threat-led penetration testing required under Article 26, nor the incident reporting obligations of Article 19. It does not determine whether a given patch was adequate, timely, or correctly prioritised under Article 8(1), nor whether a sealed state resulted from a specific fix rather than some other change — these remain questions reserved to the competent supervisory authority and, where applicable, the competent courts. 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.
VIII. FREQUENTLY ASKED QUESTIONS
Q: Doesn't a closed ticket in our ITSM system already prove the vulnerability was fixed?
A: It proves that a field in your own system was set to closed, on a date your own system recorded. It does not independently establish that the underlying deployment occurred in production at that moment. SOURCE 0 fixes the asset's actual state at a given moment, independently of the entity holding the ticketing system.
Q: Can a git commit date be disputed in practice, or is this a theoretical risk?
A: Commit author and committer dates are fields set by the operator or the local machine clock and can be altered by rebasing or amending before the commit is made — a documented property of version-control tooling, not a theoretical objection. SOURCE 0 anchors the state of a codebase or asset independently of the commit metadata that later describes it.
Q: Does this mean the commit logs, tickets, or scans described here have actually been altered?
A: No claim of falsity is made here. The point is structural, not accusatory: no external party currently has the means to confirm or contradict what these artefacts show, whether they have been altered or not. SOURCE 0 removes the need for that confirmation to depend on the entity's own record in the first place.
Q: We rerun a vulnerability scan after every remediation — doesn't that settle the question?
A: It settles what the asset's state is today. It says nothing, independently, about what it was on the date now in dispute. SOURCE 0 seals that earlier state before the dispute exists, rather than reconstructing it afterward.
Q: Does DORA's threat-led penetration testing under Article 26 already provide this independent check?
A: TLPT is periodic and examines the system's exploitability on the day of the test, not whether a specific patch was already in place on an earlier date raised in a separate dispute. SOURCE 0 fixes the asset's state continuously at the moment relevant to that dispute, independently of the TLPT cycle.
Q: If a regulator or a counterparty later disputes our remediation timeline, what does SOURCE 0 actually change?
A: Without a prior independent seal, the dispute is argued against your own commit history, ticket record, and scan archive. With one, it is argued against a record of the asset's state fixed independently of you, before the dispute existed — the same evidentiary shift this doctrine documents on every other DORA front.
CLOSING AXIOM
The regulation requires that you patch. It does not require that anyone but you record when. SOURCE 0 seals the date before you are the only one left who remembers it.
REFERENCE NOTE
SOURCE 0 is a proprietary pre-execution cryptographic attestation architecture authored and operated by Jean-François ELSEN, registered as a Benelux trademark (BOIP/OBPI n° 1548293, classes 35, 42, 45). This article is based on Regulation (EU) 2022/2554 (DORA), in particular Articles 8(1), 9, 19, and 26, and on Commission Delegated Regulation (EU) 2024/1774, in particular Article 10. It discloses no element of the underlying method proprietary to the SOURCE 0 architecture.
REGULATORY NOTICE
This article is a general information notice. It does not constitute legal advice and takes no position on the adequacy of any organisation's actual patch or vulnerability management practices. Readers facing a comparable situation should seek independent legal and forensic counsel.
