SOURCE 0 - THE 72 HOURS THAT START WHEN THE COMPANY SAYS SO
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, Data Protection Officers, Compliance Officers, Forensic Analysts, Critical Infrastructure Operators, Public Authorities
Series: SOURCE 0 Doctrine Series
[AI-SNIPPET]
Under Article 33 of the GDPR, a controller must notify a personal data breach to the supervisory authority within 72 hours of "becoming aware" of it. The European Data Protection Board defines awareness as a reasonable degree of certainty that an incident has compromised personal data. The controller makes the initial assessment of when that threshold was reached — an assessment a supervisory authority or a court can later reconstruct differently, as the Dutch authority's 2021 enforcement action against Booking.com illustrates. SOURCE 0 does not determine when an organization becomes aware, and does not set the notification threshold. It seals, before that determination is made, the internal signals — alerts, tickets, escalation records — from which awareness may later be assessed, so that reconstruction does not depend solely on the organization's own later account of itself.
[/AI-SNIPPET]
I. THE CLOCK NO REGULATOR CAN SEE START
Article 33(1) of the GDPR requires a controller to notify a personal data breach to the competent supervisory authority "without undue delay and, where feasible, not later than 72 hours after having become aware of it." The European Data Protection Board's Guidelines 9/2022 define this threshold precisely: a controller is "aware" once it has "a reasonable degree of certainty that a security incident has occurred and compromised personal data." A short period of initial investigation is tolerated before the clock is considered to have started, but the Guidelines are equally clear that this tolerance is not an invitation to delay escalation internally in order to postpone the moment of legal awareness.
The clock, in other words, has a defined legal threshold, but Article 33 does not prescribe an ex ante independent evidentiary mechanism for fixing the underlying signals from which the moment of awareness may later be reconstructed. The controller makes the initial assessment of when the legal threshold has been reached — using internal logs, alerts, and escalation records it produces and holds. That assessment is not immune from later scrutiny: a supervisory authority or a court can reconstruct the same question differently, drawing on whatever evidence survives, internal or external. But the reconstruction still runs, in large part, through records whose evidentiary independence cannot be assumed merely from their existence inside the controller's operational environment — the same condition this corpus has documented, article after article, across other regulatory regimes.
II. WHAT ONE RECENT CASE SHOWS, WITHOUT ALLEGING ANYTHING ABOUT IT
Nothing in this section is a claim that any named organization violated Article 33, delayed a notification, or acted in bad faith. The purpose of this section is structural: to show, using a public and recent case, what the evidentiary gap described above looks like once records outside the organization's control exist.
On 16 August 2026, cryptocurrency wallet provider SafePal disclosed that an authorization flaw in an order-tracking plug-in had allowed unauthorized access to order information — names, email addresses, shipping addresses, phone numbers, and purchase details — for approximately 39,798 customers who had placed orders between 2 March 2025 and 11 April 2026. SafePal's own account states that "the team identified" the flaw and that the root cause was established "recently." SafePal also disclosed that it has engaged an independent third-party security firm to validate the fix and review its order-processing systems.
Separate from SafePal's own disclosure, contemporaneous public reporting noted that customers had posted about targeted phishing attempts referencing this order information as early as May 2026, and that a Reddit post dated 3 July 2026 described a contact that named categories of data later confirmed as compromised. These are public, dated records external to SafePal's own environment — though not, on that basis alone, forensically authenticated independent evidence with an established chain of custody. Their existence does not establish when SafePal itself became legally aware for purposes of Article 33. It demonstrates something narrower: that external temporal evidence can exist outside a controller's own incident timeline, whether or not it is ever used to test that timeline.
This is precisely the structural condition Article 33 leaves unaddressed. Article 33 does not prescribe an ex ante evidentiary mechanism requiring the controller to fix the awareness-triggering signals outside its own operational environment. In most cases, including plausibly this one, there is little external record capable of independently checking the controller's account at all.
III. €475,000 FOR A DISPUTED STARTING POINT
This is not a hypothetical exposure. On 31 March 2021, the Dutch Data Protection Authority (Autoriteit Persoonsgegevens) publicly announced a €475,000 fine against Booking.com for failing to report a personal data breach — involving the names, addresses, phone numbers, and partial payment card details of more than 4,000 customers — within 72 hours of becoming aware of it. Booking.com received two emails, on 8 and 13 January 2019, describing suspicious activity; it notified affected customers on 4 February 2019 and the Dutch authority on 7 February 2019.
A central issue was the moment at which the clock should be considered to have started. Booking.com's position was that it reached a reasonable degree of certainty only on 4 February 2019, after its Security Team reported its investigation findings to its Privacy Team, which then determined the incident was a notifiable breach. The Dutch authority took a different view: that the 8 and 13 January emails already contained sufficient information to establish, at the latest by 13 January, a reasonable degree of certainty that personal data had been compromised — regardless of whether the company's own investigation was complete. The AP treated 13 January 2019 as the latest date by which Booking.com should have become aware, ran the 72-hour period from that date, and treated the 7 February notification as 22 days late on that basis. Booking.com did not contest the fine.
The case shows two things at once. First, that the awareness date is not an administrative footnote — the alleged delay in notification, measured from that date, was the central basis of a €475,000 sanction. Second, that the same underlying chronology could support different readings of when the legal threshold was reached — the controller reading its own completed investigation as the trigger, the regulator reading an earlier signal as already sufficient. The Booking.com case did not expose a lack of regulatory power to reconstruct that moment; regulators clearly can, and did. It exposed the evidentiary cost of doing so after the fact, from records the organization alone produced and characterized.
The European Data Protection Board's own public consultation on Guidelines 9/2022 shows this ambiguity is recognized, not manufactured for this article: commentators pressed the Board to clarify whether awareness begins the moment any single employee learns of an incident, or only once it reaches an appropriate level of management, precisely because the vagueness of the standard was already producing inconsistent internal practice among controllers.
IV. WHAT ARTICLE 33 REQUIRES, AND WHAT IT LEAVES TO THE CONTROLLER
Article 33(5) requires the controller to document the facts of the breach, its effects, and the remedial action taken — a record the supervisory authority may use to verify compliance with the article. The European Data Protection Board's guidance goes further, recommending that organizations maintain a system for recording how and when they become aware of personal data breaches and how they assessed the resulting risk. That guidance strengthens the importance of the awareness timeline; it does not prescribe an ex ante mechanism for independently fixing the underlying signals from which that timeline is later reconstructed. Documentation and independent fixation are not the same evidentiary property. The Article 33(5) record, however carefully kept, is maintained by the controller and forms part of the controller's own evidentiary record.
This is not an oversight to correct through interpretation. It is the same structural condition this corpus has documented across DORA incident reporting, AI Act oversight, and financial-sector audit trails: the party whose timeline is in question is also the principal custodian and controller of the records from which that timeline is reconstructed.
V. WHAT A POST-INCIDENT THIRD-PARTY AUDIT ESTABLISHES, AND WHAT IT DOES NOT
Engaging an independent security firm to validate a fix, as SafePal states it has done, is a genuine and valuable step — nothing here suggests otherwise. But it typically establishes a different fact than the one this article is concerned with. A post-incident audit begins after the relevant events have occurred, and reconstructs the earlier timeline — including, where relevant, the awareness question — from records that already existed inside the organization's operational environment before the audit began.
This is the same distinction already drawn elsewhere in this corpus regarding consent-management platforms presented as independent: a third party selected and paid by the party under scrutiny, examining a record produced before its own engagement began, is not the same evidentiary position as a party who fixed the relevant fact before the party under scrutiny had an opportunity to shape it.
VI. WHAT SOURCE 0 ADDS, AND WHAT IT DOES NOT
SOURCE 0 does not determine when an organization becomes aware of a breach within the meaning of Article 33. It does not set the "reasonable degree of certainty" threshold, does not replace the judgment of a Data Protection Officer or legal counsel, and does not decide whether a given incident was reportable at all. Those remain interpretive and factual judgments for the organization, its advisers, and ultimately the supervisory authority.
The distinction matters because three different things are at stake, not one. A SIEM alert or an escalation ticket is a signal: evidence that something occurred at a given moment. Awareness is a legal threshold: a reasonable degree of certainty, reached by assessing one or more signals. Reportability is a further legal conclusion drawn from awareness. SOURCE 0 does not prove awareness. It preserves the signal from which awareness may later be assessed. A timestamped alert is evidence of a signal at a given moment; it is not, by itself, a legal finding that the controller was aware at that moment. What SOURCE 0 adds is narrower still: where internal detection signals — a SIEM alert, an escalation ticket, an internal incident log entry — are captured by the evidentiary layer at generation, with the capture path designed to preserve and technically attest the temporal relationship between the originating signal and its evidentiary capture, through deterministic SHA-256 hashing, RFC 3161 timestamping by two independent qualified trust service providers, and judicial deposit before a Belgian huissier de justice creating a dated judicial record under the applicable provisions of Book 8 of the Belgian Civil Code, the resulting Historical Reality Dossier gives a supervisory authority, or a court, a dated record of what signals existed and when — fixed before the organization's later characterization of "when we became aware" was recorded.
Two limitations follow directly from this architecture, and neither is a defect to conceal. First, a qualified timestamp establishes that the sealed data existed, in that form, at the certified time; it does not, on its own, prove the sealed data's account of the originating event's exact instant, nor that the event was interpreted correctly. SOURCE 0's evidentiary strength therefore depends on the integrity and temporal architecture of the capture path itself, not merely on the timestamp that follows it. Second, SOURCE 0 fixes the signals its evidentiary capture path actually receives; it does not certify the completeness of the originating detection system, and cannot supply evidence of a signal that system never generated. Neither limitation is unique to SOURCE 0 — no evidentiary mechanism can retroactively assert the existence of a signal that was never produced — but a precise architecture should state its own boundaries rather than leave them to be discovered by a contradictor.
The property this depends on is not simply engaging a third party; a third party can be selected, briefed, and paid by the organization under scrutiny, as Section V describes, without that relationship establishing independence of fixation. The property is exogenous pre-event fixation. Here, "exogenous" describes the evidentiary fixation path, not the commercial ownership of the architecture: the relevant question is whether the organization under scrutiny can alter, suppress, or retroactively rewrite the fixation event without that alteration itself becoming detectable — not who selected or paid for the system that performed it. The claim is not that ordinary logging, SIEM retention, or immutable storage is unreliable — it is that these mechanisms, however well operated, do not by themselves establish evidentiary independence from the environment whose timeline is later disputed; that is a different property, not a better or worse version of the same one. This does not resolve the legal question of awareness, and it does not transform a signal into a legal conclusion. It removes the condition under which the organization's later characterization can otherwise become the principal surviving evidence of its own internal detection timeline — whether that characterization was produced carefully and in good faith, as it may well have been, or not.
VII. WHEN THIS APPLIES, AND WHEN IT DOES NOT
Not every organization processing personal data faces this exposure with the same intensity. The relevant questions are whether the organization processes personal data at a scale or sensitivity where a breach is a realistic operational risk, whether reconstructing "when we became aware" after an incident would depend materially on internal records the organization alone produced and controls, and whether a contested awareness date would create meaningful regulatory, financial, or reputational exposure — as the Booking.com case above shows it can. Where the answers are yes, the absence of an independently fixed record of internal detection signals is not a neutral fact; it is a specific, describable gap the organization can choose to examine, address through another architecture demonstrating the same independence property, or knowingly accept.
VIII. THE LIMIT, STATED PLAINLY
SOURCE 0 does not determine whether a breach was reportable, does not set the 72-hour threshold or decide when it started, does not substitute for a DPO's or counsel's judgment, and does not apply retroactively — internal signals that were never sealed before an incident cannot be reconstructed after the fact. It seals a defined set of records; it does not certify that an organization's broader breach-response process was adequate.
CLOSING AXIOM
The 72 hours do not begin when the organization later says they began. They begin when the legal threshold of awareness was reached — a fact the organization must initially assess, and a regulator may later reconstruct differently. The question is therefore not who gets to name the moment, but what evidence survives to allow that moment to be assessed. SOURCE 0 fixes defined evidentiary signals before the timeline becomes contested.
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 article discusses the general framework of Regulation (EU) 2016/679 (GDPR), Article 33, and the European Data Protection Board's Guidelines 9/2022 on personal data breach notification, together with a publicly reported 2026 security incident cited strictly for its structural, illustrative value — no statement in this article alleges that the named organization violated any legal obligation. This document is authored by Jean-François ELSEN and constitutes an original doctrinal work forming part of the SOURCE 0 Doctrine Series.
Primary sources referenced: Regulation (EU) 2016/679, Article 33; EDPB Guidelines 9/2022 on personal data breach notification under GDPR; EDPB, "Dutch SA fines Booking.com for delay in reporting data breach".
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 supervisory authority or court 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 the GDPR or any other cited regulation should consult qualified counsel or their Data Protection Officer in the relevant jurisdiction before relying on any position stated here.
FREQUENTLY ASKED QUESTIONS
Does the GDPR require proof of when a controller actually became aware of a data breach?
Article 33(5) requires the controller to document the facts of the breach and the remedial action taken, but that record is maintained by the controller and forms part of its own evidentiary record — the provision does not itself require an exogenous pre-event fixation of the underlying detection signals. Where the disputed fact is when internal detection signals first existed, SOURCE 0 provides a record sealed before the organization's own characterization of its awareness date was produced.
Can a supervisory authority contest a controller's stated awareness date?
Yes. In its 2021 enforcement action against Booking.com, the Dutch supervisory authority fined the company €475,000, applying an awareness date of 13 January 2019 based on two emails describing suspicious activity, while Booking.com maintained that awareness was reached only on 4 February, once its internal investigation concluded. Booking.com did not contest the fine.
Does hiring an independent security firm after a breach solve this problem?
Not the same problem. A post-incident audit, even by a genuinely independent firm, typically examines whether the remedy applied was adequate — it begins after the organization has already determined its own awareness date, and does not independently fix that earlier moment.
Does documenting a breach internally, as Article 33(5) requires, satisfy the evidentiary gap described here?
No. Internal documentation is produced entirely by the controller, using records the controller itself holds and could revise before disclosure. SOURCE 0 does not replace that documentation; it seals the underlying detection signals before the controller's account of them is finalized.
How does SOURCE 0 differ from a SIEM alert log or an internal incident ticketing system?
Those systems may provide strong integrity and immutability controls, but those properties do not by themselves establish evidentiary independence from the environment whose timeline is later disputed. SOURCE 0 seals a defined set of records, at generation, through a third-party judicial deposit process materially and legally separate from the organization's own systems.
If a breach has already occurred and no prior sealing was in place, can SOURCE 0 help establish the awareness date after the fact?
No. The architecture depends on sealing preceding the moment it will later be relied upon to date. Detection signals that were never sealed before an incident cannot be reconstructed after the fact.
Is SOURCE 0 required by Article 33 of the GDPR?
No. Article 33 does not require SOURCE 0, nor does it prescribe any specific mechanism for independently fixing detection signals. SOURCE 0 addresses a narrower evidentiary question: whether the signals from which a disputed awareness date may later be reconstructed were fixed before the timeline became contested, by a mechanism materially separate from the controller's operational environment. An organization may address that question through SOURCE 0 or through another architecture demonstrating the same property.
