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

Notification of a Personal Data Breach to the Supervisory Authority

1. The basic architecture of Article 33

Article 33 is one of the GDPR's central breach-response provisions. It establishes a regulatory reporting mechanism that becomes relevant after a personal data breach has occurred and the controller has assessed that the breach is likely to result in a risk to the rights and freedoms of natural persons.

The provision should not be understood simply as a rule saying:

“A breach occurs → notify the regulator within 72 hours.”

That formulation is incomplete and can lead to serious compliance mistakes.

The actual legal sequence is more sophisticated:

Security incident → investigation → determination whether a personal data breach occurred → awareness → risk assessment → decision whether Article 33 notification is required → notification without undue delay / where feasible within 72 hours → continuing investigation → supplementary information → documentation.

The provision therefore combines several distinct legal questions:

1. Has there been a security incident?

2. Does the incident amount to a “personal data breach”?

3. When did the controller become sufficiently aware of that breach?

4. Is the breach likely to result in a risk to individuals' rights and freedoms?

5. Which supervisory authority is competent?

6. What information must be supplied?

7. Can all information be supplied within the initial period?

8. If not, how should phased notification operate?

9. What must the controller document?

10. Can the controller defend a decision not to notify?

11. What are the consequences of failing to notify?

These questions must be kept analytically separate.

Article 33 is consequently both a notification provision and anaccountability mechanism.

It does not merely tell organisations when to contact regulators. It forces organisations to develop the internal capability necessary to detect, investigate, assess, contain, report and document personal data breaches.

This is why Article 33 should be read together with Articles 5(2), 24, 28, 32, 34 and 83 GDPR.

2. Article 33 operates within the broader breach-management framework

Article 33 does not exist in isolation.

Article 32 requires appropriate technical and organisational measures for security. Those measures should not merely prevent breaches; they should also enable organisations to detect, investigate and respond to them.

Article 33 then addresses regulatory notification.

Article 34 addresses communication to affected data subjects where the breach is likely to result in a high risk to their rights and freedoms.

Article 28 is particularly important where a processor is involved because processors have an obligation to notify controllers of breaches.

Article 5(2) introduces accountability, requiring controllers to be able to demonstrate compliance.

Article 83 establishes the potential administrative-fine consequences of non-compliance.

The practical relationship can therefore be visualised as:

Article 32 → prevention and detection

Article 33(2) → processor alerts controller

Article 33(1) → controller assesses breach and regulatory notification

Article 34 → controller separately assesses whether affected individuals must be informed

Article 33(5) → controller documents the entire incident and decision-making process

This distinction is extremely important.

A controller may have:

• a personal data breach requiring Article 33 notification but not Article 34 communication;

• a personal data breach requiring both Article 33 and Article 34;

• a personal data breach requiring neither notification nor communication because the relevant risk thresholds are not met;

• or a security incident that is not a personal data breach at all.

These are not interchangeable concepts.

3. First question: what exactly is a “personal data breach”?

Article 33 is triggered only by a personal data breach, not by every cybersecurity incident.

A personal data breach is essentially a security breach resulting in accidental or unlawful:

• destruction;

• loss;

• alteration;

• unauthorised disclosure; or

• unauthorised access

to personal data.

This produces the familiar three-part classification:

A. Confidentiality breach

This occurs where personal data is accessed or disclosed by someone who should not have access.

Examples

include:

• an employee sending a customer database to the wrong recipient;
• a hacker accessing an HR database;
• a cloud storage bucket becoming publicly accessible;
• a doctor emailing patient information to another patient;
• credentials being compromised;
• an employee accidentally publishing a confidential spreadsheet.

B. Integrity breach

Here the personal data is altered or corrupted.

Examples

include:

• an attacker modifying bank-account details;
• an employee accidentally overwriting customer records;
• ransomware encrypting records and altering their accessibility;
• manipulation of medical records;
• fraudulent alteration of payroll information.

C. Availability breach

Here personal data becomes unavailable or is destroyed.

Examples

include:

• ransomware making customer databases inaccessible;
• accidental deletion of a database;
• destruction of physical records;
• a cloud service failure resulting in loss of access;
• destruction of the only copy of important personal records. One incident can involve more than one category.

Example

ransomware might simultaneously create:

• an availability breach because the organisation cannot access its data;

• a confidentiality breach if the attacker exfiltrated the information; and

• potentially an integrity breach if records were modified.

The notification should therefore not mechanically label an incident “cyberattack”. The controller should explain what happened to the personal data.

4. Not every security incident is a personal data breach

This is one of the most important distinctions under Article 33.

Suppose an organisation experiences a denial-of-service attack against a public-facing website.

If the attack merely makes the website unavailable and no personal data is affected, there may be a cybersecurity incident but not a personal data breach.

Similarly, an attempted phishing attack that is detected and blocked before any personal data is compromised may be a security incident but not necessarily a personal data breach.

However, the organisation should be careful not to conclude too quickly that there was no breach.

A failed attack may become a personal data breach if investigation establishes that:

• credentials were actually compromised;

• an attacker accessed a database;

• personal information was downloaded;

• records were altered;

• or data became unavailable.

The key question is not:

“Was there a cyberattack?”

The key question is:

“Did the security incident lead to destruction, loss, alteration, unauthorised disclosure or unauthorised access to personal data?”

5. The significance of “awareness”

The 72-hour period does not begin merely when the organisation first hears a rumour about a possible cybersecurity problem.

The critical concept is when the controller becomes aware of the personal data breach.

The EDPB's approach is particularly important here. Awareness generally exists when the controller has a reasonable degree of certainty that a security incident has occurred which has resulted in personal data being compromised.

This creates an important distinction between:

suspicion andawareness.

Imagine an employee reports at 9:00 a.m.:

“I think someone may have accessed the customer database.”

At this point, the controller may not yet know that a personal data breach occurred.

It should nevertheless immediately investigate.

At 11:00 a.m. forensic evidence establishes that an unauthorised account accessed the database containing customer information.

The controller may now have reached the necessary level of awareness.

The 72-hour clock would ordinarily be calculated from that point.

This prevents an absurd outcome in which every vague suspicion automatically starts the statutory notification clock.

But there is an equally important counter-principle:

The awareness concept cannot be manipulated by deliberately delaying investigation.

An organisation cannot simply say:

“We did not know there was a breach because our investigation was incomplete.”

If the organisation had sufficient information to establish with reasonable certainty that personal data had been compromised, it cannot artificially postpone the beginning of the notification period by refusing to make a determination.

This is why Article 32 and Article 33 interact.

An organisation should have appropriate detection and incident-response processes precisely so that it can determine rapidly whether a breach occurred.

6. The “reasonable certainty” threshold is not absolute certainty

Controllers do not have to wait until every forensic question has been resolved.

Suppose:

• an attacker definitely accessed the database;

• the controller knows that approximately 200,000 customer accounts were potentially exposed;

• but forensic investigators do not yet know whether the attacker actually downloaded every record.

Waiting several weeks for complete forensic certainty would defeat the purpose of Article 33.

The controller can notify the supervisory authority based on what is reasonably known and update the authority later.

This is precisely why Article 33(4) permits phased notification.

The practical principle is therefore:

Reasonable certainty that a personal data breach occurred is sufficient to trigger the assessment process; complete knowledge of every detail is not required before notification.

7. Processor awareness and controller awareness are distinct

This is a particularly important issue in outsourced processing.

Suppose Company A is the controller and Cloud Provider B is its processor.

At 2:00 a.m. B discovers that attackers accessed a server containing A's customer data.

B becomes aware of the breach.

A has not yet been informed.

Under the GDPR framework, the processor must notify the controller without undue delay.

The processor's knowledge does not simply become the controller's knowledge automatically for Article 33 purposes.

The controller generally becomes aware when:

• it is informed by the processor; or

• it independently discovers the breach.

This distinction matters because the Article 33 notification deadline applies to the controller.

But it does not mean processors can take their time.

Quite the opposite.

A processor's delay can seriously prejudice the controller's ability to meet its own 72-hour obligation.

That is why Article 28 agreements normally contain much more precise contractual requirements, such as:

• immediate notification;

• notification within a specified number of hours;

• emergency telephone contact;

• provision of preliminary information;

• continuing updates;

• forensic cooperation;

• preservation of evidence;

• assistance with regulatory notifications;

• assistance with data-subject communications.

The contractual deadline may therefore be substantially shorter than 72 hours.

Example

a controller may require:

“Processor shall notify Controller within 12 hours of becoming aware of a personal data breach.”

This does not replace Article 33. It operationalises it.

8. The processor does not normally notify the supervisory authority under Article 33

A major exam and practical distinction is:

Controller → Supervisory authority

Processor → Controller

The processor's statutory obligation under Article 33(2) is to inform the controller.

The controller remains responsible for regulatory notification.

This allocation makes sense because the controller determines the purposes and means of processing and generally possesses the broader contextual information necessary to assess risk to individuals.

The processor may know:

• what server was compromised;

• what technical vulnerability was exploited;

• when the attack occurred;

• what systems were accessed;

• what logs reveal.

But the controller may know:

• who the affected individuals are;

• whether they are children;

• why the data was processed;

• whether the data is particularly sensitive;

• whether individuals are vulnerable;

• what consequences are likely;

• whether similar information is publicly available.

The controller therefore performs the final Article 33 assessment.

9. “Without undue delay” is stronger than “within 72 hours”

This is perhaps one of the most misunderstood aspects of Article 33.

The 72-hour period is not a grace period.

It is not correct to think:

“I have 72 hours, so I can wait until hour 71.”

The primary obligation is notification without undue delay.

The 72-hour period is the outer benchmark where notification within that period is feasible.

Suppose a serious breach is discovered at 9:00 a.m. and the controller already possesses sufficient information to notify the supervisory authority at 1:00 p.m.

There is little justification for deliberately waiting until the third day.

The more serious and obvious the breach, the stronger the expectation of rapid action.

“Without undue delay” therefore introduces a qualitative requirement.

The controller must act as soon as reasonably practicable.

10. Is 72 hours an absolute deadline?

Not exactly.

Article 33 says “where feasible” and recognises that notification may occur after 72 hours in appropriate circumstances.

But this should not be misunderstood as giving controllers a general extension.

A controller cannot simply say:

“Our investigation took longer.”

The controller must be able to explain why notification within 72 hours was not feasible.

The provision therefore creates two simultaneous requirements:

Requirement 1

Act without undue delay.

Requirement 2

Where feasible, notify no later than 72 hours after awareness.

If more than 72 hours elapse, the controller must provide reasons for the delay.

The longer the delay, particularly in a serious breach, the more carefully the organisation should document why the delay was necessary.

11. The 72-hour clock and practical incident-response management

The 72-hour rule has major operational consequences.

An organisation should not begin designing its response procedure after the breach occurs.

It should already have:

• an incident-response team;

• escalation procedures;

• internal reporting channels;

• breach classification criteria;

• legal escalation procedures;

• DPO involvement where appropriate;

• technical investigation procedures;

• notification templates;

• supervisory-authority contact information;

• processor escalation requirements;

• evidence-preservation procedures;

• decision-making authority;

• communication protocols.

A breach at 2:00 a.m. on a public holiday is still a breach.

The organisation cannot reasonably structure its entire response around:

“The privacy lawyer returns to work Monday.”

Business continuity and incident-response planning are therefore part of Article 33 compliance.

12. The risk threshold: “unlikely to result in a risk”

Article 33 does not require notification of every personal data breach.

Notification to the supervisory authority is generally unnecessary where the breach is unlikely to result in a risk to the rights and freedoms of natural persons.

This is a lower threshold than the Article 34 threshold for communicating a breach to data subjects.

That distinction is fundamental:

Article 33

Risk

Article 34

High risk

Therefore:

No likely risk → generally no Article 33 notification

Risk → Article 33 notification

High risk → Article 33 notification + potentially Article 34 communication

This creates a three-level conceptual framework:

This is one of the most important distinctions in GDPR breach analysis.

13. Risk is not synonymous with damage already occurring

Article 33 is concerned with whether the breach is likely to result in risk.

The controller therefore does not need to wait until:

• fraud occurs;

• identity theft occurs;

• someone suffers financial loss;

• confidential information is actually exploited;

• an individual suffers discrimination.

The possibility and likelihood of adverse consequences matter.

Example

if a database containing identity documents is stolen, the controller cannot reasonably wait until an affected individual becomes a victim of identity fraud.

The potential consequences are part of the risk analysis.

14. Risk assessment is a structured exercise

A serious breach assessment should not simply contain a conclusion such as:

“Low risk, no notification.”

That is inadequate from an accountability perspective.

The controller should consider at least:

1. type of breach;

2. nature of the personal data;

3. sensitivity of the data;

4. volume of data;

5. number of individuals;

6. ability to identify individuals;

7. likely consequences;

8. vulnerability of affected individuals;

9. characteristics of the controller;

10. effectiveness of security measures;

11. possibility of misuse;

12. whether the data remains accessible to an unauthorised person;

13. whether containment measures reduce the risk;

14. whether the attacker has actually accessed or exfiltrated the data;

15. whether encryption or other safeguards make the data unintelligible.

The risk assessment should be evidence-based.

15. Type of breach matters

Different breach types create different risk profiles.

Confidentiality breach

Suppose employee salary information is accidentally sent to another employee.

The main concern may be:

• embarrassment;

• workplace discrimination;

• loss of confidentiality;

• reputational damage.

But if a database containing passport information is stolen by criminals, the potential consequences may include:

• identity fraud;

• financial crime;

• impersonation.

Integrity breach

Suppose an attacker changes bank-account details in customer records.

The concern is not merely that the database has been altered.

The altered information could cause:

• payments to the wrong account;

• financial loss;

• fraudulent transactions;

• incorrect decisions.

Availability breach

Suppose a hospital loses access to patient records.

The issue can potentially extend beyond inconvenience.

If doctors cannot access essential medical information, availability loss may create physical risks.

Therefore, availability breaches should not automatically be treated as low-risk simply because confidentiality was not compromised.

16. Sensitivity of data matters - but special-category data is not required

Health information, biometric data, financial information, identity documents, authentication credentials and similar data may create elevated risks.

But there is no rule saying:

“Only sensitive data creates risk.”

Ordinary personal data can also create substantial risks depending on context.

A name and address may appear relatively innocuous.

But consider:

• a protected witness;

• a person escaping domestic abuse;

• an undercover investigator;

• an adoptive parent whose address must remain confidential;

• a person in a witness-protection context.

The same categories of data can therefore have completely different risk profiles depending upon context.

This is why risk assessment cannot be reduced to a checklist saying:

“Name + address = low risk.”

Context matters.

17. Combining data can increase risk

A breach involving one isolated data element may present limited risk.

But combinations can materially change the analysis.

For example:

Name + address

may create relatively limited risk.

But:

Name + address + date of birth + government ID + bank details + authentication information

can create a much greater possibility of:

• identity theft;

• financial fraud;

• account takeover;

• impersonation.

The risk therefore depends not merely on the individual fields but on what an attacker can do with the combination.

18. Number of affected individuals matters - but is not decisive

Large-scale breaches naturally deserve careful attention.

However:

“Only 10 people were affected”

does not automatically mean “no notification.”

A breach affecting one individual may be highly serious.

Example

disclosure of one person's:

• medical records;

• sexual-health information;

• domestic-abuse shelter location;

• criminal-victim information;

• immigration information;

• confidential employment information

could create considerable risk.

Conversely, a very large breach involving relatively low-risk information may not necessarily create the same level of individual harm.

Thus:

Scale is a factor, not a substitute for risk analysis.

19. Vulnerable individuals receive particular attention

The identity and characteristics of the affected data subjects matter.

Children are a classic example.

Other potentially vulnerable groups may include:

• elderly individuals;

• persons with disabilities;

• patients;

• financially vulnerable individuals;

• individuals dependent on public services;

• persons exposed to coercion or discrimination.

The same breach may therefore present different risks depending on who is affected.

A breach involving children's educational or behavioural records should not be assessed identically to an equivalent breach involving ordinary business-contact information.

20. Encryption and pseudonymisation can change the analysis

One of the most important practical factors is whether the breached information was protected by effective technical measures.

Suppose a company loses a laptop containing a database.

If:

• the entire disk is strongly encrypted;

• the encryption key is not stored on the laptop;

• the key has not been compromised;

• the encryption remains effective; and

• another copy of the data exists,

the likelihood that an unauthorised person can meaningfully access the personal data may be low.

Consequently, Article 33 notification may not be necessary.

But the conclusion must be revisited if:

• the encryption key was stored on the device;

• credentials were compromised;

• the encryption algorithm is broken;

• the attacker obtained the key;

• the data was also copied elsewhere;

• the device was remotely unlocked;

• or the organisation cannot establish that encryption actually operated.

“Encrypted” is therefore not a magic word.

The relevant question is:

Was the data effectively rendered unintelligible to the unauthorised person in the circumstances?

21. Containment measures can affect risk

Risk assessment is not necessarily frozen at the instant of discovery.

Suppose a malicious insider accesses 10,000 records.

Within 30 minutes, the organisation:

• disables the account;

• terminates all sessions;

• revokes credentials;

• prevents further access;

• confirms that no data was downloaded;

• verifies system logs.

The containment measures may reduce the likelihood of further harm.

However, containment does not necessarily erase the breach.

The organisation still has to assess what happened and whether the breach created a risk.

A useful distinction is:

Breach occurrence andongoing risk are separate questions.

Stopping the attacker may reduce ongoing risk, but it does not retroactively mean that no breach occurred.

22. The controller should document the risk assessment

This is one of the most important practical consequences of Article 33(5).

Suppose the controller decides:

“No notification required.”

The question then becomes:

“Why?”

The organisation should be able to produce a contemporaneous record showing:

• what happened;

• what personal data was involved;

• how many people were affected;

• what safeguards existed;

• whether unauthorised access occurred;

• what consequences were considered;

• why those consequences were considered unlikely;

• what containment occurred;

• who made the decision;

• when the decision was made.

This transforms a conclusion into an auditable decision.

23. “When in doubt, notify” - but with nuance

A cautious organisation may prefer notification where there is genuine uncertainty.

That is often sensible because:

• notification does not automatically mean liability;

• the supervisory authority can receive additional information;

• the regulator may provide guidance;

• failure to notify where notification was required can create enforcement exposure.

But “notify everything” is not necessarily the correct compliance strategy.

Excessive notification can:

• burden regulators;

• dilute the significance of genuinely serious incidents;

• create operational costs;

• reflect poor internal risk assessment.

The objective should therefore be defensible, evidence-based assessment, not indiscriminate notification.

24. The identity of the competent supervisory authority

Notification must go to the appropriate supervisory authority.

This becomes especially important in cross-border processing.

For ordinary domestic processing, determining the competent authority may be comparatively straightforward.

For cross-border processing, however, the organisation may need to determine whether a lead supervisory authority is involved.

The lead authority generally relates to the controller's main establishment or single establishment for cross-border processing.

A common mistake is to assume:

“Notify the authority where the breach happened.”

That is not necessarily correct.

Another mistake is:

“Notify the authority where most affected individuals live.”

Again, that may not be the correct approach where the one-stop-shop mechanism applies.

Incident-response plans should therefore identify the likely competent authority before a breach occurs.

25. Non-EU organisations

An organisation outside the European Union may nevertheless fall within GDPR territorial scope, particularly under Article 3(2).

If such an organisation is subject to GDPR and experiences a personal data breach affecting individuals in multiple EU Member States, the supervisory-authority question becomes particularly important.

The one-stop-shop framework does not operate in exactly the same way for every non-EU organisation because the organisation may not have an EU main establishment.

Accordingly, a non-EU controller should not assume that having GDPR applicability automatically means there is one obvious single regulator to notify.

The geographic distribution of affected data subjects and the organisation's EU establishments must be examined carefully.

26. What if the controller notifies the wrong supervisory authority?

This is a practical grey area.

Suppose a controller genuinely misunderstands which authority is competent and sends the notification to the wrong authority.

That does not necessarily mean the organisation can simply assume compliance.

The safer approach is:

1. identify the mistake quickly;

2. contact the authority;

3. determine where notification should properly be made;

4. notify the correct authority where necessary;

5. document the circumstances.

The lesson is that competent-authority analysis should form part of the incident-response plan.

27. What must the notification contain?

Article 33(3) uses the expression “at least”.

That phrase is extremely important.

The listed information is a minimum.

The controller is not restricted to those four categories.

The notification should give the supervisory authority enough information to understand:

• what happened;

• who is affected;

• what information is involved;

• what harm may result;

• what the controller has done;

• what it plans to do.

A technically accurate but practically useless notification is not ideal.

For example:

“We experienced a cyber incident affecting customer data. We are investigating.”

That is unlikely to be sufficient if more information is reasonably available.

28. Nature of the breach

The notification should explain the character of the breach.

For example:

“An unauthorised third party obtained access to an employee account and subsequently accessed a customer database.”

That is much more useful than:

“Security incident.”

The authority should be able to understand whether the breach concerns:

• confidentiality;

• integrity;

• availability;

• or several of these.

The notification should also explain how the breach occurred if known.

For example:

• phishing;

• ransomware;

• misconfiguration;

• lost device;

• human error;

• malicious insider;

• software vulnerability;

• accidental disclosure.

29. Categories of data subjects

The notification should identify who is affected.

Examples

include:

• customers;
• employees;
• former employees;
• children;
• patients;
• students;
• account holders;
• website users;
• suppliers;
• applicants. This matters because the identity of affected individuals informs the risk analysis. For example: “The breach affected approximately 5,000 customers” is useful. But: “The breach affected approximately 5,000 children using an online educational platform” provides a substantially more meaningful risk picture.

30. Categories of personal data

The authority should also understand what kinds of data were involved.

Examples

include:

• contact details;
• account credentials;
• financial information;
• identification documents;
• location data;
• health information;
• employment information;
• communications;
• behavioural data;
• special-category data. Again, specificity matters. “Personal data” is too broad to communicate the actual risk.

31. Approximate numbers are expressly contemplated

Organisations often make the mistake of thinking:

“We cannot notify because we don't know the exact number.”

That is not the purpose of the rule.

The GDPR expressly contemplates approximate numbers.

Suppose the controller initially knows:

“Approximately 50,000, 70,000 accounts may have been affected.”

It can provide that approximation and later update the authority.

This reflects an important policy choice:

Speed is more important than artificial precision at the initial stage.

The organisation should not spend 72 hours attempting to calculate the exact number when it could submit an initial notification and provide an updated figure later.

32. Contact information

The authority needs a person through whom it can obtain additional information.

This is why the notification should provide the DPO's details where applicable or another appropriate contact point.

The contact should be genuinely operational.

It should not be merely a generic mailbox that nobody monitors.

The authority may need to ask:

• What happened?

• Has the attacker been contained?

• Are more systems affected?

• Are data subjects being informed?

• Has law enforcement been contacted?

• What forensic evidence exists?

• What remediation has occurred?

The contact person must therefore be capable of facilitating continuing communication.

33. Likely consequences

The controller must describe the likely consequences of the breach.

This is not a requirement to predict the future with certainty.

The controller should identify plausible consequences based on the evidence available.

For example:

“Exposure of email addresses and telephone numbers may increase the risk of targeted phishing.”

Or:

“Exposure of identity documents may facilitate identity fraud.”

Or:

“Unauthorised modification of payment information may result in fraudulent redirection of payments.”

This is also where the earlier risk assessment becomes visible.

The notification should not simply say:

“There may be consequences.”

It should explain what those consequences are likely to be.

34. Measures taken and proposed

The authority also needs to know what the controller is doing about the incident.

This may include:

Immediate containment

• disabling compromised accounts;

• isolating systems;

• blocking malicious IP addresses;

• revoking credentials;

• disconnecting affected infrastructure.

Investigation

• forensic analysis;

• log examination;

• malware analysis;

• investigation of access records.

Remediation

• patching vulnerabilities;

• changing passwords;

• improving access controls;

• strengthening authentication;

• improving encryption;

• modifying configuration.

Harm mitigation

• warning affected individuals;

• monitoring accounts;

• providing fraud support;

• resetting credentials;

• increasing security controls.

This information demonstrates that the organisation is actively responding rather than merely reporting the incident.

35. Proposed measures matter even if not yet implemented

The controller does not have to wait until every remedial action has been completed before making the notification.

At the initial stage, it may be able to say:

“We have disabled the compromised credentials and isolated the affected server. We are conducting forensic analysis and intend to implement additional authentication controls following completion of the investigation.”

This is precisely why Article 33 accommodates information about measures proposed to be taken.

36. Notification in phases

One of the most practically important provisions is the ability to provide information in phases.

Complex cyber incidents often unfold over days or weeks.

At hour 24, the controller may know:

• an attack occurred;

• one database was accessed;

• approximately 100,000 records may be affected.

But it may not yet know:

• the precise number of records;

• whether data was exfiltrated;

• exactly which categories of data were accessed;

• the identity of the attacker;

• the precise attack vector.

Article 33 does not require the controller to wait for complete forensic certainty.

The controller can make an initial notification and supplement it.

37. Phased notification is not a loophole

The phased-notification mechanism must not become:

“We will notify the authority once the investigation is finished.”

That would defeat the 72-hour mechanism.

The proper approach is:

Notify what is reasonably known now → explain what is unknown → continue investigating → provide additional information without undue further delay.

The initial notification should therefore clearly state that it is preliminary where appropriate.

38. Example of proper phased notification

Imagine a ransomware incident.

At hour 30:

• unauthorised access confirmed;

• customer database affected;

• approximately 250,000 individuals potentially affected;

• exact records unknown;

• exfiltration not yet confirmed.

The controller can notify with those facts.

At hour 60:

• forensic evidence suggests approximately 180,000 records were accessed.

The controller updates the authority.

At day 5:

• investigators establish that names, addresses and hashed passwords were accessed;

• no payment-card information was affected.

The controller provides another update.

The notification process is therefore dynamic.

Article 33 should be viewed as a continuing regulatory communication process, not necessarily as a single document submitted once and forgotten.

39. There is no penalty simply because an initial assessment later changes

A controller may initially reasonably believe that a breach occurred and notify the authority.

Later forensic investigation may establish:

“The suspected attacker never actually accessed personal data.”

The controller should update the authority.

The fact that the initial notification later turns out to have been based on incomplete information does not itself mean the controller acted improperly.

Indeed, this is preferable to suppressing notification until absolute certainty exists.

40. Law-enforcement interests

Recital 88 recognises that breach notification rules must take account of legitimate law-enforcement interests.

There may be situations in which premature public disclosure could interfere with an investigation.

However, this does not create a general exemption from Article 33.

The controller must carefully distinguish:

• notification to the supervisory authority; and

• public communication or communication to affected individuals.

A controller should not casually argue:

“Police asked us not to say anything, therefore GDPR notification is unnecessary.”

The actual circumstances and applicable legal requirements must be assessed.

The supervisory authority itself may be able to coordinate with law enforcement.

41. Article 33 and Article 34 must be analysed separately

This distinction deserves emphasis.

Suppose an organisation suffers a breach involving customer email addresses.

The breach may create a risk sufficient for Article 33.

But it may not create a high risk sufficient to trigger Article 34 communication.

The controller therefore may need to:

• notify the supervisory authority;

• but not notify every affected individual.

Conversely, where highly sensitive information is exposed and serious consequences are likely, both provisions may apply.

The two assessments should therefore be documented separately.

A breach-response form should ideally have separate fields:

Article 33 risk assessment

and

Article 34 high-risk assessment.

42. Article 33(5): the often-underestimated obligation

Article 33(5) is sometimes treated as an administrative footnote.

It is not.

It creates an independent accountability obligation.

The controller must document any personal data breach.

This is broader than the notification obligation.

That means:

No Article 33 notification does not mean no Article 33 documentation.

This is one of the most important practical points.

Suppose 100 personal data breaches occur during a year:

• 20 require notification;

• 80 do not meet the risk threshold.

The controller should still document all 100.

43. Why document breaches that were not notified?

Because the regulator may later ask:

“How did you determine that notification was unnecessary?”

The controller must be able to demonstrate that the decision was reasoned.

Article 33(5) therefore converts the internal risk assessment into evidence of accountability.

It protects against retrospective reasoning.

Without documentation, an organisation may later say:

“We considered it low risk.”

But it may be unable to demonstrate:

• who assessed it;

• when;

• on what information;

• under what criteria;

• what safeguards existed;

• what consequences were considered.

That weakens the organisation's position considerably.

44. What should a breach record contain?

Although the GDPR does not prescribe a rigid template, a robust breach register should ordinarily capture:

Incident identification

• incident number;

• date and time discovered;

• date and time believed to have occurred;

• source of detection;

• responsible business unit.

Nature

• confidentiality;

• integrity;

• availability;

• combination of categories.

Personal data

• categories of data;

• categories of data subjects;

• approximate number of individuals;

• approximate number of records.

Circumstances

• attack vector;

• human error;

• technical failure;

• unauthorised access;

• accidental disclosure;

• loss or destruction.

Risk assessment

• likelihood;

• severity;

• potential consequences;

• vulnerability of affected individuals;

• mitigating safeguards.

Regulatory decision

• Article 33 notification required/not required;

• reasoning;

• authority notified;

• date/time of notification.

Article 34

• high-risk assessment;

• communication required/not required;

• reasoning.

Remediation

• containment;

• recovery;

• technical fixes;

• organisational changes;

• preventive measures.

• logs;

• forensic reports;

• correspondence;

• processor notifications;

• decision records.

45. Documentation should capture reasoning, not merely facts

This is a subtle but important point.

A breach register saying:

“Data breach, no notification.”

is insufficiently informative.

A stronger record might say:

“Lost encrypted laptop containing customer contact information. Full-disk encryption was confirmed operational. Encryption keys were not stored on the device and remain securely controlled by the organisation. No evidence indicates compromise of credentials or keys. A duplicate copy of the information remains available. Based on these circumstances, the organisation assessed the likelihood of unauthorised access to the personal data as low and concluded that the breach was unlikely to result in a risk to individuals' rights and freedoms. Article 33 notification was therefore not made.”

That record demonstrates the reasoning process.

46. Retention period for breach documentation

The GDPR does not prescribe a specific universal retention period for Article 33 breach records.

This creates a practical governance question.

The controller should establish an appropriate retention period based on:

• accountability requirements;

• limitation periods;

• regulatory enforcement risk;

• litigation exposure;

• internal audit requirements;

• sector-specific obligations;

• legal requirements;

• sensitivity of the information.

The fact that Article 33 does not provide a specific period does not mean the organisation should delete records immediately after the incident closes.

Indeed, premature deletion could make it impossible to demonstrate compliance later.

47. Breach registers themselves can contain personal data

Although breach documentation may contain relatively limited personal data, it can nevertheless contain sensitive information.

For example:

• names of affected employees;

• usernames;

• IP addresses;

• details of disciplinary incidents;

• health information;

• victim information;

• forensic evidence.

The breach register should therefore itself be appropriately secured.

The organisation should apply:

• access controls;

• confidentiality measures;

• retention rules;

• role-based access;

• encryption where appropriate.

It would be ironic if a breach register created a second privacy problem because too many employees could access it.

48. Security incidents that are not personal data breaches

The final distinction is between:

security incident

and

personal data breach.

Suppose:

• a phishing email is received;

• it is detected immediately;

• no credentials are entered;

• no personal data is accessed;

• no system is compromised.

This may not qualify as a personal data breach.

Article 33(5) does not require such an event to be documented as a personal data breach.

However, organisations may nevertheless choose to record security incidents voluntarily.

That can be valuable for:

• security monitoring;

• threat intelligence;

• trend analysis;

• employee training;

• audit;

• incident-response improvement.

A mature organisation will therefore often maintain separate but connected records for:

1. security incidents;

2. suspected personal data breaches;

3. confirmed personal data breaches;

4. regulatory notifications;

5. data-subject communications.

49. The relationship between Article 33 and Article 32

A breach can reveal failures in security controls.

Example

suppose a database is exposed because:

• default credentials were left unchanged;

• access controls were misconfigured;

• encryption was not enabled;

• security patches were not applied.

The Article 33 notification addresses the breach.

But the supervisory authority may also ask:

“Why did this happen?”

This leads directly to Article 32.

The regulator may examine whether the controller had implemented appropriate technical and organisational measures.

Consequently, a breach notification is potentially the beginning of a wider regulatory examination.

This is one reason organisations sometimes hesitate to notify.

But failure to notify can itself create an additional compliance violation.

50. Notification does not constitute an admission of GDPR liability

A sophisticated breach-response process should distinguish between:

reporting facts

and

admitting legal fault.

The controller can say:

“An unauthorised third party gained access to the database.”

without necessarily saying:

“We violated Article 32.”

The notification should accurately describe:

• what occurred;

• what is known;

• what is unknown;

• what the controller is doing.

Legal conclusions should be carefully considered.

The objective is transparency and regulatory cooperation, not unnecessary self-characterisation.

51. But the notification must not be misleading

There is a difference between avoiding premature legal conclusions and minimising the incident.

Example

saying:

“A limited technical issue occurred”

when forensic evidence indicates that an attacker accessed thousands of customer records would be inappropriate.

A notification should be:

• accurate;

• sufficiently specific;

• candid about uncertainty;

• updated as facts develop.

Where facts are uncertain, the controller should say so.

For example:

“At the time of this notification, exfiltration has not been confirmed. Forensic investigation remains ongoing.”

That is preferable to either speculation or concealment.

52. Trade secrets and confidential information

A controller generally does not need to disclose every internal technical detail or hand over the compromised personal data itself merely because it is notifying the authority.

The notification should contain information necessary for regulatory assessment.

There may be legitimate concerns regarding:

• trade secrets;

• security architecture;

• proprietary technology;

• confidential business information.

But confidentiality concerns should not be used as a blanket excuse to withhold relevant information from a competent supervisory authority.

The supervisory authority has its own legal framework for handling information.

53. Relationship with contractual breach obligations

A controller may simultaneously have obligations under:

• customer contracts;

• insurance policies;

• banking regulations;

• sectoral cybersecurity laws;

• employment agreements;

• processor contracts;

• cloud-provider agreements.

Article 33 does not replace those obligations.

Example

a processor contract might require notification within 6 hours, while Article 33 gives the controller the 72-hour framework.

The controller must comply with both.

Similarly, a cyber-insurance policy might require immediate notification to the insurer.

Incident response should therefore map all parallel notification obligations, not merely GDPR.

54. Practical breach-response timeline

A mature organisation can structure its response approximately as follows.

Stage 1 - Detection

A suspicious event is detected.

Immediately:

• preserve evidence;

• activate incident response;

• identify responsible personnel;

• begin investigation.

Stage 2 - Qualification

Determine whether personal data may be affected.

If not, treat as a security incident.

If yes, investigate whether a personal data breach occurred.

Stage 3 - Awareness

Determine when there is reasonable certainty that personal data has been compromised.

Record this timestamp.

Stage 4 - Risk assessment

Assess:

• nature;

• sensitivity;

• volume;

• individuals;

• vulnerability;

• likely consequences;

• likelihood;

• severity;

• safeguards.

Stage 5 - Regulatory decision

Determine whether Article 33 notification is required.

Stage 6 - Initial notification

If required, notify without undue delay and, where feasible, within 72 hours.

Do not wait for perfect information.

Stage 7 - Data-subject assessment

Separately determine whether Article 34 applies.

Stage 8 - Continuing investigation

Determine:

• exact scope;

• root cause;

• data accessed;

• affected individuals;

• remediation.

Stage 9 - Updates

Provide supplementary information without undue further delay.

Stage 10 - Closure

Document:

• facts;

• effects;

• decisions;

• remediation;

• lessons learned.

55. A useful distinction: detection time, awareness time and breach time

These three timestamps should not automatically be treated as identical.

Breach time

When the compromise actually occurred.

Detection time

When the organisation detected the suspicious event.

Awareness time

When the controller acquired reasonable certainty that a personal data breach had occurred.

For example:

Monday 10:00 - attacker gains access

Tuesday 09:00 - security system detects unusual activity

Tuesday 14:00 - investigation establishes personal data was accessed

The Article 33 clock generally turns on the controller's awareness rather than the original moment of compromise.

This distinction should be documented carefully because it may become relevant during regulatory scrutiny.

56. What if the controller discovers the breach late?

Suppose the controller learns on Friday that attackers had been accessing personal data for three weeks.

The 72-hour period does not normally run from the original attack date merely because the attack began weeks earlier.

The important issue is when the controller became aware of the breach.

But the regulator may reasonably ask:

“Why did your security controls fail to detect this for three weeks?”

That question may lead into Article 32 compliance.

Thus, late detection can create two separate issues:

1. Article 33 timing from awareness;

2. possible concerns regarding the adequacy of security and detection measures under Article 32.

57. Multiple related breaches

Sometimes an organisation discovers several similar breaches.

Example

it discovers that multiple employees have repeatedly emailed customer spreadsheets to the wrong recipients over a short period.

Instead of treating every event in complete isolation, it may be appropriate in certain circumstances to organise a meaningful notification covering closely related incidents.

However, this should not become a method of artificially delaying reporting.

The EDPB recognises that multiple similar breaches may create situations in which a consolidated notification is sensible.

The key considerations are:

• similarity;

• timing;

• circumstances;

• whether meaningful regulatory information can be provided;

• whether delay would prejudice affected individuals.

58. The importance of an Incident Response Plan

Article 33 practically requires organisational readiness.

A robust Incident Response Plan should specify:

Who receives the first report?

For example:

employee → IT/security team → privacy/legal → DPO → senior management.

Who decides whether a breach occurred?

A defined multidisciplinary team.

Who performs risk assessment?

Usually a combination of privacy/legal, security and business personnel.

Who contacts the processor?

Defined operational owner.

Who contacts the supervisory authority?

Defined person or team.

Who communicates with affected individuals?

Defined communications function, coordinated with legal/privacy.

Who preserves evidence?

Security/forensic team.

Who approves final decisions?

Appropriate governance authority.

Without this structure, the first 72 hours can be consumed by internal uncertainty.

59. Training employees is therefore part of breach compliance

Employees are often the first people to discover a breach.

They should know:

• what constitutes a potential incident;

• whom to contact;

• that they should not conceal mistakes;

• that accidental disclosure can constitute a personal data breach;

• how urgently incidents must be reported;

• not to delete evidence;

• not to investigate beyond their competence.

An employee who accidentally sends a customer spreadsheet to the wrong person should have a clear reporting channel.

The objective is to encourage:

rapid reporting, not blame avoidance.

If employees fear disciplinary consequences, they may delay reporting, which can make Article 33 compliance more difficult.

60. The “72-hour trap”

A common organisational mistake is treating 72 hours as sufficient time to organise everything.

In reality, the controller needs time for:

• technical investigation;

• legal analysis;

• risk assessment;

• authority identification;

• notification drafting;

• management approval;

• communications planning.

If the organisation spends the first 48 hours simply arguing about whether the incident is a breach, it may leave inadequate time for notification.

The better approach is:

investigate and assess in parallel.

Legal, security and business teams should work simultaneously rather than sequentially.

61. The role of the DPO

Where an organisation has a DPO, the DPO is an important participant in breach management.

The DPO may:

• advise on GDPR obligations;

• assist in risk assessment;

• advise on notification;

• coordinate with supervisory authorities where appropriate;

• monitor compliance.

But the DPO should not automatically become the person legally responsible for every breach decision.

The controller remains responsible for compliance.

The DPO's role must also respect the independence requirements applicable to the position.

62. Article 33 is fundamentally an accountability provision

The deepest principle underlying Article 33 is accountability.

A regulator should be able to ask:

“You experienced a breach. What did you do?”

A mature controller should be able to answer:

1. We detected it.

2. We investigated it.

3. We established when we became aware.

4. We identified the affected personal data.

5. We assessed the risk.

6. We determined whether Article 33 applied.

7. We notified the authority where required.

8. We assessed Article 34 separately.

9. We contained the incident.

10. We remediated the underlying problem.

11. We documented everything.

That is the essence of Article 33 compliance.

63. Common mistakes under Article 33

Mistake 1: “Every breach must be reported.”

Wrong.

The Article 33 risk threshold matters.

Mistake 2: “We have 72 hours.”

Not exactly.

The obligation is without undue delay and, where feasible, within 72 hours.

Mistake 3: “We cannot notify until the investigation is complete.”

Wrong.

Phased notification exists precisely because complete information may not initially be available.

Mistake 4: “The processor will notify the regulator.”

Normally wrong under Article 33.

The processor informs the controller.

Mistake 5: “No notification means no documentation.”

Wrong.

All personal data breaches must be documented.

Mistake 6: “Only sensitive personal data creates risk.”

Wrong.

Ordinary personal data can create serious contextual risks.

Mistake 7: “Only large breaches matter.”

Wrong.

A breach affecting one vulnerable individual may be serious.

Mistake 8: “Encryption automatically eliminates risk.”

Wrong.

The effectiveness of the encryption and the protection of the keys matter.

Mistake 9: “We should wait until we know the exact number.”

Wrong.

Approximate numbers are permitted.

Mistake 10: “A cyberattack is automatically a personal data breach.”

Wrong.

Personal data must actually be compromised.

Mistake 11: “If the attacker was stopped quickly, there was no breach.”

Wrong.

Containment does not erase an already occurring breach.

Mistake 12: “The authority only needs the headline.”

Wrong.

The notification must contain sufficient information for meaningful assessment.

64. The most important grey area: deciding whether risk exists

The hardest Article 33 decisions usually involve borderline cases.

For example:

An employee accidentally emails 300 customer names and addresses to another customer.

Questions arise:

• Did the recipient open the email?

• Was the recipient trustworthy?

• Were the addresses sensitive?

• Can the recipient be contacted?

• Did the recipient delete the message?

• Could the information be misused?

• Were the affected customers vulnerable?

• Was the disclosure accidental and immediately contained?

There is no automatic numerical formula.

The controller must assess the actual circumstances.

This is why breach assessment requires judgement rather than merely ticking boxes.

65. A second grey area: misdirected communications

Consider a hospital employee who accidentally sends medical information to the wrong email address.

Even if the employee immediately recalls the email, the controller must ask:

• Was the email actually delivered?

• Did the recipient open it?

• Was the recipient known?

• Did the recipient confirm deletion?

• Was the information highly sensitive?

• Could the recipient misuse it?

• Was the recipient in a position to cause harm?

The assessment should be evidence-based.

The mere fact that a mistake was quickly corrected does not automatically eliminate the risk.

66. A third grey area: lost devices

A lost laptop containing personal data should trigger a structured analysis.

Questions include:

• Was the disk encrypted?

• What encryption standard was used?

• Was the device password protected?

• Was the device remotely managed?

• Could the attacker bypass authentication?

• Were encryption keys separately protected?

• Was the data duplicated elsewhere?

• Was the device remotely wiped?

• Was there evidence of access?

A securely encrypted laptop with no compromised keys may result in a different conclusion from an unencrypted laptop containing the same data.

67. A fourth grey area: ransomware

Ransomware should not automatically be classified as only an availability breach.

The controller must determine whether:

• data was encrypted;

• data was exfiltrated;

• credentials were stolen;

• systems were accessed;

• backups were compromised;

• personal data was altered;

• personal data became unavailable.

Modern ransomware attacks frequently involve both encryption and exfiltration.

Therefore:

“We restored the backup, so there was no breach.”

is not an adequate analysis.

Restoration may address availability but does not necessarily address confidentiality.

68. A fifth grey area: employee misconduct

Suppose an employee intentionally downloads customer records before leaving the organisation.

This can be a personal data breach even though:

• the employee was originally authorised to access the data;

• the organisation trusted the employee;

• the employee's account was legitimate.

The key issue is whether the subsequent access, use or disclosure was authorised.

A person may have legitimate access to personal data for one purpose but act outside that authority.

69. Article 33 as a governance test

A regulator reviewing a breach may look beyond the incident itself.

The authority may effectively ask:

“What does this breach tell us about the organisation?”

For example:

If the organisation:

• detected the breach quickly;

• notified promptly;

• documented the assessment;

• contained the incident;

• cooperated with the authority;

• remediated the vulnerability;

the incident demonstrates mature governance.

If the organisation:

• discovered the breach late;

• failed to notify;

• had no incident-response plan;

• could not identify affected data;

• had no documentation;

• blamed the processor;

• delayed for weeks;

the same underlying incident can produce much greater regulatory concern.

Article 33 therefore functions as a governance test as much as a reporting rule.

70. The processor - controller contract should operationalise Article 33

A well-drafted Article 28 agreement should not simply reproduce the words:

“Processor shall notify Controller without undue delay.”

That is legally correct but operationally weak.

A better agreement should address:

• notification deadline;

• emergency contact;

• required initial information;

• information updates;

• forensic assistance;

• preservation of evidence;

• affected-data identification;

• affected-data-subject identification;

• cooperation with regulators;

• cooperation with Article 34 communications;

• subprocessor notification;

• incident-response testing;

• post-incident investigation;

• remediation.

For high-risk processing, contractual specificity is especially important.

71. The processor's role does not eliminate controller accountability

A controller cannot ordinarily defend an Article 33 failure merely by saying:

“Our processor failed to notify us.”

The processor may have breached its contractual and GDPR obligations.

But the controller's own regulatory responsibility does not simply disappear.

This is why processor selection, contractual controls and monitoring are important aspects of controller accountability.

Article 28 and Article 33 should therefore be understood together.

72. Final conceptual framework

The easiest way to remember Article 33 is to divide it into five questions.

Question 1, Did a personal data breach occur?

If no:

Article 33 does not apply.

If yes:

Proceed.

Question 2, Has the controller become aware?

If no:

Investigate promptly.

If yes:

Record the awareness time.

Question 3, Is the breach likely to result in a risk?

If no:

Generally no supervisory-authority notification, but document the breach and reasoning.

If yes:

Notify the competent supervisory authority.

Question 4, Do we know everything?

If yes:

Provide the required information.

If no:

Notify with available information and supplement later.

Question 5, What happened afterwards?

Document:

• facts;

• effects;

• decisions;

• remedial action.

This is the operational core of Article 33.

73. Article 33 and the principle of accountability

Ultimately, Article 33 demonstrates why accountability under Article 5(2) is so important.

GDPR compliance is not merely:

“We believe we complied.”

It is:

“We can demonstrate why we concluded that we complied.”

That distinction becomes particularly important when an organisation chooses not to notify.

A notification can itself demonstrate that the organisation recognised the incident and acted.

A non-notification decision requires particularly strong internal evidence because the organisation must later explain why the risk threshold was not met.

Thus, Article 33(5) turns the breach register into an important accountability instrument.

74. Practical compliance checklist

A controller should ideally be able to answer “yes” to the following:

Detection

• Do we have mechanisms capable of detecting personal data breaches?

• Do employees know how to report incidents?

• Do processors have immediate escalation channels?

Awareness

• Do we record when the controller became aware?

• Can we distinguish suspicion from reasonable certainty?

• Do we prevent artificial delays in declaring awareness?

Risk assessment

• Do we assess confidentiality, integrity and availability separately?

• Do we consider sensitivity and volume?

• Do we consider affected individuals?

• Do we consider vulnerable individuals?

• Do we assess likelihood and severity?

• Do we consider encryption and other safeguards?

Notification

• Do we know which supervisory authority is competent?

• Can we notify within 72 hours?

• Do we have a notification template?

• Can we explain delays?

• Can we make phased notifications?

Processor management

• Are processors contractually required to notify quickly?

• Do they provide sufficient information?

• Do they cooperate with investigation?

• Do they assist with Articles 33 and 34?

Documentation

• Do we record all personal data breaches?

• Do we record non-notification decisions?

• Do we record reasoning?

• Do we record remedial measures?

• Do we retain records appropriately?

Post-incident

• Do we identify root cause?

• Do we remediate vulnerabilities?

• Do we assess Article 32 compliance?

• Do we update policies and controls?

• Do we learn from the incident?

75. Conclusion

Article 33 is much more than the famous “72-hour breach notification rule.”

Its deeper structure is:

detect → investigate → establish awareness → assess risk → notify where required → update progressively → document everything.

The provision deliberately balances two competing realities.

On one side, regulators need timely information so that they can intervene and help protect affected individuals.

On the other side, breach investigations are often incomplete during the first few hours. Requiring perfect information before notification would therefore be impractical and potentially harmful.

The GDPR resolves this tension through several interconnected mechanisms:

• the reasonable-awareness threshold prevents mere suspicion from automatically triggering notification;

• the 72-hour benchmark forces rapid action;

• the “without undue delay” requirement prevents controllers from treating 72 hours as a grace period;

• the risk threshold prevents unnecessary reporting of breaches unlikely to harm individuals;

• approximate numbers prevent incomplete information from paralysing notification;

• phased notification allows information to be supplemented as investigations progress;

• the processor notification obligation ensures controllers are alerted rapidly when breaches occur in outsourced environments; and

• the documentation obligation ensures that even non-notified breaches remain subject to accountability.

The most important practical lesson is therefore that Article 33 is not a single decision made at the end of an investigation. It is a continuous incident-governance process.

A sophisticated controller should be able to reconstruct the entire chain:

When did we first detect the incident? When did we become reasonably certain that personal data was compromised? What information did we have at that moment? What risk assessment did we conduct? Why did we notify or not notify? Why did we choose that supervisory authority? What did we tell the authority within the first 72 hours? What information was unavailable and why? When did we provide supplementary information? What happened to the affected individuals? What containment and remedial measures were taken? What did we learn from the incident?

That is the real compliance architecture of Article 33.

The provision should consequently be understood as creating three distinct but interconnected duties:

1. The notification duty

Where a personal data breach is likely to result in a risk to individuals' rights and freedoms, the controller must notify the competent supervisory authority without undue delay and, where feasible, within 72 hours of awareness.

2. The cooperation and escalation duty

Processors must rapidly alert controllers, controllers must cooperate with supervisory authorities, and incomplete information must be supplemented as the investigation develops.

3. The accountability duty

Every personal data breach must be documented sufficiently to demonstrate how the controller assessed the incident, what effects were identified, what decision was made and what remedial action was taken.

This third element is particularly important because it means that “we did not notify” is itself a decision that must be capable of justification.

The strongest Article 33 compliance programme therefore does not merely have a breach-notification template. It has an integrated personal data breach management framework covering detection, escalation, investigation, risk assessment, authority identification, regulatory notification, data-subject assessment, processor cooperation, remediation and documentation.

In practical terms, the single most dangerous Article 33 mindset is:

“We have 72 hours, so we have time.”

The correct mindset is:

“We have an obligation to act without undue delay, and the 72-hour period is the maximum benchmark where notification within that period is feasible, not a period that the controller is entitled to consume.”

And the second most dangerous mindset is:

“The investigation is not finished, so we cannot notify.”

The correct approach is:

“Notify what is reasonably known, identify what remains unknown, and supplement the notification without undue further delay.”

Finally, the third major misconception is:

“If we do not notify, there is nothing to record.”

The correct position is the opposite:

A non-notified breach still requires documentation, and the reasoning behind the non-notification decision may ultimately be one of the most important pieces of evidence demonstrating GDPR compliance.

That combination, speed, risk-based judgement, phased communication and documented accountability, captures the essential legal and practical logic of Article 33 GDPR.