European Union — Breach Notification

Article 4(12) of the General Data Protection Regulation (Regulation (EU) 2016/679) provides the foundational definition that triggers all breach-notification obligations under Articles 33 and 34. The provision defines a "personal data breach" as "a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed."

This definition establishes three critical elements. First, there must be a breach of security — an incident compromising the safeguards that the controller has implemented to protect personal data under Article 32 GDPR (security of processing). The Court of Justice of the European Union (CJEU) clarified in Natsionalna agentsia za prihodite (C-340/21, judgment of 14 December 2023) that "unauthorised disclosure of personal data or unauthorised access to those data by a 'third party' … are not sufficient, in themselves, for it to be held that the technical and organisational measures implemented by the controller in question were not 'appropriate,'" but the fact of unauthorized access or disclosure confirms that a breach has occurred for notification purposes.

Second, the breach must involve personal data — any information relating to an identified or identifiable natural person, as defined in Article 4(1) GDPR. A security incident affecting only anonymized data or data relating to legal persons (where no natural person can be identified) does not constitute a personal data breach under Article 4(12), though controllers should verify that the data are genuinely anonymized and that re-identification is not feasible.

Third, the breach may be accidental or unlawful. The GDPR does not distinguish between malicious attacks (ransomware, phishing, SQL injection) and human error (sending an email to the wrong recipient, losing an unencrypted USB drive, accidental deletion of a database). Both categories trigger the Article 33 and Article 34 notification framework if the resulting harm meets the risk thresholds.

The three breach types: confidentiality, integrity, availability

The European Data Protection Board (EDPB) clarified in Guidelines 9/2022 on personal data breach notification (version 2.0, adopted 4 April 2023) that the Article 4(12) definition encompasses three distinct types of breach, which may occur individually or in combination:

1. Breach of confidentiality — unauthorised or accidental disclosure of, or access to, personal data. This is the most commonly recognized breach type. Examples include a cyberattack that exfiltrates a customer database, an email containing patient records sent to the wrong recipient, a publicly accessible cloud storage bucket containing employee data, or an insider accessing personnel files without authorization. The EDPB notes that even temporary unauthorized access — such as a brief network intrusion that is detected and blocked within minutes — constitutes a confidentiality breach if personal data were accessed or disclosed, regardless of whether the attacker retained or misused the data. The key question is whether someone who should not have had access obtained it, not whether harm ultimately materialized.

1. Breach of integrity — unauthorised or accidental alteration of personal data. Integrity breaches occur when personal data are modified, corrupted, or manipulated in a way that compromises their accuracy or completeness. Examples include a ransomware attack that encrypts files and renders them unreadable (altering the data structure), an SQL injection attack that changes customer account balances, a database corruption event that scrambles transaction records, or an employee who deliberately falsifies medical records. The EDPB's Guidelines 01/2021 on examples regarding personal data breach notification (adopted 14 December 2021) stress that controllers must investigate whether attackers not only accessed data (confidentiality) but also had the technical capability to alter it, because many intrusions involve both confidentiality and integrity breaches.

1. Breach of availability — accidental or unauthorised destruction of, or loss of access to, personal data. Availability breaches occur when personal data become unavailable to the controller or to data subjects who rely on access. The EDPB Guidelines 9/2022 state that "a breach will always be regarded as an availability breach when there has been a permanent loss of, or destruction of, personal data," such as accidental deletion of a customer database with no backup, physical destruction of servers in a fire or flood, or loss of the decryption key for encrypted data, rendering the data permanently inaccessible. The Guidelines further clarify that availability breaches also include temporary unavailability when the disruption is significant: "A loss of availability may also occur where there has been significant disruption to the normal service" — for example, a denial-of-service (DoS) attack that takes a healthcare provider's patient portal offline for several days, or a ransomware attack that locks medical records and prevents clinicians from accessing them during treatment. Article 32(1)(b) GDPR requires controllers to implement "the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services," and a failure of availability is itself a breach under Article 4(12).

Combination breaches and multiple breach types

The EDPB Guidelines 9/2022 emphasize that "depending on the circumstances, a breach can concern confidentiality, integrity and availability of personal data at the same time, as well as any combination of these." Ransomware attacks are the canonical combination breach: the attacker gains unauthorized access to the data (confidentiality breach), encrypts the files and alters their structure (integrity breach), and renders the data unavailable to the controller and data subjects (availability breach). The EDPB's Guidelines 01/2021 analyze multiple ransomware scenarios, noting that controllers must assess all three dimensions when determining the nature of the breach, the risk level, and the content of the notification to the supervisory authority and data subjects.

What is not a breach under Article 4(12)

The Article 4(12) definition requires a breach of security. Planned system maintenance that temporarily makes data unavailable is not a breach, because it does not compromise security — it is an expected operational event. Similarly, a controller's lawful deletion of personal data in compliance with a retention policy or a data-subject erasure request under Article 17 GDPR is not a breach, because the "destruction" is neither accidental nor unlawful.

The EDPB notes that not all security incidents are personal data breaches. An attempted phishing attack that is blocked by email filters before any employee clicks the malicious link is a security incident but not a breach, because no personal data were compromised. A vulnerability scan that identifies a potential SQL injection flaw before it is exploited is a security event requiring remediation under Article 32, but it is not a breach under Article 4(12) unless and until an attacker actually accesses, alters, or destroys personal data through that flaw.

Relationship to Article 32 security obligations

Article 4(12) breaches are evidence that a controller's Article 32 security measures were, at minimum, insufficient to prevent the specific incident. However, the CJEU made clear in Natsionalna agentsia za prihodite (C-340/21) that the occurrence of a breach does not, by itself, prove that the controller's security was "inappropriate" under Articles 24 and 32 GDPR. The Court held that GDPR "establishes a risk management system and that it in no way purports to eliminate the risks of personal data breaches" — controllers are required to implement security "appropriate to the risk," not to guarantee absolute prevention. Supervisory authorities assess whether the controller's pre-breach security measures were reasonable given the state of the art, the costs of implementation, and the nature of the data, and whether the controller responded appropriately once the breach occurred. A breach that results from a zero-day exploit against a fully patched system may not trigger Article 32 liability; a breach caused by failure to apply known security patches or to encrypt sensitive data typically will.

Awareness and the start of notification obligations

A controller becomes subject to the Article 33(1) 72-hour notification clock when it becomes "aware" of a personal data breach. The EDPB Guidelines 9/2022 define awareness as occurring "when that controller has a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised." Awareness does not require forensic certainty about the full scope or impact; it means the controller has sufficient information to conclude that a breach under Article 4(12) has taken place. For example, discovering that a misconfigured cloud storage bucket containing customer data was publicly accessible for six months triggers awareness, even if the controller does not yet know whether any unauthorized person actually accessed the data — the "unauthorised … access to" element of Article 4(12) is satisfied by the fact that access was possible without authorization.

Controllers must implement monitoring and logging under Article 32(1)(d) GDPR ("a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing") to ensure that they become aware of breaches promptly. A controller that lacks logging and only discovers a breach months later when a data subject reports fraudulent use of their data may face compounded penalties: a fine for inadequate security under Article 32 (subject to Article 83(4)(a), €10 million or 2% of turnover) and a separate fine for late notification under Article 33 (same tier), in addition to potential Article 34 data-subject notification failures.

Source: Regulation (EU) 2016/679 (GDPR), Article 4(12), Articles 32, 33, Recital 85 Source: CJEU Judgment, Case C-340/21, Natsionalna agentsia za prihodite, 14 December 2023 Source: EDPB Guidelines 9/2022 on personal data breach notification under GDPR, version 2.0, adopted 4 April 2023 Source: EDPB Guidelines 01/2021 on Examples regarding Personal Data Breach Notification, adopted 14 December 2021

Article 33(1) of the General Data Protection Regulation (Regulation (EU) 2016/679) imposes a strict timeline on controllers: in the case of a personal data breach, the controller must notify the competent supervisory authority "without undue delay and, where feasible, not later than 72 hours after having become aware of it," unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. The 72-hour clock starts when the controller becomes "aware" — not when the incident first occurred, nor when a full forensic investigation has concluded.

What constitutes "awareness"?

The European Data Protection Board (EDPB) clarified in Guidelines 9/2022 (version 2.0, adopted April 2023) that a controller becomes aware when it has "a reasonable degree of certainty that a security incident has occurred and led to personal data being compromised." Awareness does not require complete information about the scope or impact; it means the controller has sufficient evidence to conclude that a breach happened. For example, confirming that a database was publicly accessible and contained personal data triggers awareness, even if the full extent of unauthorized access remains under investigation.

The "unlikely to result in a risk" exemption

Notification is mandatory unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. This is a risk-to-individuals test, not a reputational or business-impact test. Recital 85 GDPR lists factors controllers should consider: the nature, sensitivity, and volume of personal data; ease of identification; severity of potential consequences (e.g., identity theft, financial loss, discrimination); and any safeguards already in place (such as encryption rendering the data unintelligible). A breach of encrypted data where the controller holds the key separately, for instance, may still pose a risk; a breach of data encrypted with a key the attacker cannot access may not.

The EDPB stresses that controllers must document the reasoning behind every decision not to notify, because supervisory authorities can inspect breach registers under Article 33(5) to verify that the exemption was appropriately applied.

Notification content — Article 33(3) mandatory elements

When notification is required, Article 33(3) mandates that the controller provide at minimum:

• A description of the nature of the breach, including where possible the categories and approximate number of data subjects concerned and the categories and approximate number of personal data records concerned;
• The name and contact details of the data protection officer (or other contact point);
• A description of the likely consequences of the breach; and
• A description of measures taken or proposed to address the breach and mitigate its adverse effects.

Phased notification — Article 33(4)

GDPR recognizes that controllers will rarely have complete forensic detail within 72 hours. Article 33(4) permits notification "in phases without undue further delay" when it is not possible to provide all the information at the same time. Controllers should submit an initial notification within 72 hours containing whatever is known, then update the supervisory authority as the investigation progresses. The EDPB recommends flagging in the initial submission which elements are provisional and when updates will follow.

Late notification and reasons for delay — Article 33(1)

If the 72-hour deadline is missed, Article 33(1) requires that the notification be "accompanied by reasons for the delay." Supervisory authorities (including CNIL, ICO post-Brexit under the parallel UK GDPR, and others) have accepted justifications such as complex cross-border forensic investigations, weekend timing affecting incident-response availability, or coordination across multiple joint controllers. Unexplained delay, however, exposes the controller to administrative fines under Article 83(4)(a), which caps at €10 million or 2% of total worldwide annual turnover, whichever is higher.

Processor obligations — Article 33(2)

Processors have a parallel duty under Article 33(2): they must notify the controller "without undue delay after becoming aware of a personal data breach." The GDPR does not specify a numeric deadline for processor-to-controller notification, but the EDPB Guidelines recommend that processors notify promptly — typically within 24 to 48 hours in practice under modern data processing agreements — to give the controller time to meet the 72-hour authority deadline. A processor that delays notifying the controller and thereby causes the controller to miss the 72-hour window can face its own enforcement action under Article 83(4)(a).

Documentation obligation — Article 33(5)

Article 33(5) requires controllers to document every personal data breach, whether notified to the authority or not. The documentation must comprise "the facts relating to the personal data breach, its effects and the remedial action taken," and must enable the supervisory authority to verify compliance with Article 33. This breach register is a core artifact during supervisory audits and enforcement investigations.

Which supervisory authority receives the notification?

Under Article 55 GDPR, the competent supervisory authority is the lead supervisory authority where the controller has its main or single establishment in the EU, or the authority of the Member State where the breach occurred if the controller has no EU establishment but falls under Article 3(2) territorial scope. Each EU Member State supervisory authority operates its own online breach notification portal; controllers should identify the correct portal in advance as part of incident-response planning.

Source: Regulation (EU) 2016/679 (GDPR), Articles 33, 55, 83, Recital 85 Source: EDPB Guidelines 9/2022 on personal data breach notification under GDPR, version 2.0

Article 34(1) of the General Data Protection Regulation (Regulation (EU) 2016/679) requires controllers to communicate a personal data breach directly to affected data subjects "when the personal data breach is likely to result in a high risk to the rights and freedoms of natural persons." This obligation is distinct from, and additional to, the Article 33 duty to notify the supervisory authority. The threshold for data-subject notification is deliberately higher: Article 33 mandates authority notification when a breach is likely to result in a "risk," whereas Article 34 triggers only when the breach is likely to result in a "high risk."

The "high risk" threshold — more severe than Article 33's "risk"

The European Data Protection Board (EDPB) clarified in Guidelines 9/2022 (version 2.0, adopted April 2023) that "the threshold for communicating a breach to individuals is therefore higher than for notifying supervisory authorities and not all breaches will therefore be required to be communicated to individuals, thus protecting them from unnecessary notification fatigue." A breach may require supervisory-authority notification under Article 33 but not data-subject communication under Article 34 if the risk level does not cross into "high risk."

Recital 85 GDPR states that a breach is likely to result in high risk "where the breach could lead to physical, material or non-material damage such as loss of control over his or her personal data or limitation of his or her rights, discrimination, identity theft or fraud, financial loss, unauthorised reversal of pseudonymisation, damage to reputation, loss of confidentiality of personal data protected by professional secrecy or any other significant economic or social disadvantage to the natural person concerned." The EDPB's Guidelines 9/2022 list factors to assess high risk: the type of breach (confidentiality, integrity, or availability), the nature, sensitivity, and volume of personal data, the ease of identification, the severity of consequences for individuals, and the special characteristics of the data subjects (children, employees, vulnerable persons). Breaches of special-category data under Article 9(1) — such as health data, biometric data, or data revealing racial or ethnic origin — are more likely to cross the high-risk threshold, though not automatically; the EDPB notes that the compromise of certain ordinary personal data can also present high risk if the combination or context heightens the threat of identity theft, fraud, or significant harm.

Timing — "without undue delay," no numeric deadline

Article 34(1) requires that communication be made "without undue delay," but the GDPR does not specify a numeric deadline as it does for supervisory-authority notification (72 hours). The EDPB Guidelines 9/2022 state that "without undue delay" means "as soon as possible" — controllers should communicate to data subjects as soon as they have assessed that the breach is likely to result in high risk and have gathered sufficient information to provide a meaningful, actionable notification. Recital 87 GDPR emphasizes that "the fact that the notification was made without undue delay should be established taking into account in particular the nature and gravity of the personal data breach and its consequences and adverse effects for the data subject."

The policy rationale for immediate communication is that affected individuals may need to take protective steps — changing passwords, monitoring financial accounts, placing fraud alerts — and delay in notifying them increases the window for harm to materialize. Unlike supervisory-authority notification, where phased updates are common, data-subject communication should be made once the controller has a clear understanding of the high risk and actionable mitigation advice to offer.

Mandatory content — Article 34(2)

Article 34(2) specifies that the communication must "describe in clear and plain language the nature of the personal data breach and contain at least the information and measures referred to in points (b), (c) and (d) of Article 33(3)." This cross-reference means controllers must include:

• The name and contact details of the data protection officer or other contact point (Article 33(3)(b));
• A description of the likely consequences of the breach (Article 33(3)(c)); and
• A description of the measures taken or proposed to address the breach, including where appropriate measures to mitigate its possible adverse effects (Article 33(3)(d)).

The EDPB Guidelines 9/2022 emphasize that the communication should provide "specific advice to individuals to protect themselves," such as recommending password resets, credit-monitoring enrollment, or steps to secure accounts. The language must be "clear and plain" — jargon-free and intelligible to the general public, particularly when the notification is addressed to children or other vulnerable groups. Controllers may not rely on legalistic boilerplate; the notification must explain this breach and these consequences in concrete, accessible terms.

Three statutory exemptions — Article 34(3)

Article 34(3) carves out three circumstances in which data-subject notification is not required, even when the breach meets the high-risk threshold:

1. Technical protection rendering data unintelligible (Article 34(3)(a)): The controller need not notify data subjects if "the controller has implemented appropriate technical and organisational protection measures, and those measures were applied to the personal data affected by the personal data breach, in particular those that render the personal data unintelligible to any person who is not authorised to access it, such as encryption." The canonical example is a breach of data encrypted with AES-256 where the attacker did not obtain the decryption key. The EDPB Guidelines clarify that controllers must understand how their encryption product functions — some devices are encrypted only when powered off, not in standby mode; some encryption systems have default keys that must be changed to be effective. The exemption applies only if the encryption was genuinely robust and the key remained secure.

1. Subsequent measures eliminating high risk (Article 34(3)(b)): Notification is not required if "the controller has taken subsequent measures which ensure that the high risk to the rights and freedoms of data subjects referred to in paragraph 1 is no longer likely to materialise." For example, if an attacker exfiltrated a customer database but the controller immediately invalidated all affected credentials and forced password resets, the risk of account compromise may be eliminated. The burden is on the controller to demonstrate that the remediation was swift and effective.

1. Disproportionate effort (Article 34(3)(c)): Notification is excused if "it would involve disproportionate effort." In such cases, Article 34(3)(c) mandates "a public communication or similar measure whereby the data subjects are informed in an equally effective manner." The EDPB interprets this narrowly: disproportionate effort typically arises when the controller lacks current contact details for a large population of affected individuals, not when notification is merely expensive or reputationally damaging. The public communication must be prominent, specific, and accessible — a press release buried on page five of a corporate website will not suffice; the EDPB recommends homepage banners, dedicated breach-notification pages, and media outreach to reach the affected population.

Supervisory-authority power to compel notification — Article 34(4)

Article 34(4) grants supervisory authorities the power to order data-subject notification even when the controller has not done so voluntarily. The provision states: "If the controller has not already communicated the personal data breach to the data subject, the supervisory authority, having considered the likelihood of the personal data breach resulting in a high risk, may require it to do so or may decide that any of the conditions referred to in paragraph 3 are met." Conversely, the authority may conclude that one of the Article 34(3) exemptions applies and that notification is not required. This supervisory override prevents controllers from unilaterally withholding notification when the authority's risk assessment differs.

Enforcement consequences — Article 83(4)(a)

Failure to communicate a breach to data subjects in violation of Article 34 is subject to administrative fines under Article 83(4)(a) GDPR, which caps fines at €10 million or 2% of total worldwide annual turnover, whichever is higher. The EDPB Guidelines 9/2022 note that "in some cases, the failure to notify a breach could reveal either an absence of existing security measures or an inadequacy of the existing security measures," which can trigger separate sanctions under Article 32 (security of processing, subject to the higher Article 83(5) fine tier of €20 million or 4%). A controller that both fails to secure data and fails to notify affected individuals after the breach can face cumulative penalties.

Cross-border breaches and which data subjects to notify

When a breach affects data subjects across multiple EU Member States, the controller notifies the lead supervisory authority under Article 56 GDPR (the one-stop-shop mechanism) but must communicate the breach to all affected data subjects, regardless of where they reside in the EU or EEA. The obligation runs to individuals, not to national authorities. If the controller lacks current contact information for some affected individuals, the disproportionate-effort exemption and public-communication alternative under Article 34(3)(c) become relevant.

How to communicate — modalities under Article 12

Article 34(2) incorporates by reference the transparency requirements of Article 12 GDPR. Communication should be in writing (email, postal letter, secure account notification) or, where appropriate, by electronic means. If the controller knows that a data subject prefers a particular communication channel, it should use that channel where feasible. The communication must be free of charge to the data subject. Controllers may not condition notification on the data subject's acceptance of terms or payment of a fee.

Source: Regulation (EU) 2016/679 (GDPR), Articles 34, 33(3), 12, 83, Recitals 85, 87 Source: EDPB Guidelines 9/2022 on personal data breach notification under GDPR, version 2.0, adopted 4 April 2023

Article 33(5) of the General Data Protection Regulation (Regulation (EU) 2016/679) imposes a universal documentation obligation on controllers that is independent of the Article 33(1) notification duty and applies to every personal data breach, whether notified to the supervisory authority or not. The provision states: "The controller shall document any personal data breaches, comprising the facts relating to the personal data breach, its effects and the remedial action taken. That documentation shall enable the supervisory authority to verify compliance with this Article."

This breach register (also called a breach log or breach documentation system) is a core accountability artifact under GDPR. Controllers must maintain it continuously, and supervisory authorities routinely inspect it during audits to verify that the controller is identifying breaches, assessing risk correctly, and documenting the rationale for every decision not to notify.

What must be documented — the three statutory elements

Article 33(5) mandates that the breach register contain three categories of information for each breach:

1. The facts relating to the personal data breach: This includes a description of the nature of the breach (confidentiality, integrity, or availability incident), the date and time the breach occurred (if known) and the date and time the controller became aware of it, the categories and approximate number of data subjects concerned, the categories and approximate number of personal data records affected, the cause or suspected cause of the breach, and the systems or datasets involved. The European Data Protection Board (EDPB) emphasized in Guidelines 9/2022 (version 2.0, adopted April 2023) that controllers should record "a reasonable degree of certainty" about what happened, even when a full forensic investigation is ongoing.

1. Its effects: Controllers must document the actual or likely consequences of the breach for affected individuals and for the controller's processing operations. This includes an assessment of the risk level (no risk, risk, or high risk under the Article 33/34 framework), the types of harm that could result (identity theft, financial loss, discrimination, reputational damage, physical harm, loss of control over personal data), and any known instances of harm that have already materialized. The EDPB's Guidelines 01/2021 on breach notification examples stress that even when a breach is determined to be "unlikely to result in a risk" and therefore not notified, the controller must still document why the breach was assessed as low-risk — the reasoning and the factors considered.

1. The remedial action taken: This includes immediate containment measures (e.g., shutting down affected systems, revoking compromised credentials, patching vulnerabilities), investigative steps (forensic analysis, log reviews, third-party security assessments), notification actions (supervisory authority notification under Article 33(1), data subject communication under Article 34(1), or a documented decision not to notify and the reasons), and longer-term improvements to prevent recurrence (policy updates, technical safeguards, staff training). The EDPB notes that supervisory authorities use this element to assess whether the controller responded appropriately and whether the breach revealed underlying deficiencies in the controller's Article 32 security measures.

Scope — "any personal data breaches" means every incident

The obligation applies to all breaches, without exception. The EDPB's SME guidance on data breaches states: "In any event, for all breaches — even those that are not notified to a DPA, on the basis that they have been assessed as being unlikely to result in a risk — the data controller must record at least the basic details of the breach, the assessment thereof, its effects, and the steps taken in response, as required by Art. 33(5) GDPR."

This universality has practical significance. Many controllers document only the breaches they notify to the supervisory authority, reasoning that undocumented non-notified incidents cannot be proven. Supervisory authorities reject this approach: when an audit or investigation uncovers evidence of a breach (e.g., logs showing unauthorized access, complaints from affected individuals, or forensic traces of an attack), the absence of a corresponding breach-register entry is itself a violation of Article 33(5), regardless of whether the breach should have been notified under Article 33(1).

The EDPB Guidelines 01/2021 illustrate this with numerous examples. For instance, Example Case 01 (ransomware attack with full backup and encryption) concludes that no supervisory-authority notification is required and no data-subject communication is required, but explicitly states: "However, as all data breaches, it should be documented in accordance with Article 33(5)." The same pattern repeats across all 18 case studies — documentation is mandatory in every scenario.

Purpose — enabling supervisory-authority verification of compliance

The second sentence of Article 33(5) specifies that the documentation "shall enable the supervisory authority to verify compliance with this Article" (i.e., with Article 33 as a whole). This means the breach register must contain sufficient detail for a supervisory authority to:

• Confirm that the controller is detecting breaches (not ignoring security incidents or treating them as purely technical IT problems);
• Review the controller's risk assessments and verify that the "unlikely to result in a risk" exemption under Article 33(1) was applied correctly for non-notified breaches;
• Check that notifications under Article 33(1) were made within 72 hours or accompanied by documented reasons for delay;
• Assess whether the controller conducted adequate investigations and took appropriate remedial measures; and
• Determine whether a pattern of breaches reveals systemic deficiencies in the controller's Article 32 security posture.

The EDPB Guidelines 9/2022 state that the breach register "assists the controller in demonstrating accountability to the supervisory authority, which may ask to see those records" (paragraph 24, footnote 19). Supervisory authorities commonly request the breach register as the first document during on-site inspections, desk-based audits, and enforcement investigations following a major breach.

Format and retention

GDPR does not prescribe a specific format for the breach register. Controllers may maintain it as a spreadsheet, a database, a dedicated breach-management software platform, or a written log. The EDPB recommends that the register be searchable and allow the controller to generate reports showing all breaches within a specified period, all breaches affecting a particular category of data, or all breaches where notification was not made.

GDPR does not specify a retention period for breach register entries. Most supervisory authorities recommend retaining entries for at least the duration of the processing activity to which the breach relates, or for the applicable statute-of-limitations period for GDPR enforcement actions (which varies by Member State but is typically three to five years). Controllers subject to other regulatory regimes (e.g., NIS2 Directive for essential and important entities, ePrivacy Directive for electronic communications providers, DORA for financial entities) may face longer retention requirements.

Enforcement — Article 83(4)(a) fines and compounded violations

Failure to maintain adequate breach documentation is subject to administrative fines under Article 83(4)(a) GDPR, which caps fines at €10 million or 2% of total worldwide annual turnover, whichever is higher. This is the same fine tier that applies to failure to notify the supervisory authority under Article 33(1) and failure to communicate to data subjects under Article 34(1).

In January 2022, the Commission Nationale de l'Informatique et des Libertés (CNIL), France's supervisory authority, fined the telecommunications operator FREE €300,000 for multiple violations including "failure to comply with the obligation to document a personal data breach (Article 33 of the GDPR)," in combination with failures under Articles 15, 21, and 32. The decision (publicly noted on the EDPB website in a 2022 national-news item) demonstrates that breach-register deficiencies are enforced in practice, not merely in principle.

More commonly, Article 33(5) failures surface during enforcement investigations triggered by a notified or discovered breach. When a supervisory authority investigates a major breach and finds that the controller's breach register is absent, incomplete, or shows that prior breaches were misclassified and not notified, the authority often issues compounded penalties: a fine for the failure to notify the current breach under Article 33(1), a fine for inadequate security under Article 32 (subject to the higher Article 83(5) tier of €20 million or 4%), and a separate finding under Article 33(5) for the deficient register. The EDPB Guidelines 9/2022 note that "the failure to notify a breach could reveal either an absence of existing security measures or an inadequacy of the existing security measures," leading to cumulative sanctions.

Relationship to the data protection officer and accountability principle

Where a controller has designated a data protection officer (DPO) under Article 37 GDPR, the DPO typically oversees the breach register as part of the DPO's Article 39 tasks — monitoring compliance with GDPR, advising on data protection impact assessments, and cooperating with the supervisory authority. The EDPB Guidelines 9/2022 recommend that controllers involve the DPO in breach response from the moment awareness is established, both to ensure timely notification and to ensure accurate documentation.

The breach register is a manifestation of the Article 5(2) accountability principle: the controller must be able to demonstrate compliance with GDPR's processing principles. A controller that cannot produce a documented history of breaches, risk assessments, and remedial actions when requested by a supervisory authority fails the accountability standard, even if no individual breach triggered a notification requirement.

Processor obligations

Processors are not directly subject to the Article 33(5) documentation requirement (the provision addresses controllers), but processors commonly maintain their own internal incident logs to fulfill the Article 33(2) duty to notify the controller "without undue delay after becoming aware of a personal data breach." Many controllers, through Article 28 data processing agreements, contractually require processors to document breaches and share those records upon request, mirroring the controller's own obligation.

Source: Regulation (EU) 2016/679 (GDPR), Articles 33, 83, Recital 85 Source: EDPB Guidelines 9/2022 on personal data breach notification under GDPR, version 2.0, adopted 4 April 2023 Source: EDPB Guidelines 01/2021 on Examples regarding Personal Data Breach Notification Source: EDPB SME guide on data breaches Source: CNIL enforcement decision against FREE — €300,000 fine for breach-documentation failure, Art. 33 GDPR (EDPB national-news summary, 2022)

When a personal data breach affects data subjects in multiple EU or EEA Member States, a critical procedural question arises: which supervisory authority must the controller notify under Article 33(1) GDPR? Article 56 GDPR provides the answer through the one-stop-shop (OSS) mechanism, which designates a lead supervisory authority (LSA) as the controller's single point of contact for cross-border processing activities, including breach notification. This mechanism is designed to spare controllers from having to notify every supervisory authority in every Member State where affected data subjects reside, and to ensure consistent enforcement across the EU.

The one-stop-shop rule — Article 56(1) GDPR

Article 56(1) GDPR establishes that "the supervisory authority of the main establishment or of the single establishment of the controller or processor shall be competent to act as lead supervisory authority for the cross-border processing carried out by that controller or processor in accordance with the procedure provided in Article 60." Article 56(6) further states: "The lead supervisory authority shall be the sole interlocutor of the controller or processor for the cross-border processing carried out by that controller or processor."

For breach notification purposes, this means that a controller with an EU establishment notifies only its lead supervisory authority, even when the breach affects data subjects across fifteen or twenty Member States. The lead supervisory authority then coordinates with the other "supervisory authorities concerned" (those of Member States where data subjects are substantially affected or where the controller has an establishment) under the Article 60 cooperation procedure. The controller does not submit parallel breach notifications to each national authority — it submits one notification to the LSA, which shares relevant information with concerned supervisory authorities through the EU's Internal Market Information (IMI) system.

Determining the lead supervisory authority — Article 4(16) main establishment

The LSA is determined by identifying the controller's main establishment in the EU or EEA. Article 4(16) GDPR defines "main establishment" as:

• (a) For a controller with establishments in more than one Member State: the place of its central administration in the Union, unless the decisions on the purposes and means of the processing of personal data are taken in another establishment of the controller in the Union and the latter establishment has the power to have such decisions implemented, in which case that other establishment is the main establishment.

• (b) For a processor with establishments in more than one Member State: the place of its central administration in the Union, or if it has no central administration in the Union, the establishment where the main processing activities take place.

Recital 36 GDPR clarifies that "main establishment" implies "the effective and real exercise of management activities determining the main decisions as to the purposes and means of processing through stable arrangements." The European Data Protection Board (EDPB) emphasized in Guidelines 8/2022 on identifying a controller or processor's lead supervisory authority (adopted October 10, 2022) that the controller's registered headquarters or legal domicile is not automatically the main establishment. Instead, supervisory authorities look for where the substantive data-protection decisions are made — typically where the Chief Privacy Officer, Data Protection Officer, or equivalent decision-makers are located, where the processing infrastructure is controlled, and where the authority to implement those decisions resides.

In February 2024, the EDPB adopted Opinion 04/2024 on the notion of main establishment, further clarifying that the place of central administration is presumptively the main establishment unless the controller can demonstrate that another EU establishment exercises the real decision-making authority over processing purposes and means. This assessment is fact-specific and may shift over time; controllers must document their organizational structure, data-governance frameworks, and internal decision-making processes to substantiate their main-establishment designation.

Cross-border processing — when does the one-stop-shop apply?

The one-stop-shop applies only to cross-border processing as defined in Article 4(23) GDPR. Processing is cross-border if it:

• (a) takes place in the context of the activities of establishments in more than one Member State of a controller or processor, where the controller or processor is established in more than one Member State; or

• (b) takes place in the context of the activities of a single establishment of a controller or processor in the Union but which substantially affects or is likely to substantially affect data subjects in more than one Member State.

A personal data breach involving a controller established only in Germany but affecting customers in Germany, France, Italy, and Spain is cross-border under Article 4(23)(b) — it arises from a single establishment but substantially affects data subjects in multiple Member States. The controller notifies the German supervisory authority (its LSA), which coordinates with the French CNIL, the Italian Garante, and the Spanish AEPD as concerned supervisory authorities.

Conversely, if a breach affects only data subjects residing in the same Member State where the controller has its main establishment and does not involve establishments in other Member States, the processing is not cross-border, and the one-stop-shop does not apply. The controller notifies the local supervisory authority under Article 55 GDPR's general territorial-competence rule.

The Article 56(2) local-processing exception

Article 56(2) GDPR carves out a derogation: "By derogation from paragraph 1, each supervisory authority shall be competent to handle a complaint lodged with it or a possible infringement of this Regulation, if the subject matter relates only to an establishment in its Member State or substantially affects data subjects only in its Member State." This provision allows a local supervisory authority to assert competence even when the controller has a lead supervisory authority elsewhere, if the subject matter is purely local.

For breach notification initiated by the controller (as opposed to a data-subject complaint), the EDPB's Guidelines 9/2022 on personal data breach notification (version 2.0, adopted April 4, 2023) confirm that Article 56(2) rarely applies. A controller assessing whether a breach is cross-border looks to the data subjects affected: if the breach substantially affects individuals in multiple Member States, the controller notifies the LSA under Article 56(1). Article 56(2) is primarily relevant when a local supervisory authority receives a complaint or discovers a breach that, upon investigation, affects only data subjects in that authority's Member State. In such cases, Article 56(3) requires the local authority to inform the LSA, and Article 56(3) grants the LSA three weeks to decide whether to handle the case under the Article 60 cooperation procedure or to leave it with the local authority.

Controllers without an EU establishment — no one-stop-shop

The EDPB clarified in Guidelines 9/2022 and Guidelines 8/2022 that controllers not established in the EU but subject to GDPR under Article 3(2) (offering goods or services to EU data subjects, or monitoring their behavior) cannot benefit from the one-stop-shop. Article 3(2) controllers have no main establishment in the EU, and Article 56 requires an establishment to determine a lead supervisory authority.

For such controllers, the EDPB's updated Guidelines 9/2022 (paragraph 121) state unequivocally: "If the controller has no establishment in the Union, the one-stop-shop mechanism does not apply… the controller must notify the supervisory authority in each Member State where data subjects affected by the breach are located." This can result in parallel notifications to ten or more national authorities within the 72-hour Article 33(1) deadline — a significant compliance burden, but an unavoidable one under the current GDPR framework.

Controllers subject to Article 3(2) and required to designate an Article 27 representative in the EU sometimes ask whether they can notify only the representative's supervisory authority. The EDPB's Guidelines 8/2022 (paragraph 38) reject this approach: "The appointment of a representative… does not result in the controller or processor benefiting from the one-stop-shop mechanism." The representative facilitates communication and can receive enforcement notices on the controller's behalf, but does not confer LSA status on the representative's supervisory authority. Controllers must identify the Member States where affected data subjects reside and notify each national authority individually. Many non-EU controllers use the representative to coordinate simultaneous submissions or engage external counsel to file in parallel, but the legal obligation runs to each authority separately.

Joint controllers and the one-stop-shop

The EDPB's Guidelines 9/2022 clarify that joint controllers cannot agree on a single common main establishment. Each joint controller is assessed individually to determine its own main establishment and lead supervisory authority. If joint controllers suffer a breach that is notifiable under Article 33, each controller must notify the breach to its respective lead supervisory authority (or to the local authority if the controller has only one EU establishment or no EU establishment). The EDPB explained in the October 2022 draft Guidelines on identifying the LSA (adopted as final Guidelines 8/2022 in December 2022) that joint controllership is a processing arrangement, not a corporate merger — each entity retains its own supervisory relationship.

This has practical implications for breach notification. For example, a social-media platform and an event organizer acting as joint controllers for a jointly organized marketing campaign must, upon discovering a breach of the jointly controlled dataset, each assess whether the breach triggers Article 33 notification based on its own awareness timeline, and each notify its own lead supervisory authority (or authorities, if non-EU). The two controllers may coordinate their notifications for consistency, but they cannot delegate the notification to one controller acting on behalf of both.

The Article 60 cooperation procedure — what happens after notification

Once a controller notifies its lead supervisory authority of a cross-border breach, Article 60 GDPR governs the cooperation between the LSA and supervisory authorities concerned. The LSA drafts any enforcement decision (for example, a finding that the breach was caused by inadequate Article 32 security measures, or that the controller improperly delayed notification beyond 72 hours), shares the draft with concerned supervisory authorities, and seeks to reach consensus. Concerned supervisory authorities may submit "relevant and reasoned objections" under Article 60(4), triggering extended deliberation or, if consensus cannot be reached, referral to the EDPB under Article 65 for a binding decision.

For the controller, the critical procedural point is that the LSA remains the sole interlocutor throughout. The controller does not negotiate separately with each concerned supervisory authority. Concerned authorities may request additional information through the LSA, and the controller should respond through the LSA. The EDPB's contribution to the GDPR evaluation (December 2023) notes that between May 25, 2018, and November 3, 2023, supervisory authorities registered 2,397 cross-border case entries in the IMI system, and the LSA-CSA cooperation mechanism has been applied in hundreds of breach-notification cases, though data-breach cases represent only a subset of the total OSS caseload.

Practical identification of the LSA — pre-breach planning

Controllers should identify their lead supervisory authority and register their main establishment before a breach occurs. Most EU Member State supervisory authorities operate public registers of controllers and maintain guidance on LSA determination. The EDPB published a one-stop-shop leaflet (June 2021) and maintains a publicly accessible register of Article 60 final decisions, which includes breach-notification decisions and can help controllers understand how supervisory authorities apply Article 56 in practice. As of June 2020, the EDPB reported 110 final OSS decisions; by December 2023, that number had grown substantially, with a dedicated case digest on security of processing and data breach notification published by the EDPB Support Pool of Experts program.

Controllers uncertain about their LSA should consult the supervisory authority they believe is competent and request confirmation. If the authority disagrees, it will coordinate with other authorities under Article 56(3)-(5) to resolve the question. Identifying the wrong LSA does not void a breach notification — the receiving authority will forward it to the correct LSA under the mutual-assistance framework in Article 61 GDPR — but it can delay the 72-hour clock and expose the controller to criticism for inadequate incident-response preparation.

Article 55(2) exception — public authorities acting under Article 6(1)(c) or (e)

Article 55(2) GDPR provides that "where processing is carried out by public authorities or private bodies acting on the basis of point (c) or (e) of Article 6(1)" — legal obligation or public-interest task — "the supervisory authority of the Member State concerned shall be competent. In such cases Article 56 does not apply." This means that public-sector controllers relying on Article 6(1)(c) or (e) as their lawful basis notify their national supervisory authority under Article 55(2), not a lead supervisory authority, even if the breach is cross-border in scope. The rationale, articulated in Recital 125 GDPR, is that supervision of public-authority processing is best conducted by the authority of the Member State where the public body is established, to preserve accountability to national democratic structures.

This exception has limited application to commercial controllers, but multinational groups with public-sector subsidiaries (e.g., a state-owned airline or a public research institution within a larger conglomerate) must assess whether Article 55(2) applies to the processing in question. The CJEU has not yet ruled on whether a private controller acting under a public-interest mandate (Article 6(1)(e)) falls within Article 55(2), and supervisory authorities have taken varying views.

Post-Brexit and EEA considerations

The United Kingdom left the EU on January 31, 2020, and the transition period ended December 31, 2020. The UK GDPR (retained EU law as amended by the Data Protection Act 2018 and the Data Protection, Privacy and Electronic Communications (Amendments etc.) (EU Exit) Regulations 2019) no longer participates in the Article 56 one-stop-shop mechanism. UK controllers with an EU establishment determine their EU LSA under Article 56 GDPR for EU processing, and notify the UK Information Commissioner's Office separately for UK-resident data subjects under the parallel UK GDPR breach-notification rule (UK GDPR Article 33, which mirrors EU GDPR Article 33 but operates independently). Conversely, EU controllers whose breach affects UK data subjects must assess whether UK GDPR applies (it does if the controller offers goods or services to UK individuals or monitors their behavior, under UK GDPR Article 3(2)) and, if so, notify the ICO separately. The EU Commission's adequacy decision for the UK (Decision (EU) 2021/1772, adopted June 28, 2021, with a four-year sunset reviewed in 2025) facilitates cross-border transfers but does not restore UK participation in the LSA mechanism.

The EEA Agreement incorporates GDPR into the legal orders of Iceland, Liechtenstein, and Norway. Controllers established in EEA states participate fully in the Article 56 one-stop-shop, and the supervisory authorities of those states (the Icelandic Data Protection Authority, the Liechtenstein Data Protection Office, and the Norwegian Datatilsynet) are represented on the EDPB and cooperate through the IMI system. A controller with its main establishment in Norway and operations in Germany notifies the Norwegian Datatilsynet as its LSA for cross-border breaches affecting EEA data subjects.

Source: Regulation (EU) 2016/679 (GDPR), Articles 3, 4(16), 4(23), 33, 55, 56, 60, Recitals 36, 124, 125, 127 Source: EDPB Guidelines 9/2022 on personal data breach notification under GDPR, version 2.0, adopted April 4, 2023 Source: EDPB Guidelines 8/2022 on identifying a controller or processor's lead supervisory authority, adopted December 13, 2022 Source: EDPB Opinion 04/2024 on the notion of main establishment, adopted February 13, 2024

Article 33(2) of the General Data Protection Regulation (Regulation (EU) 2016/679) imposes a standalone notification obligation on processors that is distinct from—and temporally prior to—the controller's Article 33(1) duty to notify the supervisory authority. The provision states: "The processor shall notify the controller without undue delay after becoming aware of a personal data breach."

This processor-to-controller notification is the first link in the breach-notification chain. When a processor discovers a breach affecting personal data it processes on behalf of a controller, it must alert the controller so that the controller can evaluate whether the breach triggers the Article 33(1) 72-hour notification to the supervisory authority and the Article 34 high-risk communication to data subjects. A processor that delays notifying the controller can prevent the controller from meeting the 72-hour supervisory-authority deadline and thereby expose both the controller and the processor to enforcement action.

No numeric deadline — "without undue delay" means promptly, but GDPR does not specify hours

Unlike Article 33(1), which gives controllers a concrete 72-hour deadline (where feasible), Article 33(2) does not specify a numeric time limit for processors. The European Data Protection Board (EDPB) clarified in Guidelines 9/2022 on personal data breach notification (version 2.0, adopted April 2023, paragraph 45) that "the GDPR does not provide an explicit time limit within which the processor must alert the controller, except that it must do so 'without undue delay.'" The EDPB recommends that "the processor promptly notifies the controller, with further information about the breach provided in phases as more details become available."

The GDPR is silent on what "without undue delay" means in hours or days. The key statutory principle is that the processor must act quickly enough to preserve the controller's ability to meet the 72-hour supervisory-authority deadline under Article 33(1). Controllers commonly address this ambiguity in Article 28 data processing agreements by stipulating a specific notification timeline—often 24 or 48 hours—but such contractual deadlines do not replace or override the Article 33(2) regulatory duty. A contractual clause permitting the processor seven days to notify the controller would not excuse a delay that a supervisory authority concludes violated "without undue delay" in the circumstances of that breach.

"Becoming aware" — same trigger as Article 33(1) for controllers

The Article 33(2) clock starts when the processor "becomes aware" of the personal data breach. The EDPB's Guidelines 9/2022 state that awareness occurs "when that controller [or processor] has a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised." Awareness does not require forensic certainty about the full scope, the number of affected data subjects, or the root cause; it means the processor has sufficient evidence to conclude that a breach under Article 4(12) GDPR has taken place.

For example, a cloud service provider acting as a processor becomes aware of a breach when it confirms that a misconfigured database containing customer personal data was publicly accessible, even if the provider does not yet know whether any unauthorized person actually accessed the data. A payroll processor becomes aware when it discovers that an employee emailed a payroll file to an incorrect external recipient, even if the investigation into how many individuals' data were disclosed is ongoing. Processors may not delay notification to the controller until they have completed a full forensic report—awareness triggers the duty, and the Article 33(2) notification should be provided in phases as more information becomes available.

What the processor must communicate — factual details to enable the controller's risk assessment

Article 33(2) does not prescribe specific content for the processor-to-controller notification, unlike Article 33(3) GDPR, which lists mandatory elements for controller-to-supervisory-authority notification. However, the processor must provide enough detail for the controller to assess whether the breach is "unlikely to result in a risk" (Article 33(1) threshold for exemption from authority notification) or is "likely to result in a high risk" (Article 34 threshold for data-subject communication).

The EDPB's Guidelines 9/2022 (paragraphs 43–45) recommend that processors communicate:

• A description of the nature of the breach (confidentiality, integrity, or availability incident; whether involving unauthorized access, data loss, ransomware, accidental disclosure, etc.);
• The date and time the breach occurred (if known) and the date and time the processor became aware of it;
• The categories of personal data affected and, where possible, the categories and approximate number of data subjects concerned;
• The likely consequences of the breach and any immediate containment or remediation measures the processor has taken; and
• A point of contact within the processor organization for further information.

The Guidelines note (paragraph 45) that processors may not have complete information initially and should provide an initial notification "without undue delay" with the facts known at that time, then update the controller as the investigation progresses. This phased approach mirrors the Article 33(4) framework for controller-to-authority notification.

Why the processor may lack full context — and why the controller must investigate independently

A processor typically processes personal data on behalf of one or more controllers under Article 28 GDPR data processing agreements. The processor may not know the full business context, the sensitivity of the data to the controller's operations, or whether the controller holds backup copies that mitigate the breach's impact. The EDPB's Guidelines 9/2022 (paragraph 44) state: "The controller might also want to investigate the breach, as the processor might not be in a position to know all the relevant facts relating to the matter, for example, if a copy or backup of personal data destroyed or lost by the processor is still held by the controller. This may affect whether" the controller must notify the supervisory authority or data subjects.

For instance, a processor that suffers a ransomware attack and loses access to personal data may report a high-availability breach, but if the controller maintained an independent backup and can restore the data without service disruption, the controller's risk assessment may conclude that supervisory-authority notification is not required under the Article 33(1) "unlikely to result in a risk" exemption. The processor's notification gives the controller the factual basis to make that determination, but the controller bears the ultimate legal responsibility for the Article 33(1) and Article 34 compliance decisions.

Processor liability for late or missing notification — Article 83(4)(a) fines

Processors are directly subject to GDPR enforcement. Failure to notify the controller "without undue delay" in violation of Article 33(2) exposes the processor to administrative fines under Article 83(4)(a), which caps penalties at €10 million or 2% of total worldwide annual turnover, whichever is higher. This is the same fine tier that applies to controller failures under Article 33(1) (late or missing supervisory-authority notification) and Article 34 (failure to communicate to data subjects).

Article 83(4)(a) GDPR lists "the obligations of the controller and the processor pursuant to Articles 8, 11, 25 to 39 and 42 and 43" as subject to this penalty tier. Although Article 33 is not enumerated in that list, Article 83(4)(a) applies because Article 33(2) is an Article 28-related processor obligation (processors assist controllers in complying with notification duties under the Article 28(3)(f) framework), and because Recital 87 GDPR states that processors must notify controllers to enable controller compliance. Supervisory authorities have authority under Article 58(2) GDPR to issue fines for processor breaches of Article 33(2).

Contractual reinforcement under Article 28 data processing agreements

Article 28(3)(f) GDPR requires that the data processing agreement between controller and processor stipulate that the processor "assists the controller in ensuring compliance with the obligations pursuant to Articles 32 to 36," which includes the Article 33 breach-notification duties. Many controllers, recognizing that Article 33(2) does not specify a numeric deadline, incorporate explicit processor-notification timelines in their Article 28 contracts—commonly 24 hours, 48 hours, or "immediately upon discovery," depending on the sensitivity of the data.

These contractual deadlines are enforceable as contract terms (and may trigger indemnity or service-level-agreement penalties for breach of contract) in addition to the regulatory "without undue delay" standard. However, a contractual deadline more generous than what "without undue delay" means in a given context does not override the Article 33(2) statutory duty. The GDPR obligation is the floor.

Processors do not notify the supervisory authority or data subjects directly

Article 33(2) requires only that the processor notify the controller. The processor has no direct obligation under GDPR to notify the supervisory authority (that duty falls on the controller under Article 33(1)) or to communicate the breach to data subjects (that duty is the controller's under Article 34). The processor's role is to alert the controller and provide the factual information the controller needs to discharge those obligations.

In practice, controllers often contractually require processors to assist in drafting the Article 33(1) supervisory-authority notification and the Article 34 data-subject communication, and processors routinely provide technical details, forensic reports, and incident timelines to support those filings. Article 28(3)(f) GDPR's "assist the controller" language covers this cooperation. But the legal duty to notify the authority and communicate to data subjects remains with the controller.

Sub-processor chains and the cascade of notifications

When a processor engages a sub-processor under Article 28(2) or (4) GDPR, the same Article 33(2) duty applies at each tier. If a sub-processor becomes aware of a breach, it must notify the processor "without undue delay." The processor must then notify the controller "without undue delay." The EDPB Guidelines 9/2022 do not provide separate timing guidance for sub-processor-to-processor notification, but the principle is identical: each entity in the chain must act quickly enough to preserve the next entity's ability to comply with its own notification obligations, ultimately enabling the controller to meet the 72-hour Article 33(1) deadline.

Processors should ensure that Article 28(4) sub-processor contracts impose the same "without undue delay" notification obligation (and, ideally, a specific numeric deadline) on sub-processors. When a breach occurs three layers deep—sub-sub-processor to sub-processor to processor to controller—the cumulative delay across the chain can easily exhaust the controller's 72-hour window unless each link in the chain notifies within hours, not days.

Awareness obligations and monitoring — processors must implement Article 32 security to detect breaches

A processor can only notify the controller "without undue delay after becoming aware" if it has systems in place to become aware promptly. Article 32(1) GDPR requires both controllers and processors to implement "appropriate technical and organisational measures to ensure a level of security appropriate to the risk," including "the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services" under Article 32(1)(b) and "a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing" under Article 32(1)(d).

The EDPB's Guidelines 9/2022 (paragraph 42) state that "the ability to detect, address, and report a breach in a timely manner should be seen as essential elements" of Article 32 compliance. A processor that lacks adequate logging and monitoring and only discovers a breach months later when the controller receives complaints from data subjects has failed both Article 33(2) (late notification) and Article 32 (inadequate security). Supervisory authorities may impose separate penalties for each violation: Article 32 failures are subject to the higher Article 83(5) fine tier (€20 million or 4% of turnover), while Article 33(2) failures fall under Article 83(4)(a) (€10 million or 2%).

Source: Regulation (EU) 2016/679 (GDPR), Articles 33(2), 28(3)(f), 32, 83, Recital 87 Source: EDPB Guidelines 9/2022 on personal data breach notification under GDPR, version 2.0, adopted 4 April 2023