GDPR Article 33 sets a 72-hour clock for breach notification to supervisory authorities — and the clock starts not when the breach occurred, but when the controller becomes aware of it. For organisations with complex, distributed data infrastructure, this creates a scoping challenge that can be impossible to meet without prior classification work: the notification requires specifying which personal data categories were affected and approximately how many data subjects are involved. Without a current data inventory, these questions cannot be answered accurately in 72 hours.
This article examines the Article 33 notification requirements in detail, the operational gap that underprepared organisations face during incident response, and how pre-breach classification infrastructure transforms the scoping timeline from days to minutes.
What “becoming aware” means operationally
The EDPB’s Guidelines 01/2021 on personal data breaches clarify that a controller “becomes aware” when it has a reasonable degree of certainty that a security incident has occurred that has led to a personal data breach. Awareness does not require a complete investigation — it requires enough information to conclude that a breach has likely occurred and involves personal data.
In practice, this means the 72-hour clock often starts before the full scope of the breach is understood. A server intrusion detected at 14:00 on a Tuesday starts the clock even if the investigation to determine which systems were accessed won’t complete until Thursday. Article 33(4) accommodates phased notification: an initial notification within 72 hours followed by supplementary information as the investigation progresses. The EDPB has confirmed that incomplete initial notifications are acceptable provided the phased approach is used in good faith — but the initial notification cannot be blank. It must contain whatever is known at the time of notification.
What the Article 33 notification must contain
Article 33(3) specifies five categories of required information. First: the nature of the breach, including the categories and approximate number of data subjects concerned, and the categories and approximate number of personal data records concerned. Second: the name and contact details of the Data Protection Officer or other contact point. Third: the likely consequences of the breach. Fourth: the measures taken or proposed to address the breach, including measures to mitigate its possible adverse effects.
The first category — data categories and subject counts — is where underprepared organisations face the most difficulty. Answering “which categories of personal data were involved” requires knowing what personal data was present in the compromised system. Answering “approximately how many data subjects” requires either a row count or a reliable estimate derivable from the system’s data model. Neither answer is accessible without a prior classification effort.
In a Table-level Snowflake breach scenario affecting an analytics mart, the responding team needs to know: are these tables classified as containing email addresses, health indicators, financial data, or device identifiers? Without pre-existing column-level classification, the team is conducting emergency manual review of 200+ columns under a 72-hour deadline — a data forensics exercise, not an incident response.
Why breach scoping requires continuous pre-breach classification
The only way to answer “which personal data categories were affected” quickly in a breach scenario is to have classified the data before the breach. A system that continuously classifies personal data fields across all connected sources means that when an incident descriptor is provided — affected systems, approximate timeframe, affected table list — the compliance team can immediately query the classification graph to determine which personal data fields were present in those tables, what categories they represent, and how many data subjects may be involved.
This transforms breach scoping from a multi-day manual exercise into a sub-10-minute query. The incident response team provides the list of affected tables; the classification graph returns the personal data inventory for those tables; the compliance officer assembles the Article 33 notification from the returned data. The 72-hour window becomes a manageable operational challenge rather than an impossible one.
Special-category data and the severity threshold
GDPR Article 9 special-category data — health, biometric, racial or ethnic origin, political opinion, religious belief, trade union membership, sexual orientation, criminal record — triggers higher severity breach notifications and potentially Article 34 communication obligations to affected data subjects. Knowing whether special-category data was involved is therefore not just a classification question; it determines the entire regulatory response path.
A breach affecting ordinary personal data (email addresses, names, postal codes) may require only supervisory authority notification, with no obligation to notify individual data subjects if appropriate technical safeguards (encryption, pseudonymisation) were in place. A breach affecting Article 9 data, or data of children, carries a substantially higher likelihood of triggering the Article 34 communication requirement — a costly and reputationally significant obligation. Getting the classification right before the breach is, in this context, the difference between a contained notification and a public communication campaign.
The role of data lineage in breach scoping
Lineage information amplifies breach scoping accuracy in ways that flat classification cannot. When a table is compromised, the lineage graph shows not just the fields in that table, but how those fields arrived there — which source systems they came from, which transformations they passed through. This matters for two reasons.
First, it determines whether a breach in a derived table implies exposure at the source level. If a Snowflake analytics mart was compromised and that mart was derived from a raw events table containing email addresses, lineage shows whether the email addresses survived the transformation into the mart or were aggregated away. Second, it identifies parallel derived tables: if the compromised mart is one of several downstream consumers of the same raw events source, lineage surfaces the other potential exposure points that the initial incident scope might have missed.
The Article 33 report template
Several EU supervisory authorities publish standardised breach notification templates or web-form tools that map directly to the Article 33(3) requirements. The Irish DPA and the German DSK both provide structured notification formats. A well-structured breach scoping output from a classification system maps directly onto these templates: affected data categories, estimated data subject count, DPO contact, breach description, consequence assessment, and mitigation measures.
Generating this output from a classification graph takes minutes. Generating it from manual investigation takes days. The difference is not procedural; it is infrastructural — and it is deterministic in that pre-breach investment in classification yields post-breach notification speed regardless of the specific incident type.
Conclusion
Article 33’s 72-hour window is survivable for organisations with current personal data classification. For those without it, the window is frequently insufficient to produce a complete, accurate notification — resulting in incomplete initial notifications, supplementary notification filings, and in some cases regulatory scrutiny of the classification gap as a secondary compliance failure. Breach readiness is, in large part, a classification readiness problem.
Source notes
- GDPR Articles 33 and 34 — breach notification to supervisory authority and data subjects
- European Data Protection Board, Guidelines 01/2021 on Examples regarding Personal Data Breach Notification (version 2.0, adopted 2021) — phased notification, awareness threshold, and severity criteria
- European Data Protection Board, Guidelines 09/2022 on personal data breach notification under GDPR — Article 33(3) content requirements and supplementary notification process
- Data Protection Commission (Ireland), Personal Data Breach Notification Form (2022) — structured notification template aligned to Article 33(3)
- Konferenz der unabhängigen Datenschutzaufsichtsbehörden des Bundes und der Länder (DSK), Kurzpapier Nr. 18: Meldepflicht nach Art. 33 DSGVO (2019) — German DPA guidance on breach notification scope and timing
