Article 33: Notification of a personal data breach to the supervisory authority

To meet the article 33: notification of a personal data breach to the supervisory authority requirement, you must have an operational process that (1) decides whether a personal data breach is reportable, (2) notifies the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, and (3) documents your decision and timing. (Regulation (EU) 2016/679, Article 33)

Key takeaways:

• Start the clock at “becoming aware” and prove when that happened with durable records. (Regulation (EU) 2016/679, Article 33)
• If you don’t notify within 72 hours, include reasons for the delay in the notification package. (Regulation (EU) 2016/679, Article 33)
• If you decide not to notify because the breach is unlikely to create risk to individuals, keep a defensible decision record. (Regulation (EU) 2016/679, Article 33)

Article 33 is a time-bound operational requirement. Regulators don’t want a perfect narrative after the fact; they want a working breach-notification machine that can triage quickly, make a risk decision, and communicate to the right supervisory authority on time. The legal standard is specific: notify “without undue delay” and, where feasible, within 72 hours after you become aware of the breach, unless the breach is unlikely to result in risk to people’s rights and freedoms. (Regulation (EU) 2016/679, Article 33)

For a Compliance Officer, CCO, or GRC lead, operationalizing Article 33 means converting legal text into a repeatable incident workflow with named owners, decision criteria, and evidence. This page focuses on what to implement so you can execute under pressure: how to define “awareness,” how to decide whether notification is required, how to route to the competent authority, and what to retain so you can defend your choice to notify (or not) during a supervisory inquiry or customer diligence review. (Regulation (EU) 2016/679, Article 33)

Regulatory text

Operator reading of the rule: If you are a controller and a personal data breach occurs, you must notify the competent supervisory authority without undue delay and, where feasible, no later than 72 hours after you become aware of it, unless the breach is unlikely to result in a risk to individuals’ rights and freedoms. If you miss the 72-hour window, you must include reasons for the delay. (Regulation (EU) 2016/679, Article 33)

What you must do in practice:

1. Detect and escalate suspected personal data breaches to a function that can make the Article 33 decision quickly. (Regulation (EU) 2016/679, Article 33)
2. Record the moment you “became aware” and treat it as the start of the notification timer. (Regulation (EU) 2016/679, Article 33)
3. Decide whether the breach is “unlikely to result in risk” to individuals; if it is not unlikely, prepare notification to the competent supervisory authority. (Regulation (EU) 2016/679, Article 33)
4. If you notify after 72 hours, document and provide the reasons for delay as part of the notification. (Regulation (EU) 2016/679, Article 33)

Plain-English interpretation

• You don’t get to wait for perfect forensics. Article 33 is built for partial information. You notify based on what you know, then continue investigating and managing remediation. The key is disciplined decisioning and documentation tied to the “aware” timestamp. (Regulation (EU) 2016/679, Article 33)
• The exception is narrow. You can skip notifying only when the breach is unlikely to result in risk to individuals’ rights and freedoms. Treat that as a decision you must be ready to defend with facts, not a default. (Regulation (EU) 2016/679, Article 33)
• “Without undue delay” is the standard even inside the 72-hour window. If you sit on an incident for internal convenience, you create avoidable exposure even if you technically file before the deadline. (Regulation (EU) 2016/679, Article 33)

Who it applies to (entity and operational context)

Applies to: Organizations acting as a controller for EU GDPR personal data processing where a personal data breach occurs. (Regulation (EU) 2016/679, Article 33)

Operational contexts where this shows up:

• Security incidents (ransomware, credential compromise, misconfiguration) that create accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data.
• Product incidents (logging personal data into a shared workspace, shipping data to the wrong customer tenant, exposing a bucket or endpoint).
• Third-party incidents where your processor or sub-processor is involved; you still need a controller-ready workflow to assess notification needs and act quickly once you are “aware.” (Regulation (EU) 2016/679, Article 33)

Role clarity is a gating item: If teams cannot quickly answer “Are we controller or processor for the affected processing?”, your 72-hour clock will burn while people debate scope. Maintain a role-and-scope register covering systems, data categories, and controller/processor role decisions for common processing activities. (Regulation (EU) 2016/679, Article 33)

What you actually need to do (step-by-step)

Step 1: Define triggers and an intake path

Create a single “suspected personal data breach” intake route (ticket type, hotline, or incident channel) used by Security, IT, Engineering, Customer Support, and third-party management. The intake must force capture of minimum fields: system, data types, initial detection time, and reporter. (Regulation (EU) 2016/679, Article 33)

Practical control: A one-page runbook embedded into your incident tooling that tells responders when to escalate to Privacy/Legal for Article 33 assessment. (Regulation (EU) 2016/679, Article 33)

Step 2: Establish “awareness” and start the timer

Define, in procedure, who can declare organizational “awareness” (often Incident Commander + Privacy/DPO or Legal). Record:

• Timestamp of first credible indication
• Timestamp of formal “aware” declaration
• Who declared it and why

You need this because the deadline is measured from “having become aware.” (Regulation (EU) 2016/679, Article 33)

Step 3: Triage risk to individuals (reportability decision)

Stand up a rapid assessment checklist that answers: is it unlikely to result in risk to rights and freedoms? If you cannot support “unlikely,” prepare to notify. (Regulation (EU) 2016/679, Article 33)

Decision record should capture:

• What happened (high-level facts)
• Categories of personal data involved (or believed involved)
• Approximate scope (use ranges if unknown; don’t fabricate precision)
• Who is affected (customers, employees, end users)
• Exposure type (unauthorized access, disclosure, loss)
• Mitigations already taken (access revoked, system isolated)

Tie each conclusion to evidence (logs, screenshots, vendor notice, incident notes). (Regulation (EU) 2016/679, Article 33)

Step 4: Identify the competent supervisory authority

Article 33 requires notifying the supervisory authority competent under Article 55; operationally, you need a maintained mapping of:

• Your EU establishment(s) and which authority is your primary point of contact (where applicable)
• Which products/business lines process EU personal data
• Who is authorized to submit notifications and through which portal/email channel

Maintain this as a living artifact with owners and update triggers (new EU office, acquisition, new processing activity). (Regulation (EU) 2016/679, Article 33)

Step 5: Draft and submit the notification package

Build a standard notification template aligned to Article 33 so responders fill blanks rather than write from scratch. The template must include:

• Time of awareness and time of submission
• Summary of the breach
• Why you believe notification is required (risk rationale)
• If late, reasons for delay (required when not within 72 hours) (Regulation (EU) 2016/679, Article 33)

Operating tip: Put Legal/Privacy approval gates where they speed decisions, not where they block them. Pre-authorize alternates for weekends and holidays.

Step 6: If you don’t notify, document “why not” like you expect to defend it

The most common audit failure is not the choice itself; it’s the lack of a defensible record. If you rely on the “unlikely to result in risk” exception, retain a signed decision record with the facts known at the time. (Regulation (EU) 2016/679, Article 33)

Step 7: Close the loop with third parties and internal remediation

Even though Article 33 focuses on notifying the authority, your process must integrate:

• Third-party incident notices (processors/sub-processors) into your intake queue
• Post-incident corrective actions into your risk register and control backlog

This is where tools like Daydream fit naturally: you can centralize evidence packets, track decision approvals, and maintain a role-and-scope register so responders don’t waste time re-litigating controller vs. processor in the middle of an incident. (Regulation (EU) 2016/679, Article 33)

Required evidence and artifacts to retain

Create an “Article 33 evidence packet” per incident (not only for reportable ones):

• Incident timeline (detection, awareness, containment, assessment milestones) (Regulation (EU) 2016/679, Article 33)
• Awareness declaration record (timestamp, approver, rationale) (Regulation (EU) 2016/679, Article 33)
• Risk assessment checklist and decision memo (notify vs. no-notify) (Regulation (EU) 2016/679, Article 33)
• Supervisory authority determination (which authority, why it’s competent)
• Notification submission proof (portal confirmation, email header, case number), if sent
• Late-submission rationale, if applicable (Regulation (EU) 2016/679, Article 33)
• Internal approvals (Privacy/DPO, Legal, Security lead)
• Third-party communications relevant to the breach (processor notice, hosting provider ticket)
• Remediation tracking (root cause summary and corrective actions)

Common exam/audit questions and hangups

Auditors and regulators tend to probe the same pressure points:

• “Show me how you define and record the moment you became aware.” (Regulation (EU) 2016/679, Article 33)
• “Demonstrate that you can notify within 72 hours, including weekends and holidays.” (Regulation (EU) 2016/679, Article 33)
• “For incidents you did not notify, show the documented basis for ‘unlikely to result in risk.’” (Regulation (EU) 2016/679, Article 33)
• “How do third-party incidents enter your workflow, and who owns the controller decision?”
• “Who can submit to the authority, and what is the approval path under time pressure?”

Hangup to expect: teams confuse “incident discovered” with “organization became aware.” Your process must define awareness clearly and show consistent practice. (Regulation (EU) 2016/679, Article 33)

Frequent implementation mistakes (and how to avoid them)

1. Policy-only compliance. A written policy that says “notify within 72 hours” fails if there’s no ticketing trigger, no template, and no on-call approvals. Build the workflow in the tools people already use. (Regulation (EU) 2016/679, Article 33)
2. No role clarity during incidents. If ownership depends on ad hoc debate about controller vs. processor, you lose time. Maintain a role-and-scope register for major systems and processing activities. (Regulation (EU) 2016/679, Article 33)
3. Treating the exception as the default. “Unlikely to result in risk” requires a reasoned record. Use a checklist and require documented sign-off for no-notify decisions. (Regulation (EU) 2016/679, Article 33)
4. Late notification without a delay narrative. If you miss the 72-hour window, your submission must include reasons for the delay. Draft that section as carefully as the breach summary. (Regulation (EU) 2016/679, Article 33)
5. Evidence scattered across chat and email. During an inquiry, you need a single evidence packet. Centralize artifacts and lock them from editing after closure.

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for this requirement, so this page does not list case examples. Your risk posture should still assume that timing, documentation quality, and a defensible risk decision will be tested if the authority becomes aware of the incident through other channels (for example, complaints or media reporting). (Regulation (EU) 2016/679, Article 33)

A practical 30/60/90-day execution plan

First 30 days (stand up the minimum viable process)

• Assign owners: Incident Commander, Privacy/DPO or Legal approver, Security lead, communications lead. (Regulation (EU) 2016/679, Article 33)
• Publish an Article 33 runbook: triggers, intake route, awareness declaration, decision criteria, notification template. (Regulation (EU) 2016/679, Article 33)
• Create the evidence packet structure in your GRC or case management system (Daydream or equivalent) and require it for every suspected personal data breach. (Regulation (EU) 2016/679, Article 33)

Days 31–60 (make it repeatable under pressure)

• Build an on-call/backup approval path so decisions and submissions are possible outside business hours. (Regulation (EU) 2016/679, Article 33)
• Maintain a supervisory authority contact/method list and an internal “who can submit” roster. (Regulation (EU) 2016/679, Article 33)
• Start the role-and-scope register for top systems and third parties involved in EU personal data processing. (Regulation (EU) 2016/679, Article 33)

Days 61–90 (prove it works and fix gaps)

• Run tabletop exercises using realistic scenarios: cloud misconfig, phishing exfiltration, processor breach notice. Capture lessons learned and update the runbook. (Regulation (EU) 2016/679, Article 33)
• Add metrics that do not require external benchmarking: time-to-awareness declaration, time-to-decision, completeness of evidence packets.
• Implement a closure review: every incident gets a documented notify/no-notify decision, even if preliminary facts are limited. (Regulation (EU) 2016/679, Article 33)

Frequently Asked Questions

What starts the 72-hour clock for Article 33?

The clock starts when you have “become aware” of a personal data breach, not when the incident first technically occurred. Your procedure should define who can declare awareness and require a timestamped record. (Regulation (EU) 2016/679, Article 33)

Can we wait to notify until we know exactly how many people were affected?

Article 33 expects notification without undue delay and, where feasible, within 72 hours after awareness. If scope is uncertain, document what you know, submit based on current facts, and continue investigation. (Regulation (EU) 2016/679, Article 33)

When can we decide not to notify the supervisory authority?

You can skip notification only if the breach is unlikely to result in a risk to the rights and freedoms of natural persons. Treat this as a formal decision that needs written rationale and supporting evidence. (Regulation (EU) 2016/679, Article 33)

What if we miss the 72-hour window?

You can still notify, but the notification must be accompanied by reasons for the delay. Build that “reasons for delay” section into your template so it is never forgotten. (Regulation (EU) 2016/679, Article 33)

How should we handle third-party (processor) breaches?

Route processor breach notices into the same intake workflow as internal incidents and quickly determine whether you are acting as controller for the affected processing. Your evidence packet should include the third party’s notice and your internal awareness timestamp. (Regulation (EU) 2016/679, Article 33)

What evidence will an auditor ask for first?

Expect requests for the incident timeline, the awareness declaration record, the notify/no-notify decision memo, and proof of submission (or documented rationale for not notifying). Store these together as a single evidence packet per incident. (Regulation (EU) 2016/679, Article 33)