The rule in one view
Article 33 of the GDPR concerns notification of a personal-data breach to the competent supervisory authority.
For a controller, the core rule is:
- notify without undue delay and, where feasible, no later than 72 hours after becoming aware of the breach;
- notification is not required under Article 33(1) when the breach is unlikely to result in a risk to the rights and freedoms of natural persons;
- if notification occurs after 72 hours, include reasons for the delay; and
- document the breach, its effects, and remedial action whether or not it is notified, so the supervisory authority can verify compliance.
A processor has a different immediate duty under Article 33(2): notify the controller without undue delay after becoming aware of a personal-data breach.
This is a workflow with at least three distinct activities: establish awareness, assess risk, and prepare the notification record. Treating it as one “Report breach” text box loses the structure that the rule relies on.
When the clock starts
The statutory anchor is when the controller becomes aware of the personal-data breach—not necessarily when suspicious activity first occurred, when a security alert fired, or when the incident was fully investigated.
The European Data Protection Board’s breach-notification guidelines discuss awareness and the assessment organisations should make after first learning of a possible incident. The facts can be nuanced, so a workflow should preserve more than one timestamp:
- when the event may have begun;
- when it was detected;
- when it was escalated as a possible personal-data breach;
- when the controller considered itself aware; and
- why that awareness time was selected.
Do not make the 72-hour calculation depend on a timestamp that can be silently overwritten. Preserve the original value, its author, and any later correction.
An automated timer can calculate elapsed time from the recorded awareness timestamp. It cannot decide whether that timestamp is legally correct without the surrounding facts.
What the notification needs
Article 33(3) states that the notification must at least:
- describe the nature of the breach, including, where possible, the categories and approximate number of data subjects and personal-data records concerned;
- provide the name and contact details of the data protection officer or another contact point;
- describe the likely consequences; and
- describe measures taken or proposed to address the breach, including measures to mitigate possible adverse effects where appropriate.
Those elements suggest separate fields. “Approximate” is important: the law anticipates that exact counts may not be available immediately. A workflow should allow an estimate to be identified as an estimate and later refined.
The notification record should also identify the competent authority, submission channel, submission time, reference number, and evidence of receipt. Those operational fields are not a substitute for Article 33’s required content; they show what happened to the notification after it was prepared.
Phased reporting and documentation
Article 33(4) permits information to be provided in phases without undue further delay when it cannot be supplied at the same time. A strong workflow therefore supports:
- an initial notification with known information;
- clearly marked unknown or provisional values;
- follow-up submissions linked to the initial report;
- a history of what changed and when; and
- a current consolidated view without erasing earlier submissions.
Phased reporting is not permission to leave known mandatory information out for convenience. The workflow should ask why information is unavailable and assign follow-up ownership.
Article 33(5) separately requires documentation of personal-data breaches. That internal record should include the facts, effects, and remedial action. It must be sufficient for the authority to verify compliance. This documentation obligation is one reason a workflow should not delete the assessment merely because the conclusion was “unlikely risk; no notification.”
Article 33 is not Article 34
Article 34 addresses communication to affected data subjects when the breach is likely to result in a high risk to their rights and freedoms. It has its own content and exceptions.
The two decisions are related but not identical:
| Question | Article 33 | Article 34 |
|---|---|---|
| Recipient | Supervisory authority | Affected data subjects |
| Main threshold | Risk, unless unlikely | Likely high risk |
| Timing | Without undue delay; where feasible within 72 hours | Without undue delay |
| Record | Authority notification and breach documentation | Communication content, delivery, and any exception relied on |
A workflow can present both assessments in sequence. It should retain them as distinct decisions with distinct rationales.
Fields for an operational workflow
A practical Article 33 intake commonly needs the following groups.
Identity and ownership
- controller and relevant establishment;
- incident owner;
- DPO or other contact point;
- processor involvement and processor-notification time.
Timeline
- detection time;
- escalation time;
- awareness time and rationale;
- authority-notification time;
- delay reason where applicable.
Breach facts
- confidentiality, integrity, and availability effects;
- systems and processing activities affected;
- categories and approximate counts of people and records;
- special-category or otherwise sensitive data involved;
- geographic scope.
Assessment
- likelihood and severity of consequences;
- risk conclusion and rationale;
- Article 33 notification decision;
- Article 34 high-risk decision;
- reviewer and approval time where the organisation requires review.
Response and evidence
- containment and remediation;
- mitigation for affected people;
- authority, channel, submission reference, and receipt;
- follow-up items and phased updates.
Not every field needs to block the first submission. The schema should distinguish what is mandatory now, what can be provisional, and what requires follow-up.
Common design failures
Starting the clock at the wrong event
“Incident created at” is not necessarily “controller became aware at.” Preserve both rather than using one generic date.
Treating no notification as no record
Article 33(5) makes documentation important even when the risk assessment concludes that authority notification is not required.
Hiding the rationale
A risk dropdown without reasons makes review difficult. Require a concise rationale and the facts supporting it.
Blocking until everything is known
Article 33 permits phased provision of information. A form that cannot represent unknown estimates may delay the very notification it is supposed to support.
Merging authority and data-subject communication
Keep Article 33 and Article 34 decisions distinct. A single “people notified” checkbox cannot explain either process.
The goal is a record that helps the incident team move quickly while preserving the timing, assessment, content, and follow-up needed to explain the response later.