Data breach: timestamping your response timeline and the 72-hour notification
When a data breach hits, the GDPR requires notifying the supervisory authority within 72 hours and documenting the incident. You also need to prove when you detected, decided, acted. Electronic timestamping freezes that timeline, record by record.
Friday, 6:40 pm: a vendor flags abnormal access to a customer database. What follows is a race against the clock framed by the GDPR: qualify the incident, decide whether to notify, do it within 72 hours. Six months later, during an audit, one simple question: "at what exact moment did you become aware of the breach?" Your answer will be worth what your evidence is worth.
DPOs and CISOs already document their incidents. The missing link is usually a defensible dating of that documentation: proving the analysis report really existed on Saturday morning, that the decision to notify was made on Sunday, that the register was not filled in after the fact. That is precisely what electronic timestamping freezes.
What the GDPR requires: notify fast, document everything
Article 33 of the GDPR requires notifying any personal data breach to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it, unless the breach is unlikely to create a risk for individuals. Past that deadline, the notification must explain the delay. Article 34 adds, where the risk is high, communication to the affected individuals.
Less discussed, Article 33(5) requires documenting all breaches (facts, effects, measures) in a way that allows the authority to verify compliance. Supervisory authorities, including France's CNIL, expect this internal documentation in every case, including for incidents that were not notified, where the classification must be justified.
Two obligations, then: speed, and the record. The second is what lets you demonstrate the first.
The weak point of incident files: self-declared dates
A breach register is usually an internal document (spreadsheet, ticketing tool, shared folder) editable by the people who keep it. In normal times, no problem. The day the timeline becomes contentious (a regulator's audit, litigation with affected individuals, a dispute with the vendor behind the incident), its value rests on trusting the declarant.
And the sensitive questions are precisely questions of date:
- When did you become aware of the breach? That starts the 72-hour clock, not the date of the incident itself.
- When was each measure decided, then applied?
- Was the register filled as events unfolded, or reconstructed afterwards?
An electronic timestamp answers with a technical fact: this document (this alert, this report, this version of the register) existed in this exact form at this date, and has not been touched since.
Which records to timestamp during an incident?
The principle: timestamp each record the moment it is settled, building a staircase chronology no one can rewrite, not even you.
| Step | Record to timestamp | What the date establishes |
|---|---|---|
| Detection | Alert, ticket, report email | The start of the 72-hour clock |
| Qualification | Initial analysis report, DPO opinion | The speed and seriousness of the assessment |
| Decision | Decision note (notify / not notify, reasons) | The date of the choice and its justification |
| Notification | Copy of the form sent to the authority, receipt | Meeting the deadline |
| Communication | Message to affected individuals (if any) | Performance of Article 34 |
| Remediation | Evidence of measures (patches, revocations, audits) | The reality and date of the actions |
| Closure | Consolidated version of the register entry | The final state of the file, frozen |
Supervisory authorities' notification portals date the submissions they receive. Independent timestamping does not replace that: it covers everything around it (detection, analysis, decisions, measures) whose dating otherwise rests solely on your internal systems.
Each timestamp takes seconds. Across a full incident, a dozen records are enough to turn a declarative account into a technically dated chronology.
Blockchain and personal data: the right technical gesture
Timestamping incident records raises a fair question: can you anchor documents that, by definition, contain personal data on a blockchain? The answer lies in what you anchor.
In July 2026 the EDPB adopted the final version of its guidelines on processing personal data through blockchain technologies: the immutability and lack of native erasure of public chains make writing personal data in the clear problematic. We broke these guidelines down in a dedicated article.
The sound process never writes the document itself: only its SHA-256 hash is anchored, a 64-character fingerprint that reveals nothing of the content. The incident report stays on your systems, under your retention schedules. One honest caveat: depending on context, the hash of personal content may itself remain personal data; the reasoning to document in your assessment is covered in our GDPR and timestamping guide.
What it proves, what it does not
- Proven: each timestamped record existed in this form at this date; the chronology of your documentation is real, not reconstructed.
- Not proven: that your measures were the right ones, that the incident was correctly qualified, that the breach is not attributable to you.
Timestamping establishes chronological diligence, not substantive compliance. A dated file does not prevent a fine if the notification came late or the measures fell short: it only lets you demonstrate, rather than assert, what you did and when. That is already a lot: in an audit, the burden of demonstration is on you.
Where does LegalStamp fit in?
LegalStamp timestamps your incident records without them leaving your systems: the SHA-256 hash is computed locally in the browser, then anchored on the Bitcoin blockchain via OpenTimestamps. No content (report, alert, register) is transmitted, which sits well with the EDPB's recommendations on public blockchains. Each receipt is independently verifiable, including by an auditor or a regulator, and remains so even if LegalStamp disappears.
It is a non-qualified timestamp under eIDAS: it does not carry the presumption of accuracy reserved for qualified timestamps, and the weight given to the chronology remains for the authority or the court to assess. For an incident-documentation practice, where the alternative is an internal register with no defensible dating, this level meets the need, at a cost compatible with systematic use.
The best time to test a dating chain is outside any incident. The free plan gives you 3 timestamps a month, no credit card. Try it free →
Conclusion
Facing a data breach, the GDPR asks you to act fast and to be able to prove it. Most organizations manage the first; demonstrating the second too often rests on internal documents dated on the honor system. Timestamping the key records as the incident unfolds (detection, analysis, decision, notification, remediation) costs a few minutes and freezes a chronology that neither a regulator nor an opposing party can suspect of having been rewritten.
Disclaimer: this article is provided for informational and educational purposes. It does not constitute legal advice. For a specific case (dispute, compliance, proceedings), have your evidence strategy validated by a legal professional.
