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

GDPR Article 33 requires you, as a controller, to notify the competent supervisory authority of a personal data breach without undue delay and, where feasible, within 72 hours of becoming aware of it, unless the breach is unlikely to result in risk to individuals’ rights and freedoms (Regulation (EU) 2016/679, Article 33). Operationalize this by defining “awareness,” standing up a 72-hour breach clock workflow, and keeping a defensible decision record for notify vs. no-notify calls.

Key takeaways:

• Start the 72-hour clock at “controller awareness,” then document how you determined that moment (Regulation (EU) 2016/679, Article 33).
• You need a repeatable triage process that ends in either a regulator notification or a documented “unlikely risk” rationale (Regulation (EU) 2016/679, Article 33).
• Late notifications must include reasons for delay, so build delay-reason capture into your incident workflow (Regulation (EU) 2016/679, Article 33).
• Processors don’t notify the authority under Article 33, but they must feed controllers fast enough for the controller to meet the deadline (Regulation (EU) 2016/679).

Article 33 is a timing-and-content requirement disguised as an incident response task. The compliance risk comes from two failure modes: (1) you notify late because “awareness” was never defined operationally, or escalation was unclear; (2) you decide not to notify but cannot defend the “unlikely to result in a risk” conclusion after the fact. Regulators tend to ask for your timeline, your decision criteria, and evidence that you executed a consistent process, not a one-off scramble.

To run Article 33 well, treat it as a controlled workflow that starts at intake, moves through technical confirmation and scope, then reaches a documented legal/compliance decision with named owners. That workflow must work even when facts are incomplete, because the regulation allows phased disclosure: if you cannot provide all information at once, you provide it in phases, but you still need to notify within the deadline when feasible (Regulation (EU) 2016/679, Article 33).

This page gives requirement-level implementation guidance you can hand to incident response, security, legal, privacy, and business owners. The goal is speed with defensibility: a clear “breach clock,” a structured risk screen, a notification packet, and an evidence trail you can produce under pressure.

Regulatory text

Operative requirement (excerpt): “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… unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons. Where the notification… is not made within 72 hours, it shall be accompanied by reasons for the delay…” (Regulation (EU) 2016/679, Article 33).

What the operator must do

1. Identify when you became “aware” of a personal data breach and start a tracked countdown from that point (Regulation (EU) 2016/679, Article 33).
2. Decide whether notification is required by assessing whether the breach is unlikely to result in risk to individuals’ rights and freedoms; notify unless you can support the “unlikely risk” conclusion (Regulation (EU) 2016/679, Article 33).
3. Notify the competent supervisory authority for your main establishment / relevant jurisdiction (competence referenced in Article 55) with the required content, and send follow-ups when information becomes available (Regulation (EU) 2016/679, Article 33).
4. If late, include reasons for delay as part of the notification package (Regulation (EU) 2016/679, Article 33).

Plain-English interpretation (what Article 33 is really testing)

• Speed: Can your organization move from “we saw something” to “we can make and document a regulator-notification decision” fast enough to meet the statutory deadline (Regulation (EU) 2016/679, Article 33)?
• Role clarity: Controllers carry the duty to notify. Processors must quickly inform controllers so the controller can decide and notify (Regulation (EU) 2016/679).
• Defensibility: If you don’t notify, you need a written rationale that maps to the “unlikely to result in a risk” threshold, backed by the facts known at the time (Regulation (EU) 2016/679, Article 33).

Who it applies to (entity and operational context)

In scope

• Controllers processing personal data under GDPR. Article 33’s notification obligation is explicitly on the controller (Regulation (EU) 2016/679, Article 33).
• Any operational area that can cause or detect a personal data breach: security operations, IT operations, product engineering, fraud, customer support, HR, physical security, and third parties handling your data.

How processors fit in

• Processors are typically the first to detect certain incidents (cloud/SaaS compromise, managed service mistakes). Even though Article 33’s notification duty is on the controller, your processor contracts and incident workflow must force rapid escalation so you can meet the timing requirement (Regulation (EU) 2016/679).

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

1) Establish “controller awareness” and start the breach clock

Define a practical trigger so teams don’t argue later. Use an internal definition such as:

• Awareness occurs when the incident response lead (or on-call security manager) confirms there is a personal data breach, not just a security event.
• Document the moment of awareness in the ticket: timestamp, who confirmed, what evidence supported the conclusion.

Operational control: Create an incident severity type “Suspected personal data breach” that requires privacy/legal notification immediately and forces capture of the awareness timestamp.

2) Run a structured breach triage within your incident process

Build a short, repeatable decision matrix that produces one of three outcomes:

• Notify within the deadline (default when risk is plausible) (Regulation (EU) 2016/679, Article 33).
• Do not notify because it is unlikely to result in risk; record rationale and supporting facts (Regulation (EU) 2016/679, Article 33).
• Insufficient facts; proceed with draft notification and plan phased updates, rather than waiting for perfect clarity (Regulation (EU) 2016/679, Article 33).

Minimum triage inputs to collect in the first working session:

• What happened (type of incident, attack vector if known).
• Systems affected and whether personal data is stored/transmitted there.
• Data categories (customer, employee, prospective, sensitive categories if applicable).
• Approximate scope (records, users, or accounts impacted) if available.
• Likely consequences to individuals (financial fraud risk, identity exposure, safety risks).
• Containment actions taken and current exposure status.

3) Make the notification decision and document it like an audit artifact

Create a one-page decision record with:

• Decision: notify vs. no-notify.
• Time of awareness and key timeline events.
• Risk assessment summary tied to “risk to rights and freedoms” standard (Regulation (EU) 2016/679, Article 33).
• Approvers: incident commander, privacy lead/DPO (if appointed), legal, security.
• If late: explicit delay reasons (Regulation (EU) 2016/679, Article 33).

This record matters as much as the notification itself. It is what you will produce under regulator scrutiny.

4) Prepare and submit the supervisory authority notification

Maintain a pre-built “authority notification packet” template aligned to Article 33 expectations. Article 33 specifies that notification occurs to the competent supervisory authority and that late notifications must include reasons for delay (Regulation (EU) 2016/679, Article 33). Your template should support:

• Incident description and status (ongoing/contained).
• Categories of data subjects and personal data involved.
• Likely consequences.
• Measures taken or proposed to address the breach.
• Contact point (privacy office/DPO).

5) Plan for phased updates and internal coordination

Facts change quickly. Treat your initial submission as “version 1” and schedule update checkpoints with security and engineering. Keep a simple log of:

• What you learned.
• When you learned it.
• Whether it changes risk, scope, or notifications.

6) Align third-party escalation to the same clock

Add third-party requirements that feed your workflow:

• Mandatory incident notification to you upon discovery of a suspected personal data breach affecting your data.
• Required data points for their initial report (systems, data types, containment).
• Named 24/7 escalation contacts. This is where many Article 33 programs fail: the controller can’t meet the deadline because the third party “investigated internally” first.

Daydream fit (earned mention): Daydream is useful here as a system of record for third-party incident intake, linking the third party’s report to your internal incident ticket, decision record, and the evidence packet you need for Article 33 defensibility.

Required evidence and artifacts to retain

Keep an “Article 33 evidence packet” per incident:

• Incident ticket with timeline, including the “awareness” timestamp.
• Data mapping pointers: which systems/processes store the impacted personal data.
• Risk assessment and decision record (notify vs. no-notify).
• Copy of authority submission(s) and confirmation/receipt, if available.
• Delay reasons (if notification exceeded the statutory deadline) (Regulation (EU) 2016/679, Article 33).
• Communications log: internal stakeholders and third parties contacted.
• Post-incident review notes and remediation tasks.

Also maintain standing artifacts:

• Role-and-scope register: where you are controller vs. processor, and which processing activities and systems are in scope for breach notification.
• Requirement-specific operating procedure: owners, triggers, approvals, escalation paths.
• Training records for incident commanders, security on-call, and privacy/legal.

Common exam/audit questions and hangups

Expect these questions from auditors, regulators, or customers:

• “Define ‘becoming aware.’ Who decides, and where is it documented?” (Regulation (EU) 2016/679, Article 33).
• “Show the timeline from detection to awareness to notification. Where did time get lost?”
• “For incidents you did not notify, show the ‘unlikely risk’ rationale and evidence.”
• “How do third parties notify you, and how do you ensure their timing supports yours?”
• “Where is the supervisory authority competency determined and maintained?” (Regulation (EU) 2016/679, Article 33).

Frequent implementation mistakes (and how to avoid them)

1. No operational definition of awareness.
   Fix: define the trigger and force timestamp capture in your incident tooling.

2. Treating notification as a legal-only task.
   Fix: make it a joint workflow with security as the fact owner, privacy/legal as the decision owner, and comms as a consulted function.

3. Waiting for complete scoping before notifying.
   Fix: prepare a “minimum viable notification” process and send follow-ups as facts mature (Regulation (EU) 2016/679, Article 33).

4. Poor “no-notify” documentation.
   Fix: standardize a short written rationale format. If you can’t explain it in a page, your decision likely isn’t tight.

5. Third-party escalation gaps.
   Fix: contract clauses, tested escalation paths, and exercises where the third party triggers your breach clock.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this page, so this guidance stays anchored to the statutory requirement and practical supervisory expectations described in Article 33 (Regulation (EU) 2016/679, Article 33). Your risk is still concrete: failure to notify within the deadline, failure to justify delay, or inability to defend a no-notify decision can convert a contained incident into a regulatory event.

Practical 30/60/90-day execution plan

First 30 days (stabilize the workflow)

• Assign named owners: incident commander role, privacy lead/DPO, legal approver, security fact owner.
• Publish a one-page SOP: triggers, awareness definition, escalation contacts, approval chain.
• Build templates: decision record, authority notification packet, delay-reasons field.
• Update incident intake forms to capture: suspected personal data involvement, data categories, and awareness timestamp.

Days 31–60 (make it repeatable)

• Tabletop exercise: run one scenario from detection to authority notification draft.
• Update third-party contract addendum language and onboarding checklist for incident escalation.
• Create an evidence packet checklist and store it in a central, access-controlled repository.
• Implement a simple dashboard view: open “suspected personal data breach” incidents and their breach-clock status.

Days 61–90 (prove it works under stress)

• Run a second exercise with a third party (SaaS or managed service) as the incident origin.
• Perform a retrospective on prior incidents: would any have required notification under your new decision matrix?
• Audit your ability to produce the evidence packet on demand.
• Operationalize improvements in Daydream (or your GRC system) to link incident, third-party involvement, approvals, and retained artifacts.

Frequently Asked Questions

When does the 72-hour clock start for Article 33?

It starts when the controller becomes aware of a personal data breach, not necessarily when the first alert fired (Regulation (EU) 2016/679, Article 33). Define “awareness” internally and record a timestamp in the incident record.

Do we always have to notify the supervisory authority?

No. You do not notify if the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons, but you need a documented, defensible rationale (Regulation (EU) 2016/679, Article 33).

What if we miss the deadline?

You can still notify, but the notification must include reasons for the delay (Regulation (EU) 2016/679, Article 33). Build delay-reason capture into your workflow so it is not reconstructed later.

Can we notify with incomplete information?

Article 33 anticipates that information may evolve; operationally, send an initial notification when feasible and follow up with additional details as they become available (Regulation (EU) 2016/679, Article 33). Your process should support versioned updates.

How do third parties affect our Article 33 compliance?

Third parties often detect issues first, so your contracts and escalation paths must require fast incident reporting to you with the minimum data you need to decide on notification (Regulation (EU) 2016/679). Test this path in tabletop exercises.

What evidence should we keep if we decide not to notify?

Keep a decision record tied to the known facts at the time: incident summary, data involved, containment status, and why the breach was unlikely to result in risk (Regulation (EU) 2016/679, Article 33). Auditors will focus on contemporaneous documentation, not after-the-fact narratives.