GDPR Article 33-34: Personal Data Breach Notification

The clock on my laptop read 11:47 PM when my phone buzzed. It was the CEO of a London-based fintech company, and I could hear the panic in his voice before he even spoke. "We've had a breach. Customer data. Maybe 12,000 records. What do we do?"

My first question wasn't about the technical details. It was simpler, and far more critical: "When did you discover it?"

"About three hours ago," he replied.

I felt my stomach drop. Three hours gone. That left us roughly 69 hours to notify the supervisory authority—or face penalties that could reach €20 million or 4% of annual global turnover, whichever is higher.

Welcome to the unforgiving world of GDPR Articles 33 and 34.

The 72-Hour Countdown That Changes Everything

After fifteen years in cybersecurity, I've guided dozens of organizations through GDPR breach scenarios. Here's what I've learned: most companies catastrophically underestimate the complexity of breach notification until they're in the middle of one.

GDPR's breach notification requirements represent one of the most demanding aspects of data protection law. They're not suggestions. They're not guidelines. They're legal obligations with teeth sharp enough to bankrupt organizations that get them wrong.

Let me break down exactly what Articles 33 and 34 require, why they matter, and how to navigate them when your world is falling apart at 2 AM.

"The GDPR doesn't care about your technical difficulties, your staffing shortages, or your weekend plans. When the 72-hour clock starts ticking, nothing else matters."

Article 33: Notification to the Supervisory Authority

The Core Requirement

Article 33 is brutally simple in concept: when you discover a personal data breach, you must notify your supervisory authority within 72 hours—unless the breach is unlikely to result in a risk to individuals' rights and freedoms.

That "unless" is where organizations get into trouble. I've seen companies convince themselves that breaches weren't "risky enough" to report, only to face enforcement actions later when the supervisory authority disagreed.

What Actually Triggers the 72-Hour Clock?

Here's the critical question: when does "awareness" begin?

I worked with a healthcare provider in 2021 that detected unusual database activity on a Monday morning. Their security team investigated for three days before concluding it was a breach. They notified the supervisory authority on Thursday, believing they had met the 72-hour requirement.

They were wrong.

The supervisory authority determined that "awareness" began on Monday when they first detected the anomaly, not on Wednesday when they confirmed it was a breach. The company faced a €180,000 fine—not for the breach itself, but for late notification.

The clock starts when you have a reasonable degree of certainty that a personal data breach has occurred. Not absolute certainty. Reasonable certainty.

What Must Your Notification Include?

Article 33(3) specifies exactly what your notification must contain. I've created this reference table that I keep printed next to my desk:

The "Phased Notification" Escape Hatch

Here's something that saved my client's fintech company that night: Article 33(4) allows you to provide information in phases when you can't gather everything within 72 hours.

This is how we handled it:

Hour 0 (Discovery): Breach identified at 8:47 PM Hour 3: Initial containment measures implemented Hour 12: First notification sent to ICO (UK supervisory authority)

That first notification included:

• Confirmation that a breach had occurred

• Initial assessment: approximately 12,000 customer records

• Data categories: names, email addresses, account balances

• Our DPO contact information

• Statement that investigation was ongoing

• Commitment to provide updates within 48 hours

Hour 48: Second update provided:

• Refined numbers: 11,847 confirmed affected individuals

• Root cause analysis completed

• Detailed remediation steps

• Assessment of individual risk

• Plan for individual notification (Article 34)

This phased approach kept us compliant while giving us time to investigate properly. But here's the critical part: your initial notification must still go out within 72 hours, even if incomplete.

"Perfection is the enemy of compliance. Send what you know within 72 hours, then fill in the details. Don't wait for complete information and miss the deadline."

Article 34: Communication to Data Subjects

When You Must Notify Individuals

Article 34 creates a separate obligation: when a breach is likely to result in a high risk to individuals' rights and freedoms, you must notify them directly.

Notice the difference? Article 33 requires notification to the supervisory authority when there's "risk." Article 34 requires notification to individuals when there's "high risk."

This distinction causes endless confusion. Let me share a framework I developed after handling my first dozen breaches:

The High Risk Assessment

How do you determine "high risk"? The GDPR doesn't give you a formula, but I use this assessment framework with my clients:

Consider these factors:

1. Type of data compromised

   • Financial information = High Risk

   • Health records = High Risk

   • Credentials/passwords = High Risk

   • Basic contact info alone = Lower Risk

2. Volume of individuals affected

   • Larger numbers generally increase risk

   • But even one person's sensitive data can be high risk

3. Characteristics of affected individuals

   • Children = Higher Risk

   • Vulnerable populations = Higher Risk

   • General adult population = Standard Risk

4. Ease of identification

   • Direct identifiers (names, IDs) = Higher Risk

   • Pseudonymized data = Lower Risk

   • Properly anonymized data = Not personal data (no breach)

5. Potential consequences

   • Identity theft risk = High Risk

   • Financial loss potential = High Risk

   • Discrimination risk = High Risk

   • Reputational damage only = Lower Risk

What Your Individual Notification Must Include

I learned this the hard way after watching a client send notification letters that generated more complaints than the breach itself. Here's what Article 34(2) requires:

A Real-World Example That Went Right

In 2022, I worked with an e-commerce company that discovered a web application vulnerability had exposed customer data for approximately 48 hours before being detected.

Affected data:

• Names

• Email addresses

• Shipping addresses

• Order history

• Partial credit card numbers (last 4 digits only)

Risk Assessment:

• Full credit card numbers NOT exposed (stored separately, encrypted)

• No passwords compromised (separate authentication system)

• No financial account information

• Could enable targeted phishing attempts

Our approach:

We assessed this as "high risk" primarily because:

1. Sufficient data for convincing phishing attacks

2. 48-hour exposure window (plenty of time for data harvest)

3. Evidence of automated scanning activity during exposure period

Individual notification sent within 36 hours included:

Dear [Customer Name],

We are writing to inform you of a security incident that may have affected your personal information.

On March 15, 2022, we discovered a vulnerability in our website that potentially allowed unauthorized access to customer account information between March 13-15, 2022. We immediately fixed the vulnerability and began investigating the extent of the exposure.

Your affected information includes: - Name - Email address - Shipping address - Order history - Last 4 digits of credit cards used (full card numbers were NOT exposed)

Your passwords and full payment card details were NOT compromised, as they are stored in separate, encrypted systems.

What we're doing: - Fixed the vulnerability that caused this issue - Engaged a leading cybersecurity firm to conduct a comprehensive security audit - Implemented additional monitoring systems - Reported this incident to the Information Commissioner's Office - Notified payment card processors

What you should do: 1. Be alert for phishing emails that may reference your order history 2. Never click links in unexpected emails claiming to be from us 3. Contact us directly through our website if you have concerns 4. Consider placing a fraud alert with credit bureaus

We sincerely apologize for this incident and the concern it may cause. We are taking this matter extremely seriously.

For questions, contact our Data Protection Officer: [Name, Email, Phone]

Sincerely, [CEO Name and Title]

The outcome:

• Supervisory authority acknowledged timely notification

• Customer complaints were minimal (under 2%)

• No enforcement action taken

• Media coverage was brief and factual

Compare that to companies that send vague, legalistic notifications that raise more questions than they answer. Those are the ones that end up with class-action lawsuits and regulatory investigations.

"Your breach notification should be written by a human, for humans. Legal review is essential, but if your grandmother couldn't understand it, rewrite it."

The Three Exceptions to Individual Notification

Article 34(3) provides three circumstances where you don't have to notify individuals, even when there's high risk:

Exception 1: Strong Encryption or Pseudonymization

If you've implemented appropriate technical protection measures that render the data unintelligible to unauthorized persons, you may be exempt from individual notification.

Real example: A healthcare provider lost a laptop containing 50,000 patient records. The hard drive was encrypted with AES-256, and they had documented key management procedures. After assessment with their supervisory authority, individual notification was not required.

Critical caveat: The encryption must have been effective BEFORE the breach. You can't encrypt after the fact and claim this exception.

Exception 2: Subsequent Measures That Eliminate High Risk

If you take measures after the breach that ensure the high risk no longer exists, you may be exempt.

Real example I witnessed: A database backup was briefly exposed on a misconfigured cloud storage bucket. The company's monitoring detected it within 4 minutes. They immediately:

• Secured the bucket

• Reviewed access logs (showed no access)

• Verified the backup was from a non-production environment with test data

• Confirmed zero actual customer data exposure

The supervisory authority agreed that subsequent investigation eliminated the high risk, so individual notification wasn't required.

This exception is RARE. Use it cautiously.

Exception 3: Disproportionate Effort Required

If individual notification would require disproportionate effort, you can substitute it with a public communication that's equally effective.

Here's what "disproportionate effort" actually means:

Important: You must still make a public communication that:

• Is equally effective at reaching individuals

• Contains the same information as individual notices would

• Is prominently displayed and easily accessible

I worked with a company that used this exception after a breach affecting 8.7 million users across 95 countries. Individual notification would have cost an estimated $4.3 million and taken months to execute properly across all jurisdictions.

Instead, they:

• Published detailed breach notice on their homepage

• Sent email to all accounts with valid email addresses (5.2 million)

• Purchased advertising in major newspapers in affected countries

• Issued press releases to major media outlets

• Posted notices on social media platforms

• Displayed prominent in-app notifications

Total cost: $680,000. But they could demonstrate they reached more individuals more quickly than individual postal notifications would have.

The supervisory authority approved this approach.

The Timing Question That Keeps Everyone Awake

"Without undue delay" is the requirement for individual notification. But what does that actually mean?

From my experience across multiple jurisdictions:

Critical mistake I see: Companies rush to notify individuals before understanding the full scope, then send multiple confusing updates as they learn more.

Better approach: Send initial notification acknowledging the breach and that investigation is ongoing, then provide detailed follow-up within 48-72 hours.

The Documentation Requirements Nobody Talks About

Article 33(5) requires you to document ALL breaches, whether or not you notify the supervisory authority or individuals.

This documentation must include:

• Facts of the breach

• Effects of the breach

• Remedial action taken

I've been in multiple supervisory authority audits where this documentation—or lack of it—made the difference between a warning and a substantial fine.

Here's the template I use:

Breach Documentation Template

I maintain this documentation for EVERY incident, even ones that turn out to be false alarms. Why? Because during an audit, supervisory authorities want to see your decision-making process. They want to understand why you concluded something wasn't a breach or didn't require notification.

The Cross-Border Nightmare

Here's where things get really complicated: when you operate in multiple EU countries or globally.

Lead Supervisory Authority

If you have establishments in multiple EU countries, Article 56 designates a "lead supervisory authority" based on your main establishment. In theory, you only notify the lead authority, and they coordinate with others.

In practice? It's messier.

Real scenario from 2023: A software company with headquarters in Germany, development in Poland, and sales offices in France, Spain, and Italy experienced a breach affecting users across the EU.

They notified the German supervisory authority (their lead authority) within 72 hours. Three weeks later, they received inquiries from the French, Spanish, and Italian authorities demanding their own notifications.

The lesson: When in doubt, notify all relevant supervisory authorities. The GDPR's one-stop-shop mechanism is evolving, but it's not yet seamless.

Non-EU Companies

If you're outside the EU but have EU customers, you need:

• A representative in the EU (Article 27)

• To follow the same notification requirements

• To work with the supervisory authority where your representative is located

I worked with a US-based SaaS company that made a critical mistake: they had EU customers but no EU representative. When they had a breach affecting EU residents, they didn't know which supervisory authority to notify.

They ended up notifying:

• The Irish Data Protection Commission (where many US tech companies register)

• Every supervisory authority in countries where they had substantial customers

• The European Data Protection Board

It was expensive, time-consuming, and could have been avoided with proper planning.

Real Penalties: What Actually Happens

Let me share actual enforcement actions I've studied:

Case 1: Late Notification - €400,000 Fine

Company: Italian telecommunications provider Breach: Customer database accessed by unauthorized employee Affected: 5,000 customers Problem: Notified supervisory authority 6 days after discovery Penalty: €400,000 for late notification (not the breach itself)

Key lesson: The late notification penalty exceeded what the breach itself might have cost them.

Case 2: Inadequate Individual Notification - €220,000 Fine

Company: German online retailer Breach: Payment card data exposed Affected: 3,500 customers Problem: Notified individuals with vague letter that didn't explain risks or provide specific guidance Penalty: €220,000 for inadequate notification

Key lesson: The quality of notification matters as much as the timing.

Case 3: No Authority Notification - €9.5 Million Fine

Company: Major hotel chain Breach: Multiple breaches over 2-year period Affected: Millions of guests globally Problem: Failed to notify supervisory authority about breaches that clearly met the notification threshold Penalty: €9.55 million

Key lesson: Deliberate or repeated failures to notify result in massive penalties.

Case 4: Everything Right - No Penalty

Company: Healthcare technology provider Breach: Ransomware attack affecting patient data Affected: 28,000 patients Response:

• Notified supervisory authority within 48 hours

• Sent clear, helpful notifications to individuals within 60 hours

• Provided 24 months of identity monitoring

• Detailed documentation of response

• Implemented significant security improvements

Penalty: None. Supervisory authority issued statement praising their response.

Key lesson: Good breach response can actually enhance your reputation.

"Supervisory authorities are not looking to punish organizations that suffer breaches. They're looking to punish organizations that handle breaches badly or hide them."

The Breach Response Playbook I Wish I'd Had

After guiding organizations through dozens of breaches, here's the response playbook I've refined:

Hour 0-2: Immediate Response

Actions:

1. Confirm the breach is real (not a drill or false alarm)

2. Activate incident response team

3. Start the 72-hour notification clock in your documentation

4. Implement immediate containment measures

5. Preserve evidence (logs, system images, etc.)

6. Brief executive leadership

Common mistakes:

• Spending too long confirming before starting the clock

• Destroying evidence during containment

• Not documenting decisions and actions in real-time

Hour 2-12: Assessment and Initial Notification

Actions:

1. Assess scope: what data, how many individuals

2. Conduct initial risk assessment

3. Determine notification requirements (Art. 33? Art. 34?)

4. Prepare initial notification to supervisory authority

5. Brief legal, PR, and customer service teams

6. Set up dedicated communication channels

Common mistakes:

• Waiting for complete information before notifying authority

• Making premature public statements

• Not preparing customer service for inquiries

Hour 12-72: Deep Investigation and Notification

Actions:

1. Complete detailed forensic analysis

2. Refine affected individual count

3. Submit notification to supervisory authority (must be within 72 hours)

4. Determine need for individual notification

5. Prepare individual notification materials

6. Identify lessons learned and immediate improvements

7. Provide updates to supervisory authority

Common mistakes:

• Missing the 72-hour deadline while perfecting the notification

• Underestimating the time needed to prepare individual notifications

• Not seeking supervisory authority guidance when uncertain

Hour 72+: Individual Notification and Remediation

Actions:

1. Send individual notifications (if required)

2. Set up support systems for affected individuals

3. Implement remediation measures

4. Provide additional updates to supervisory authority

5. Complete detailed breach documentation

6. Conduct post-incident review

7. Implement systemic improvements

Common mistakes:

• Treating individual notification as a formality

• Not providing adequate support for affected individuals

• Failing to follow through on promised remediation

The Tools and Templates You Actually Need

After years of handling breaches, here are the practical resources I maintain:

Pre-Breach Preparation

Essential documents to have ready:

1. Breach Response Plan (detailed playbook)

2. Incident Response Team contact list (with backup contacts)

3. Supervisory Authority contact information

4. Notification email/letter templates

5. Risk assessment framework

6. Breach documentation template

7. External resource list (forensics firms, legal counsel, PR firms)

Template: 72-Hour Notification to Supervisory Authority

I keep this template with blanks that can be filled in under pressure:

To: [Supervisory Authority Contact] From: [Your DPO] Date: [Notification Date] Subject: Personal Data Breach Notification - [Your Organization]

Dear [Supervisory Authority],

In accordance with Article 33 of the GDPR, we hereby notify you of a personal data breach.

1. Nature of the Breach: [Brief description of what happened]

Date of Breach: [When it occurred] Date of Discovery: [When you became aware]

2. Categories and Approximate Number of Data Subjects: - Approximately [number] individuals affected - Categories: [customers/employees/patients/etc.] - Geographic location: [countries/regions]

3. Categories and Approximate Number of Personal Data Records: - Approximately [number] records - Data types: [names, addresses, financial data, health data, etc.] - Sensitivity level: [assessment]

4. Contact Details: Data Protection Officer: [Name] Email: [DPO email] Phone: [DPO phone] Address: [Physical address]

5. Likely Consequences: [Realistic assessment of potential harm to individuals]

6. Measures Taken or Proposed: Immediate actions: - [List containment measures]

Planned actions: - [List remediation measures]

Individual notification: - [Required/Not Required] - [If required: timeline and method] - [If not required: justification]

7. Investigation Status: [Current status and what remains to be determined]

We will provide updated information as our investigation progresses.

Sincerely, [Your Name and Title]

Quick Reference Card

I recommend keeping this laminated card accessible to anyone who might discover a breach:

PERSONAL DATA BREACH - IMMEDIATE ACTIONS

☐ Note exact time of discovery: ___________

☐ Do NOT delete, modify, or shut down systems yet

☐ Notify: [Your incident response contact] immediately

☐ Preserve all evidence and logs

☐ Document everything in real-time

72-HOUR CLOCK STARTS AT DISCOVERY

The Questions I Always Get Asked

Q: What if we discover a breach on Friday evening?

A: The 72-hour clock doesn't pause for weekends. I've submitted supervisory authority notifications at 3 AM on Sunday mornings. This is why you need 24/7 incident response capability.

Q: Can we negotiate the 72-hour deadline with the supervisory authority?

A: No. The deadline is absolute. However, you can submit an initial notification within 72 hours and provide additional information later using the phased approach.

Q: What if we're not sure whether it's a breach?

A: Document your assessment thoroughly. If you reasonably believe a breach has NOT occurred, document why. If you're uncertain, err on the side of notification. A false alarm notification is better than a missed breach.

Q: Do we notify for every single breach?

A: You must document every breach. You notify the supervisory authority only when there's risk to individuals' rights and freedoms. You notify individuals only when there's high risk. But you document EVERYTHING.

Q: What about breaches that happened in the past but we just discovered them?

A: The 72-hour clock starts when you discover the breach, not when it occurred. But you must report historical breaches even if they happened years ago—if you just discovered them.

Q: Can we use a third-party service to send individual notifications?

A: Yes, many organizations use specialized breach notification services. But you remain responsible for the content and timing. Choose vendors carefully.

Q: What if the breach affects non-EU residents too?

A: GDPR requires notification for EU residents. You may have additional obligations under other laws (like US state breach notification laws). Coordinate your global response.

The Technology That Makes This Manageable

After dealing with breaches ranging from 50 to 5 million affected individuals, here are the tools I recommend:

Essential Technology Components

The Notification Infrastructure

For organizations handling significant volumes of personal data, I recommend maintaining:

1. Pre-approved notification templates (vetted by legal)

2. Bulk notification capability (email, SMS, postal)

3. Dedicated notification webpage (can be activated quickly)

4. Call center scripts (for handling inquiries)

5. Translation services (for multi-language notifications)

6. Monitoring dashboards (track notification delivery and response)

Final Thoughts: The Breach That Taught Me Everything

Let me close with the breach that fundamentally changed how I think about Articles 33 and 34.

In 2020, I was advising a healthcare provider when they discovered a breach that exposed patient records. The incident response was textbook perfect:

• Discovered at 9:15 AM on Tuesday

• Contained within 2 hours

• Supervisory authority notified within 48 hours

• Patients notified within 60 hours

• Comprehensive remediation implemented

But here's what made it memorable: six months later, the CISO told me something unexpected. "That breach was the best thing that happened to our security program," she said.

I must have looked shocked, because she quickly explained: "We'd been asking for budget, for headcount, for prioritization for years. After the breach—and especially after leadership saw how seriously the supervisory authority and patients took it—suddenly we had a seat at the table. We got the resources we needed. Security became a board-level discussion."

She paused, then added: "But more importantly, the breach response showed us we could handle a crisis. We had our procedures, we followed them, and we got through it. The confidence that gave our team was invaluable."

"The goal isn't to never have a breach—that's unrealistic. The goal is to handle breaches so well that they become opportunities to demonstrate your commitment to data protection."

Articles 33 and 34 aren't just legal requirements. They're your framework for turning potential disasters into managed incidents. They force you to be prepared, to be transparent, and to prioritize the rights of individuals.

Yes, the 72-hour deadline is unforgiving. Yes, the documentation requirements are burdensome. Yes, the risk assessments are complex.

But organizations that embrace these requirements—that build them into their DNA—are the ones that survive breaches with their reputations intact.

The companies that fail aren't the ones that get breached. They're the ones that weren't prepared for what comes after.

So start preparing now. Build your response plan. Train your team. Set up your notification infrastructure. Practice your procedures.

Because it's not a question of if you'll need Articles 33 and 34. It's a question of when.

And when that moment comes—when you're staring at your laptop at 11:47 PM, trying to remember everything you know about breach notification—you'll be glad you prepared.