Article 33 requires a controller to notify the supervisory authority of a personal data breach without undue delay and, where feasible, within 72 hours of becoming aware of it. The notice should summarise what happened, what data is affected, likely consequences, and the measures taken or planned. Keep internal escalation, triage, and evidence collection ready.
What Article 33 is trying to achieve
Article 33 is not just a timing rule, it is the legal mechanism that forces a controller to turn a suspected personal data breach into a documented, decisioned incident quickly. The practical question is whether you can determine scope, likely impact, and whether the threshold for notifying the supervisory authority has been met fast enough to preserve evidence and satisfy the clock.
The obligation is triggered when the controller becomes aware of the breach, so organisations need a clear internal definition of “awareness”, a fast triage path, and a record of who can make the notification decision. That matters because the 72-hour window is usually consumed by containment, fact gathering, legal review, and drafting the notice.
What a compliant notification normally contains
A useful Article 33 notice is short but complete. It should explain what happened, which data categories are affected, the likely consequences, and what the controller has already done or plans to do. That structure helps the authority understand whether the incident is contained, whether individuals may face real harm, and whether follow-up reporting will be needed.
Controllers should treat the notice as a live incident record, not a one-time form. Early versions are often incomplete, so teams need a process for supplementing facts, correcting assumptions, and keeping the chronology of events intact. If the full impact is still unknown, the initial notice should say so plainly and explain what is being investigated.
For teams that want a practical template, the Data Breach Notification Checklist is useful because it mirrors the steps regulators expect to see, including decision points, records, and timeline control.
How teams should prepare before the clock starts
The hardest part of Article 33 is rarely the legal wording, it is the operational readiness behind it. If your logging, asset inventory, and incident triage are weak, you will spend the first day just finding out what was exposed. That is why privacy incident handling depends on good detection, good evidence collection, and a preassigned escalation path that can move without waiting for a full postmortem.
Preparation should also include the ability to tell whether the breach is likely to create a high risk to individuals, because that often determines whether separate communication duties may follow. Encryption status, account scope, and whether access was authenticated all affect that judgement, since they influence both exposure and the likelihood that the breach can be considered controlled.
Where personal data may have been exposed through stolen devices or sessions, Lost or Stolen Device Response Checklist is a useful companion for the containment and evidence side of the workflow, especially when token revocation and rapid triage are needed before a notification can be finalised.
Risk and Threat Considerations
Article 33 creates operational risk when organisations cannot confirm facts quickly enough to meet the deadline, and it creates compliance risk when incident handling and legal review are not integrated. The threat side matters too, because attackers often exploit delayed detection, incomplete logging, or confusion over ownership to extend dwell time and increase the amount of data affected.
Failure mechanism: Notification fails when teams do not know when awareness started, cannot reconstruct the breach scope, or cannot preserve evidence while containment is under way. That can lead to late reporting, incomplete notices, and inconsistent facts across security, privacy, and legal teams.
Impact: The organisation may face regulatory scrutiny, missed deadlines, follow-up questions from the supervisory authority, and avoidable confusion about what data was affected and whether the breach was contained.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while GDPR and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| GDPR | Art. 33 — Notification of a personal data breach to the supervisory authority | This exact article governs breach-notification timing and content. |
| Recommendation — Notify the supervisory authority without undue delay and document the breach facts and response. | ||
| NIST CSF 2.0 | RS.CO-02 — Incidents are reported consistent with established criteria | Breach notification depends on clear reporting criteria and escalation paths. |
| Recommendation — Set reporting thresholds and route suspected breaches through a defined escalation path. | ||
| ISO/IEC 27001:2022 | A.5.24 — Information security incident management planning and preparation | Prepared incident handling supports meeting breach-notification deadlines. |
| Recommendation — Prepare incident handling procedures that preserve evidence and accelerate reporting decisions. | ||
| NIST SP 800-53 Rev 5 | IR-6 — Incident Reporting | Formal incident reporting controls align with breach notification workflows and deadlines. |
| Recommendation — Define who reports, what gets reported, and how quickly reporting must occur. | ||
| CIS Controls v8 | CIS-17 — Incident Response Management | Breach notification depends on a practiced response process with assigned roles and escalation. |
| Recommendation — Maintain and rehearse an incident response process that supports timely breach reporting. | ||
Practitioner Guidance
What to prioritise: Build the notification workflow around the first 24 hours of incident handling, not around the final notice. The practical priority is to capture the time of awareness, freeze the evidence trail, and assign one owner for the regulatory clock.
What to verify: Before you rely on the notification draft, verify that the incident record answers four questions: what happened, what data was affected, what has been contained, and what is still unknown. If any of those are unresolved, the notice should reflect that uncertainty rather than guess.
Decision rule: If the event may involve personal data and the controller has enough facts to suspect a real breach, start the breach-notification path immediately and refine the notice as facts improve. Do not wait for perfect certainty if the clock is already running.
Practitioner takeaway: Article 33 works best when breach notification is treated as an incident-management discipline with legal deadlines, not as a privacy paperwork exercise that starts after containment.