GDPR Articles 33 & 34: The 72-Hour Data Breach Notification Rule — A SaaS Developer's Complete Response Playbook

Post #869 in the sota.io EU Cyber Compliance Series

When a personal data breach occurs in your SaaS application, the GDPR clock starts immediately. Under Article 33, the controller must notify the competent supervisory authority within 72 hours of becoming aware of the breach. Under Article 34, when that breach is likely to result in a high risk to the rights and freedoms of natural persons, you must also notify the affected individuals — without undue delay, and without waiting for the supervisory authority to respond.

This is not a theoretical requirement. The largest fines under GDPR enforcement in 2024 and 2025 included violations related to late or missing breach notifications. The Swedish DPA fined a healthcare provider for failing to report a breach involving patient records within the 72-hour window. The Irish DPC imposed a penalty for a breach notification that omitted required content, rendering it legally deficient even though it was filed on time.

For SaaS developers, the challenge is practical: a breach can occur at any layer of your stack — at the infrastructure level, in your application code, in a third-party dependency, or through a misconfigured access control. Your 72-hour window counts from the moment you first become aware, regardless of where in your organization awareness first arose.

This guide explains what constitutes a reportable breach, what the 72-hour obligation actually requires (and what it does not), the full content required in an Article 33 notification, when you must also notify individuals under Article 34, and how processor chains (your upstream infrastructure provider, your DPA) affect the flow of obligations.

What Counts as a Reportable Breach

Article 4(12) GDPR 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."

Three categories of breach exist, and each triggers different risk assessments:

The GDPR does not require that a breach involve malicious actors. Accidental exposure counts. Sending a bulk email with recipients in CC instead of BCC is a personal data breach under Article 4(12) if it discloses email addresses of data subjects. Misconfiguring a cloud storage bucket to public is a breach the moment it occurs — even if no one accessed the data before you corrected it.

The notification threshold is not harm — it is risk. Article 33(1) requires notification unless "the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons." This is an affirmative determination that must be documented. If you cannot demonstrate that risk is unlikely, you must notify.

The 72-Hour Clock: When It Starts and What Stops It

When the Clock Starts

The 72-hour window begins "from the moment the controller becomes aware." The EDPB Guidelines 01/2021 clarify that a controller "should be regarded as having become aware when that controller has a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised."

This means:

• A SIEM alert that a database has been accessed by an unauthorised IP starts the clock — even if your investigation is incomplete
• A support ticket from a user saying "I can see another user's data in my account" starts the clock
• A threat intelligence notification from a third party that your credentials were found in a dark web dump starts the clock
• Your engineer discovering a publicly accessible storage bucket starts the clock

What does not stop the clock:

• Uncertainty about the exact scope of the breach
• Ongoing forensic investigation
• Legal review
• Management approval processes
• The fact that your Data Protection Officer is on holiday

The EDPB is explicit: you may notify with information available at the time and supplement later. Waiting until your investigation is complete is a violation of Article 33 if the investigation takes more than 72 hours.

"Without Undue Delay" vs. 72 Hours

Article 33(1) says notification should happen "without undue delay and, where feasible, not later than 72 hours after having become aware." The 72-hour limit is the outer boundary. If you have the information required to file a complete notification within 6 hours, you must not wait 71 hours.

The 72-hour window is also not extended by weekends or public holidays. A breach discovered at 23:00 on a Friday gives you until 23:00 on Monday — but your supervisory authority's portal and emergency contact procedures must accommodate this.

Content Required in an Article 33 Notification

Article 33(3) specifies five mandatory content elements. A notification that omits any of these is legally deficient and may constitute a separate violation.

Note on phased notification: Article 33(4) explicitly permits phased notification. If you cannot provide all required information within 72 hours, you may submit an initial notification with available information and supplement it "without undue delay" thereafter. The initial notification must include at minimum: the nature of the breach, contact details of the DPO or point of contact, and the fact that a full notification is forthcoming. Document each supplement with a timestamp.

A notification filed at hour 71 with incomplete information is preferable to a notification filed at hour 73. File first; supplement as your investigation develops.

Article 34: When You Must Also Notify Individuals

Notifying the supervisory authority (Article 33) and notifying affected individuals (Article 34) are separate obligations triggered by separate risk thresholds.

Article 34 threshold: "high risk to the rights and freedoms of natural persons."

This is a higher bar than Article 33. The factors that elevate a breach to "high risk" include:

• Sensitive categories of data exposed (Article 9 data: health, biometric, financial, sexual orientation, religion, political opinion)
• Financial harm risk (payment card data, bank account numbers, credentials that could enable account takeover)
• Identity theft risk (full name + government ID + date of birth combination)
• Large number of data subjects affected
• Vulnerable populations affected (children, medical patients)
• Publicly accessible data (the breach made personal data visible to unknown parties, not just one attacker)

Content of an Article 34 Individual Notification

Article 34(2) requires the notification to use clear, plain language and to contain:

1. The nature of the personal data breach
2. Contact details of the DPO or point of contact
3. The likely consequences of the breach
4. Measures taken or proposed to address the breach, including measures to mitigate possible adverse effects
5. Recommended protective actions for the individual (e.g., change your password, monitor your bank account, place a fraud alert)

What Article 34 does not require: Notification to individuals in three cases (Article 34(3)):

• The controller has implemented appropriate technical and organisational protection measures, particularly encryption, that render the data unintelligible to anyone not authorised to access it
• The controller has taken subsequent measures that ensure the high risk is no longer likely to materialise
• Individual notification would involve disproportionate effort — in which case the controller must make a public communication instead

The Controller-Processor Chain: Who Notifies Whom

Most SaaS developers operate in a controller-processor chain. As a SaaS company, you are typically the processor for your enterprise customers (who are controllers). Simultaneously, you are the controller for your own employees' personal data and for any data you collect directly from end users in a B2C context.

Article 33(2): The processor must notify the controller "without undue delay" after becoming aware of a personal data breach. The GDPR does not specify a time limit for processor-to-controller notification, but the EDPB and most DPAs expect this to happen within 24 to 36 hours, giving the controller sufficient time to assess and file their 72-hour notification.

Your Data Processing Agreement (DPA) under Article 28 should specify:

• The maximum time within which you as processor will notify the controller (typically 24 hours or "without undue delay")
• The information you will provide in the initial notification
• Your commitment to cooperate with the controller's investigation
• Your obligations to preserve forensic evidence

If your DPA does not contain these provisions, you have an Article 28 gap — separate from any Article 33 obligation.

When you are the controller: If you are a B2C SaaS and the breach affects your own users' personal data, you are the controller and you file the Article 33 notification directly to your lead supervisory authority.

Lead supervisory authority: For SaaS companies with cross-border processing in the EU, the lead supervisory authority is the DPA of the Member State where your main EU establishment is located (Article 56 GDPR). If you are established only in one Member State, that DPA is your authority. If you have no EU establishment, any Member State DPA where your users are located can act.

The Encryption Safe Harbour

If personal data was breached but was properly encrypted at rest and in transit, and the encryption key was not compromised, the practical risk to data subjects is substantially reduced. Article 34(3)(a) explicitly recognises this: you are not required to notify individuals if you "have 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."

This does not eliminate your Article 33 obligation to notify the supervisory authority. The supervisory authority still needs to know that a breach occurred. The encryption safe harbour only affects the Article 34 obligation to notify individuals.

Standards that satisfy the safe harbour:

• AES-256 encryption with keys not stored alongside data
• Properly salted, high-cost password hashing (bcrypt with cost ≥12, Argon2id)
• End-to-end encryption where keys are never accessible to the provider

Standards that do not satisfy the safe harbour:

• Outdated hashing algorithms (MD5, SHA-1 unsalted)
• Encryption with keys stored in the same compromised environment
• Row-level encryption where the database admin key was also compromised

Document your encryption implementation in your Records of Processing Activities (ROPA) under Article 30. When a breach occurs and you invoke the encryption safe harbour, you will need to demonstrate to the supervisory authority that the encryption was adequate and that the keys were not compromised.

Building an Incident Response Workflow for the 72-Hour Window

The breach notification obligation fails in practice when it is addressed only at the legal level without a corresponding engineering and operations workflow. The 72-hour window is short enough that a process that requires board approval before a DPA notification is filed will regularly fail.

A minimal GDPR-compliant incident response workflow for SaaS developers includes:

1. Detection and First Awareness (T=0)

Define what constitutes "becoming aware" for your organisation. This should be written into your internal policies. Suggested definition: "Any team member who identifies evidence sufficient to reasonably conclude that a personal data breach may have occurred must immediately escalate to the incident response lead."

This prevents the ambiguity of who in the organisation was "aware" and at what time.

2. Initial Triage (T=0 to T+2 hours)

Within two hours of the first report:

• Identify the category of breach (confidentiality/integrity/availability)
• Estimate scope (rough number of data subjects, categories of data)
• Determine whether personal data is involved
• Make a preliminary risk assessment: "likely no risk / uncertain / likely high risk"

If risk cannot be ruled out: activate formal incident response. If plainly no personal data is involved: document the determination and close.

3. Notification Decision (T+2 to T+12 hours)

Determine whether the preliminary risk assessment supports the "unlikely to result in a risk" exemption from Article 33(1). This decision must be documented. If you proceed to a determination that notification is required:

• Draft the Article 33 notification with available information
• Identify whether Article 34 individual notification is likely to be required
• Notify your DPO (if appointed)
• Identify your lead supervisory authority and their filing method

4. Authority Notification (before T+72 hours)

File the Article 33 notification via your lead DPA's breach notification portal. Most EU DPAs maintain dedicated portals:

Keep confirmation receipts. These are your evidence that the notification was filed within the window.

5. Individual Notification (if Article 34 applies)

If your breach assessment concludes that a high risk to individuals exists, draft individual notifications. These should:

• Be sent directly (email, in-app notification, or — if no direct contact exists — public announcement)
• Use plain language, not legal language
• Include the specific recommended actions the individual should take

6. Post-Incident Documentation

Article 33(5) requires the controller to document "any personal data breaches, comprising the facts relating to the personal data breach, its effects and the remedial action taken." This documentation must be sufficient to allow the supervisory authority to verify compliance. Retain it for at least three years.

GDPR Breach Notification Penalties in Practice

The GDPR penalty for breach notification violations falls under the lower tier: up to €10 million or 2% of global annual turnover under Article 83(4). This is distinct from the higher-tier penalties under Article 83(5) for violations of fundamental processing obligations (up to €20 million or 4% of global turnover).

However, regulators frequently issue penalties that combine Article 33/34 violations with underlying processing violations — for example, a breach of a sensitive data database that should not have been retained in the first place. The notification fine may be lower than the retention or security fine, but both apply.

Factors that mitigate fines in breach notification cases:

• Proactive notification before regulatory investigation
• Complete and accurate notification with all required elements
• Evidence of a pre-existing incident response plan
• Cooperation with the supervisory authority during investigation
• Prompt remediation and evidence of TOMS improvement

Factors that aggravate fines:

• Delay beyond 72 hours without a justified reason
• Notification triggered by a media story or regulatory inquiry rather than proactive filing
• Missing required content elements
• No documented internal breach register (Article 33(5))
• Repeated violations

Checklist: GDPR Data Breach Notification Compliance

Before a breach occurs:

• Incident response policy defines "becoming aware" with a specific escalation path
• DPO (if required) is identified and has direct escalation contact
• Lead supervisory authority is identified and portal/contact details are known
• Article 33(5) breach register template is prepared
• DPA with processors (Article 28) specifies their breach notification timeline to you (as controller) or your timeline to customers (as processor)
• Encryption implementation is documented in ROPA to support safe harbour determination

During a breach:

• T=0 documented: who became aware, when, what information was available
• Preliminary triage completed within 2 hours
• Risk determination documented with reasoning
• Article 33 notification drafted with all required elements (or phased filing plan if information is incomplete)
• Notification filed before T+72h with confirmation receipt retained
• Article 34 risk assessment documented; individual notifications sent if threshold is met

After a breach:

• Article 33(5) breach register entry completed
• Post-incident review completed
• TOMS improvements documented and implemented

GDPR Articles 33 and 34 are among the most operationally demanding compliance obligations for SaaS developers precisely because they require a fast, accurate response at the moment of maximum uncertainty. A breach is inherently chaotic. The 72-hour clock does not care that your engineering team is still investigating, that your legal team is on a different continent, or that the full scope remains unclear.

The organisations that consistently meet the 72-hour window are those that have built the workflow before they needed it: a clear definition of "becoming aware," a pre-prepared notification template, a documented relationship with their lead supervisory authority, and a post-incident documentation habit that protects them in any follow-on regulatory review.

If you are operating a SaaS that processes EU personal data and have not yet run a tabletop exercise against a fictional breach scenario, that exercise is the most valuable 90 minutes you can spend on GDPR compliance this quarter.