Data breach notification: what you must be able to prove

Published August 20, 2026

A data breach notification is a set of statements made under pressure, inside 72 hours, often at night, before anyone has the full picture. You declare when you became aware, what data was involved, how many people it affects, what you did about it. The authority acknowledges the filing.

Months later someone asks a different question: how do you know? Not what you declared, but what you can show. An audit, a complaint from a data subject, a claim on a cyber policy. The notification stops being a form and becomes a claim you have to substantiate, and most organizations are thin exactly there. What they rarely have is evidence a third party would accept about the four facts it rests on: when the incident was detected, what it touched, who decided what, and what was done to contain it.

What the law actually requires when you notify a data breach

A personal data breach is a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data. Under Article 33 GDPR the controller notifies the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it.

The clock runs from awareness, not from the intrusion. The EDPB Guidelines 9/2022 treat a controller as aware once it has a reasonable degree of certainty that a security incident has occurred and compromised personal data, which makes detection a legal fact rather than an operational detail. Notification is not required where the breach is unlikely to result in a risk to the rights and freedoms of natural persons, and a late filing must carry the reasons for the delay. Failure to notify sits under Article 83(4)(a): up to 10 million euro or 2% of worldwide annual turnover, whichever is higher.

The GDPR and NIS2 reporting windows

One incident can start two clocks at once. Personal data pulls you into the GDPR track and its supervisory authority. Service disruption at an entity in scope of NIS2 pulls you into incident reporting and its national CSIRT. Neither excuses the other.

The 24-hour early warning lands before forensic work has concluded anything. You describe an incident you do not yet understand, on the strength of what your team saw on a screen, and that description is what the regulator holds you to. Which is why, for entities running essential services, data integrity inside the NIS2 perimeter is a reporting problem before it is a technical one.

The obligations that survive the notification

Filing does not close the file. Article 33(5) GDPR requires the controller to document every personal data breach, including the facts, the effects and the remedial action taken, in a form good enough for the supervisory authority to verify compliance. The obligation covers breaches you decided not to notify: if you judged the risk unlikely and stayed silent, the assessment is what you will be asked to produce.

Article 34 GDPR adds communication to the data subjects where the breach is likely to result in a high risk to them, unless measures such as encryption already protected the data. Article 33(4) allows information to be supplied in phases, so a filing with gaps is legally provided for. What is not provided for is filling those gaps later with material nobody can date.

The four things an organization must be able to prove

The notification asks you to declare four elements. Any later review asks you to demonstrate them, which is a different exercise. Article 5(2) GDPR makes the controller responsible for compliance and able to demonstrate it, and that quietly moves the burden: it is not for the authority to show you were slow, it is for you to show you were not. A story assembled in a spreadsheet six months on is not a demonstration.

1. Detection time: the moment the organization became aware, and from what evidence.
2. Scope: which data categories, records and systems the incident actually touched.
3. Decisions: who assessed the risk, who authorized each step, and when.
4. Measures: what was done to contain, remediate and prevent recurrence.

The exact moment the incident was detected

Detection time starts the 72 hours and decides whether you were prompt or late. It is the most consequential number in the filing and, almost always, the least evidenced. Ask a team how it knows detection happened at 23:14 and the answer is a SIEM entry: a file on infrastructure the organization controls, stamped by a clock it administers. None of that is dishonest and all of it is contestable. It is the one fact no external party can corroborate for you, unless you arranged corroboration while it was happening.

The scope of data and systems involved

Scope changes shape while you work, and Article 33(3) accepts approximation on the categories and numbers of data subjects and records. Review examines whether your method was reasonable and your revisions honest, not whether the first estimate was right. That is provable only if the intermediate states survive. Once you have patched, rotated credentials and rebuilt a server, the environment that justified the original assessment is gone. A coherent audit trail across data lineage helps, though lineage answers where data moved, not what a responder saw.

The decisions taken, and by whom

Regulators read an incident as a sequence of decisions. Who called it reportable. Who judged the risk to individuals high or not. Who signed off on the wording sent to customers. Article 33(3)(b) requires the notification to name a contact point, typically the data protection officer. Most of that trail lives in email and chat, written quickly by people not thinking about evidence, which is why certifying internal communications with legal value matters more here than for other business records.

The measures adopted to contain and remediate

Containment gets described in good faith and documented almost never. “We isolated the affected segment and forced a credential reset” is a true sentence that leaves no trace of its own truth. It surfaces in ticketing systems and change logs, internal records with the same weakness as the rest. The fix costs almost nothing while the incident is running: capture the state before the measure and after it, from the console that shows it.

Why internal logs are not enough as proof

An internal log is an editable file, produced and stored by the same organization that has to demonstrate its own diligence. Nobody is accusing anyone of bad faith. It is a structural position, and it holds whatever your intentions were. The value of digital evidence rests on the integrity of the process that produced it, which is why forensic practice separates collection from the party with an interest in the content.

Editable files produced by the party that has to demonstrate its own diligence

Retention requirements solve availability. They say nothing about whether the record you produce is the one that existed on the night of the incident, and compliance programs routinely treat the first problem as though it settled the second. A forensic copy has evidentiary value because it is bound to a verifiable process: an acquisition method, a cryptographic digest, an unbroken record of custody. A log exported to CSV when the lawyers ask has none of that: no tamper evident record behind it, just a fresh file.

How log evidence is challenged, and what happens to the burden of proof

The challenge is rarely dramatic. The other side simply observes that the file was under your exclusive control, that its timestamps come from a clock you administer, and that no independent record corroborates it. That moves the discussion from what the log says to whether it can be relied on, and the work of re-establishing reliability falls on you. The dynamic is familiar from the objections raised against screenshots offered as evidence: the image is not disputed as a picture, it is disputed as a representation of a real screen at a real time. Incident response stays with the security team, and that does not change. TrueScreen operates on the layer that makes what the team saw and decided provable to a third party.

How to collect evidence that survives a challenge

Evidence has to be secured while the incident is live, by a process that does not depend on your later word. ISO/IEC 27037, the international standard for handling digital evidence, is built around identification, collection, acquisition and preservation carried out so that relevance and reliability can be shown afterwards, with a documented chain of custody running from the first touch.

What to certify while handling the incident

Certify what a person actually looked at when they made a decision: the alert or console view at detection, the dashboards used to scope the incident, the internal messages that escalated it, the administrative pages consulted, the state of controls before and after each containment measure. Two habits pay for themselves: certified screen recording with an unbroken chain of custody for analysis sessions, because a recording keeps the sequence that a series of stills loses, and forensic capture of authenticated views, since restricted areas behind a login hold the decisive information.

When to certify: capture at the time versus export after the fact

Capturing at the time and exporting afterwards are not two routes to the same result. An export produced a week later proves only that a file existed on the day of the export. It cannot establish what the system displayed on the night in question, because the only witness is the person who was looking, and their account is what is under examination.

Certification at the moment of collection moves the temporal reference. When a review arrives months later, TrueScreen lets you trace back to the exact moment each piece of evidence was collected, because the timestamp was applied by a third party at capture and not reconstructed afterwards. The same logic extends to files: certifying a digital file as it is extracted binds the export to a verifiable point in time.

How to certify incident evidence while you are still handling the incident

Certifying evidence at the moment of collection means fixing content and time together, through a party with no stake in the outcome. TrueScreen, the Data Authenticity Platform, certifies monitoring console screenshots at the moment they are captured, applying a qualified timestamp and electronic seal through a third-party trust service provider. A cryptographic digest is calculated at capture, so later alteration is detectable, and the qualified timestamp under eIDAS carries a presumption of accuracy for the date and time it indicates. Organizations use TrueScreen to certify log extracts, internal communications and pages consulted during incident handling, so the evidence is not produced unilaterally by the party that has to demonstrate its own diligence. Where volume justifies it, the same certification runs through an API inside the response workflow.

It is 23:14 on a Friday. The SOC sees outbound volume from a file server climbing past baseline. The duty engineer opens the console, reads the graph, isolates the segment. On Monday the organization gives 23:14 Friday to the supervisory authority as the moment of awareness. Six months later the question arrives: from what record does it follow that the console showed that data at that hour? The SIEM entry is a file the organization kept. The console view, certified while the engineer was looking at it and timestamped by a third party, is a different kind of answer.