GDPR Article 33 is the rule for reporting a personal data breach to a supervisory authority. The official Regulation (EU) 2016/679 on EUR-Lex sets a risk threshold, an urgency requirement and a 72-hour reference point. It does not make every security incident reportable. A controller must notify the competent authority without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach, unless the breach is unlikely to result in a risk to people’s rights and freedoms. A notification made later must give reasons for the delay.
A useful response therefore starts with three separate questions. Did an event compromise personal data? When did the controller have reasonable certainty of that fact? Is risk to people sufficiently unlikely to justify not notifying? The answers should be recorded as facts become available, even if an early assessment later changes. The EDPB’s final Guidelines 9/2022 explain awareness, risk and the relationship between controller and processor notification. This guide translates those rules into a decision and evidence trail; the regulation and guidance remain the primary authorities.
First distinguish an incident from a personal data breach
An outage, lost laptop or malicious login is a security incident. Article 4(12) calls it a personal data breach when a security breach leads to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data that has been transmitted, stored or otherwise processed. Confidentiality is only one route. A corrupted customer database can be an integrity breach; an unavailable health record may be an availability breach. One event may affect all three.
Confirm that the affected material is personal data and that the event had one of those effects. A failed phishing attempt with no access to data is not automatically an Article 33 breach. A misaddressed email containing identifiable customer information may be one even if nobody exploited it. A stolen encrypted device still deserves assessment: encryption and key separation may greatly reduce risk, but the controller must establish what was on the device, whether the key was exposed and whether usable copies remain available. The breach response guide covers immediate containment, while the 72-hour walkthrough helps assign the first response actions. Containment does not by itself settle the reporting decision.
Establish the awareness time without waiting for perfect facts
The EDPB describes awareness as a reasonable degree of certainty that a security incident has occurred and has led to personal data being compromised. An unverified alert can justify a short, prompt investigation. It cannot justify leaving a credible alert unexamined while the reporting clock is convenient to avoid. Record the first alert, the investigation steps and the point at which the evidence supported reasonable certainty. A controller that discovers exposed records on Friday does not gain a new statutory clock on Monday because its privacy team works office hours.
Imagine a hosting alert at 09:00 on Friday. At first it shows unusual traffic but no affected dataset. By 14:00 the team confirms that an intruder exported a customer table. The latter finding may establish awareness even though the exact number of customers and the intruder’s identity remain unknown. The team should preserve the alert and investigation timestamps. Conversely, if an alert was plainly a false positive, document the reason; do not treat every alert as a confirmed breach. Reasonable certainty is a factual threshold, not an invitation to complete a forensic report before taking a position.
Article 33 says without undue delay and, where feasible, not later than 72 hours. That wording makes 72 hours an outer reference point for a notifiable breach, not a routine waiting period. If a controller can submit an accurate initial notification earlier, it should. The hours include weekends and holidays. A later notification still has to be made where required, with reasons for the delay. A sensible internal incident plan sets earlier escalation targets so that people can investigate and decide within the legal window; those targets are chosen operating rules, not deadlines imposed by Article 33.
Apply the risk threshold to the actual breach
Article 33(1) removes the authority-notification requirement where the breach is unlikely to result in a risk to rights and freedoms. That is a reasoned conclusion about the circumstances, not an exemption based solely on record count or a supplier’s assurance. Consider the kind of information, the ability to identify people, possible misuse, number and vulnerability of affected people, who obtained access, duration of exposure, existing protections and the effectiveness of containment. The EDPB guidance supplies examples; a controller should explain which details make its own case comparable or different.
For example, a brief internal disclosure to a trusted colleague who promptly confirms deletion may have a different risk profile from the same file posted on a public website and indexed by a search engine. A lost encrypted device with uncompromised keys and restorable backups may present little confidentiality or availability risk; a stolen unencrypted database containing identity documents may present substantial risk. Special-category data heightens the analysis, but its presence is not a statutory rule that every incident must be notified. Similarly, ordinary contact data can create material risk when combined with credentials or when a recipient can use it for convincing fraud.
Write down both plausible harms and the facts that reduce them. If a low-risk conclusion depends on a recipient deleting a misdirected message, keep evidence of that confirmation. If the facts are not yet sufficient to conclude that risk is unlikely, investigate urgently and consider an initial notification. Do not turn uncertainty into a silent assumption of safety. Reassess when the scope, recipients or effectiveness of protective measures changes. The related Article 34 analysis addresses the separate, higher threshold for communicating with affected people.
Identify the competent authority before filing
Article 33 refers to the supervisory authority competent under Article 55. The authority and channel depend on the controller’s establishment and the processing involved. Cross-border processing may engage the GDPR’s lead-authority and cooperation rules; the EDPB guidance also addresses cases involving controllers outside the EU. Do not send a notice to an authority chosen only because its web form is familiar. Check the applicable authority’s current instructions and whether additional national reporting duties apply to the event. A security incident can also engage sectoral rules without changing Article 33’s own threshold.
An incident owner should keep the authority contact, portal access and backup filing route in the response plan. During a serious breach, a broken login or missing authorised signatory can consume the remaining time. Record the submission identifier, timestamp, copy of the filed information and any follow-up request. If several entities are involved, identify which is controller for each affected processing activity instead of assuming a group-wide filing covers every legal entity.
Submit the four categories of information Article 33 requires
Article 33(3) states the minimum content. Describe the nature of the breach, including where possible the categories and approximate numbers of affected people and personal data records. Give the name and contact details of the data protection officer or another contact point. Describe likely consequences. Describe measures taken or proposed to address the breach, including mitigation of possible adverse effects where appropriate. These are substantive fields: a bare notice saying “incident under investigation” may be insufficient even when sent within 72 hours.
Use estimates honestly. If the affected population could be between 2,000 and 3,000 because one log source is incomplete, identify the estimate and its basis. Distinguish confirmed access from possible access. Explain what systems were isolated, whether credentials were revoked, whether exposed files were removed and what protective action remains. A notification can say a fact is not yet known; it should also say what is being done to find it. Avoid speculation presented as a conclusion. Coordinate legal, security and customer teams so that statements to the authority and affected people describe the same known facts.
A practical initial record has an incident identifier, controller, processing purpose, data categories, first alert, awareness time, risk assessment, authority decision, contact person, present consequences, containment and next update owner. That record is an internal aid, not a substitute for the authority’s filing form. If the authority’s current form asks more information, answer it or explain what cannot yet be supplied. The authority-notification guide provides a complementary filing view, and the general breach-notification guide places the authority decision within the wider response.
Use phased notification when information is genuinely unavailable
Article 33(4) permits information to be supplied in phases, without undue further delay, where it is not possible to provide everything at the same time. This solves a common problem: a controller may know that a notifiable export happened while forensic work is still establishing which accounts were copied. File what is available, mark estimates and unknowns clearly, and update the authority as material facts emerge. The Regulation does not prescribe universal follow-up dates such as seven, fourteen or thirty days. Set case-specific update commitments that match the investigation and the authority’s instructions.
A later update may correct an initial estimate, describe confirmed misuse, explain why a different data category is affected or report a completed mitigation. Preserve earlier versions rather than silently replacing them. If new facts change the Article 34 high-risk assessment, the controller must assess communication to people without undue delay; it should not wait for a final forensic report simply because the authority notification was phased. Record who owns each outstanding question so that “we will investigate” becomes an action with an accountable result.
If notification occurs after 72 hours, state concrete reasons for the delay: when awareness arose, what impeded filing, what work was done, and when the impediment ended. A generic claim that the investigation was complex does not explain every hour of delay. The authority can evaluate the explanation against the actual record. A delayed filing is still more useful than never filing a reportable breach.
Manage the processor-to-controller handoff
Under Article 33(2), a processor must notify its controller without undue delay after becoming aware of a personal data breach. The Regulation supplies no universal 24-hour or 48-hour processor deadline. A controller and processor may agree a shorter operational target and minimum information in their Article 28 agreement, provided the arrangement supports prompt statutory notification. The processor should not wait to finish the controller’s risk assessment before raising the alarm; the controller needs the facts to make that assessment.
A useful notice identifies affected services and tenants, the event and discovery times, data categories known, containment already performed, outstanding investigation and an emergency contact. If the processor supplies only a generic security bulletin, ask whether personal data processed for this controller was affected. Multi-supplier incidents require each participant to pass information through the chain. The controller retains responsibility for its Article 33 decision. A processor may make a filing on the controller’s behalf when authorised, but delegation does not transfer that responsibility. The processor-role explainer helps resolve whose instructions and data are involved.
Document every personal data breach, including a decision not to notify
Article 33(5) requires the controller to document personal data breaches, comprising their facts, effects and remedial action, so that the authority can verify compliance. A log should therefore capture the risk reasoning and its evidence, including why notification was or was not required. Record later changes to that conclusion. There is no universal five-year retention period in Article 33(5); apply a defensible retention rule in light of accountability, applicable law and the organisation’s records policy.
A log entry is more than a checkbox. For a mistaken email, retain the time sent, recipient, information disclosed, recall or deletion evidence, foreseeable harms and decision owner. For an outage, record which personal data became unavailable, how long, whether a usable backup existed and whether anyone suffered consequences. Restrict access to the incident record because it may contain sensitive technical details and additional personal data. Test the incident procedure after events and use findings to improve the Article 32 security measures, rather than treating the filing itself as remediation.
Keep authority notification and individual communication separate
The Article 33 authority threshold is risk unless risk is unlikely. Article 34 calls for communication to affected people where the breach is likely to result in a high risk, subject to its specific exceptions. Neither rule says that every security event must be public. A single event can require an authority notice but no individual notice, both notices, or neither after a supported assessment. The decision should be revisited if evidence changes. Communication to people should explain what happened, likely consequences and protective steps in clear language, with a real contact route; see the Article 34 guide.
Article 83(4)(a) places infringements of Article 33 in the GDPR’s lower administrative-fine tier, with the statutory maximum calculated according to the applicable undertaking rule. That ceiling is not an automatic penalty for a late form, and a breach is not proof that security was inadequate. An authority evaluates the particular infringement under Article 83’s factors. For that reason, avoid using unrelated headline penalties as a “benchmark” for this reporting decision. The safest operational evidence is a prompt, candid and well-documented assessment tied to the actual facts.
A decision sequence to use during an incident
Start by securing people and systems: isolate the exposure, preserve logs, and route the alert to the controller’s incident owner. Determine whether personal data suffered confidentiality, integrity or availability loss. Record the earliest time the controller reached reasonable certainty. Identify the affected processing activities, people, records and other controllers or processors. Assess risk to rights and freedoms with the evidence presently available, then decide whether an authority notice is required. If it is, identify the competent authority and file without undue delay, within 72 hours where feasible. Supply the four Article 33(3) categories as far as possible, give reasons for lateness if applicable, and update missing information without undue further delay. Separately assess Article 34 and any sector-specific obligations. Keep the incident record and review controls after containment.
This sequence deliberately leaves room for judgment. A ten-record disclosure can be severe; a large encrypted archive may pose little risk if its keys remain secure. The record should show how the team reached its conclusion, not merely that it met an internal timer. Read the official Article 33 text alongside the EDPB breach guidelines when a difficult case depends on awareness or risk. This article is a working explanation of those sources, not an authority filing or case-specific legal decision.