GDPR Article 33 and NIS2 Article 23 both start their notification clocks at the moment of awareness; here is what that moment means under the EDPB's reading, and what an incident register has to record so you can prove when it happened.
GDPR Art. 33(1) reads: "In the case of a personal data breach, the controller shall without undue delay and, where feasible, not later than 72 hours after having become aware of it, notify the personal data breach to the supervisory authority competent in accordance with Article 55, unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons."
The load-bearing phrase is "after having become aware of it." The clock starts at a moment inside your organization, and months later a supervisory authority or an auditor can ask what time that moment was, and how you know. A ticket queue rarely answers that question. What follows derives what an incident register has to capture so the answer exists.
Start with the GDPR clock. Art. 33(1) has two qualifiers. Notification is owed unless the breach is "unlikely to result in a risk to the rights and freedoms of natural persons": someone has to assess risk, and that assessment happens against the clock. And a notification made after 72 hours "shall be accompanied by reasons for the delay," which turns a late filing into an argument about your own timeline. Art. 33(4) softens the content burden only: "the information may be provided in phases without undue further delay." Art. 33(2) gives processors their own trigger: notify the controller "without undue delay after becoming aware of a personal data breach."
None of this defines awareness. The regulation's preamble comes closest: recital 87 says it should be ascertained whether measures were in place "to establish immediately whether a personal data breach has taken place," and that timeliness is judged by the nature, gravity, and consequences of the breach. The working definition comes from the EDPB's Guidelines 9/2022 on breach notification (version 2.0, adopted 28 March 2023). Paragraph 31: a controller becomes aware "when that controller has a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised."
The test is fact-dependent. Paragraph 34 allows "a short period of investigation" after a first report (from an individual, a media organization, or your own detection) during which the controller "may not be regarded as being 'aware'." The investigation has to start as soon as possible and establish reasonable certainty; the detailed forensics can follow. One worked example shows how little certainty is needed: for a lost USB key with unencrypted personal data, the controller may never establish whether anyone accessed the data, but it becomes aware of an availability breach "when it realised the USB key had been lost." Paragraph 40 closes the loophole: failing to act on an initial alert in a timely manner, where a breach did occur, "could be considered as a failure to notify in accordance with Article 33 GDPR."
NIS2 runs a faster cascade for essential and important entities. Art. 23(1) requires notifying the CSIRT or competent authority "without undue delay" of any significant incident — significant, per Art. 23(3), when it "has caused or is capable of causing severe operational disruption of the services or financial loss for the entity concerned" or has affected or can affect others "by causing considerable material or non-material damage." Art. 23(4) then sets the schedule: an early warning "without undue delay and in any event within 24 hours of becoming aware of the significant incident," indicating where applicable whether unlawful or malicious acts are suspected and whether cross-border impact is possible; an incident notification "within 72 hours of becoming aware," with an initial assessment of severity and impact and, where available, indicators of compromise; an intermediate report on request; and a final report "not later than one month after the submission of the incident notification under point (b)" — the one-month clock runs from when you submitted the 72-hour notification, not from awareness. The final report has to include a detailed description with severity and impact, "the type of threat or root cause that is likely to have triggered the incident," and applied and ongoing mitigation measures. NIS2 is a directive; the obligations reach entities through national law transposing Art. 23.
The two regimes share one dependency. Every deadline in both is measured from a moment only your own records can establish. If your detection time is wrong, undocumented, or reconstructed after the fact, every argument about whether you notified in time inherits that weakness.
Art. 33(5) is the paragraph that makes this a records problem rather than a notification problem: "The controller shall document any personal data breaches, comprising the facts relating to the personal data breach, its effects and the remedial action taken. That documentation shall enable the supervisory authority to verify compliance with this Article."
The operative word is "any." The under-threshold breach you assessed as unlikely to result in a risk, the one you never notified, still generates a documentation duty, and the standard is in the same sentence: enough for the authority to verify compliance, including your decision not to notify.
The EDPB's guidelines make the practical shape explicit. Paragraph 122 ties the duty to the Art. 5(2) accountability principle, notes "the supervisory authority can request to see these records," and adds that controllers "are therefore encouraged to establish an internal register of breaches, regardless of whether they are required to notify or not." Paragraph 123 lists what to record: the causes, what took place, the personal data affected, the effects and consequences, and the remedial action taken. A footnote even allows the register to live inside the Art. 30 record of processing activities, provided the breach information "can be extracted upon request." The GDPR sets no retention period for the register; the controller determines one.
Measure a typical ticket queue against that standard. A ticket that was opened, worked, closed, and buried under three months of newer tickets holds fragments of the facts, few of the effects, and remedial actions scattered across comments with no structure. "Extract upon request" is exactly the operation it does not support.
Working backward from the three texts, a register entry that can carry the weight has five properties. A disciplined spreadsheet can hold all five.
None of this requires a particular tool. Whatever holds your register, the test is whether it holds these five things with timestamps you would show a regulator.
devguard ships an Incidents module, and the first thing to say about it is a boundary: it does not detect anything. It does not ingest alerts, connect to monitoring, or open incidents from webhooks. The paths that create one are the create form, a CSV import, and an assistant tool that acts when a user reports something went wrong. In every case, a human creates the record. That has a real cost: if nobody logs the incident, the register stays silent, and the gap between your monitoring stack firing and a person creating the record is entirely your process's problem. The reasoning follows the EDPB's paragraph 41: the ability to detect and address a breach in a timely manner is an element of your Art. 32 security measures, and that capability already lives in your alerting. The module picks up at awareness and structures everything after it.
The record itself is the five properties from the previous section. When an incident occurred and when it was detected are captured as separate timestamps, on purpose; the gap between them is the awareness argument. Resolution and closure get their own timestamps, and root cause and lessons learned have their own place on the record, written at closure. An incident moves through five statuses (open, investigating, contained, resolved, closed) and carries a severity on a four-step scale from low to critical, a scale that exists before the incident does. Scope is links: assets, risks, vendors, treatment actions, controls, and evidence attach to the record, each link carrying who made it and when. Actions-as-they-develop are timeline entries, each recording both when the action happened and when it was written down, with an author.
Flag an incident as a personal-data breach and a 72-hour notification deadline is computed from the detection time: awareness anchored at detection, per Article 33. As long as the deadline is auto-computed, it follows edits to the detection time; a hand-set value is left alone, and clearing the flag clears the deadline. It surfaces as a countdown on the incident and in the org-wide deadlines feed, where an unnotified breach stays visible regardless of lifecycle status. The dates the authority and the data subjects were notified are recorded alongside (the latter for the Art. 34 communication). And because Art. 33(5)'s standard is enabling the supervisory authority to verify compliance — the EDPB's guidelines put it as being able to extract the documentation on request — the whole thing exports as a PDF titled "Complete Incident Register," breach column included. [screenshot: incident detail page with the breach block countdown and timeline entries]
Most of an incident record can be reconstructed later from logs, chat history, and invoices. The moment your team reached a reasonable degree of certainty cannot; it exists only if someone wrote it down at the time. I would treat that one timestamp as the reason the register exists; everything else on the entry can be rebuilt around it if it has to be. Incident handling is also one of the control families that shows up in every framework at once; for how the same record serves NIS2, SOC 2 and the CRA together, see one control set for NIS2, SOC 2 and the CRA.
devguard's Incidents module is the register described above, with lifecycle timestamps, timeline, links, and the Article 33 clock: devguard.ch/platform.
Vadim leads engineering, the architecture, automation, and integrations that let compliance live. He's set on making a serious, audit-grade system genuinely easy to run.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.