Article 34: Communication of a personal data breach to the data subject

GDPR Article 34 requires you, as a controller, to notify affected individuals when a personal data breach is likely to create a high risk to their rights and freedoms, and to do it without undue delay. To operationalize it, you need a defensible “high-risk” decision workflow, ready-to-send breach communication templates, tested contact-channel logistics, and complete evidence of your assessment and execution. (Regulation (EU) 2016/679, Article 34)

Key takeaways:

• Article 34 triggers only for breaches likely to result in high risk to individuals, and it applies to controllers. (Regulation (EU) 2016/679, Article 34)
• Your audit posture depends on a documented risk assessment and a time-stamped decision record, not a policy statement. (Regulation (EU) 2016/679, Article 34)
• Build a repeatable playbook: triage → risk decision → draft/approve notice → deliver → log evidence → follow-up actions. (Regulation (EU) 2016/679, Article 34)

Article 34 is the “tell the people” part of GDPR breach response. It is separate from supervisory authority notification under Article 33 and has a different trigger: you communicate directly with data subjects when a breach is likely to result in a high risk to their rights and freedoms. The practical challenge is speed with discipline: you often have incomplete facts early, multiple internal stakeholders (security, legal, PR, customer support), and messy contact data. A workable program turns the legal trigger into a fast, documented decision that you can defend later.

Operators typically fail Article 34 in one of three ways: (1) they wait for certainty and miss “without undue delay,” (2) they notify when they shouldn’t (creating unnecessary harm and operational noise), or (3) they notify without enough clarity to be useful to the individual. Your goal is a consistent, repeatable approach: clear controller/processor role mapping, a breach risk scoring method that flags “high risk,” and a notification workflow that can execute even during an incident.

This page gives requirement-level implementation guidance for a CCO, privacy lead, or GRC owner who needs to stand up Article 34 quickly and prove it works. (Regulation (EU) 2016/679, Article 34)

Regulatory text

Legal requirement (excerpt): “When the personal data breach is likely to result in a high risk to the rights and freedoms of natural persons, the controller shall communicate the personal data breach to the data subject without undue delay.” (Regulation (EU) 2016/679, Article 34)

What the operator must do:

1. Identify whether you are the controller for the processing impacted by the breach (or joint controller). Article 34 assigns the duty to the controller. (Regulation (EU) 2016/679, Article 34)
2. Assess whether the breach is likely to result in high risk to individuals’ rights and freedoms (not just “some risk”). (Regulation (EU) 2016/679, Article 34)
3. If the trigger is met, communicate to impacted data subjects without undue delay using channels that are realistic, timely, and documented. (Regulation (EU) 2016/679, Article 34)

Source references for your policy library and audit binder:

• GDPR Article 34 on EUR-Lex (Regulation (EU) 2016/679, Article 34)
• Full GDPR text (Regulation (EU) 2016/679)
• Official Journal publication (GDPR Official Journal Text)

Plain-English interpretation (requirement-level)

If a breach could seriously harm people, you must tell them quickly so they can take protective action. “High risk” is the gating decision. “Without undue delay” means you do not wait for a perfect forensic report if you already have enough information to determine high risk and start notifying. (Regulation (EU) 2016/679, Article 34)

Operationally, Article 34 is a time-sensitive control that depends on:

• Role clarity: Are you the controller for the affected data and processing? (Regulation (EU) 2016/679, Article 34)
• Risk triage maturity: Can you consistently separate low/medium incidents from “high risk to individuals”? (Regulation (EU) 2016/679, Article 34)
• Notification logistics: Do you have contact data, templates, approvals, and delivery methods that work under pressure? (Regulation (EU) 2016/679, Article 34)

Who it applies to (entity and operational context)

Applies to: Any organization acting as a controller for personal data processing within GDPR scope, when a personal data breach occurs and it is likely to result in a high risk to individuals. (Regulation (EU) 2016/679, Article 34)

Common operational contexts where Article 34 becomes real:

• Unauthorized access to customer accounts with personal data exposure.
• Data exfiltration from an endpoint, cloud storage bucket, or SaaS app containing HR/customer records.
• Misdelivery or misconfiguration that exposes sensitive profiles (financial, health-related, identity data) to unintended recipients.

Third-party reality: Many breaches involve a third party (cloud provider, payroll processor, support platform). Even if the incident happens in a processor environment, you still need a clear controller decision and a way to get facts fast enough to make the Article 34 call. Your contracts and incident intake path must support this execution. (Regulation (EU) 2016/679, Article 34)

What you actually need to do (step-by-step)

Step 1: Establish controller/processor role and scope for breach communications

• Maintain a role-and-scope register that maps products/services and key systems to controller vs processor roles, with ownership assigned (privacy + product/business). This prevents “we’ll decide later” during an incident.
• Define what “data subject” populations you can contact (customers, employees, users, dependents) and where the source-of-truth contact data lives.

Artifact: Role-and-scope register for Article 34 applicability (controller vs processor, data categories, systems).

Step 2: Build a “high risk” decision workflow you can run during incident response

Create a documented decision tree that answers:

• What data types were involved?
• How many people could be affected (estimate ranges are acceptable early; document assumptions)?
• Was the data protected (access controls, encryption, hashing) and did protection likely hold?
• What credible harms could follow (identity fraud, account takeover, discrimination, physical safety, loss of confidentiality, reputational harm)?

Run this as a structured meeting with named attendees (security incident commander, privacy/legal, relevant business owner). Make the output binary and time-stamped: Article 34 notice required: Yes/No/Not yet (pending facts), with the next review checkpoint documented. (Regulation (EU) 2016/679, Article 34)

Artifacts:

• Breach risk assessment worksheet / decision log
• Evidence inputs (IR timeline, indicators, affected datasets, containment status)

Step 3: Pre-authorize a notification process and approvals

You need a path that works after-hours:

• Draft owner: privacy/legal prepares the message.
• Fact owner: incident response confirms what is known vs unknown.
• Approver(s): define who can green-light sending (CCO/DPO/GC or delegated alternate).
• Comms/support readiness: customer support gets a script and escalation route.

Avoid bottlenecks by pre-approving templates and allowing limited “fill-in-the-blanks” customization under a controlled workflow.

Artifacts:

• Article 34 SOP with RACI, escalation matrix, and after-hours process
• Approved templates (email, letter, in-app notice) with required fields

Step 4: Execute communication “without undue delay”

Operational checklist:

1. Confirm impacted population and contact source (CRM, HRIS, identity platform).
2. Segment if needed (different harms for different groups).
3. Send using reliable channels (email, letter, in-product messaging), and record delivery evidence.
4. Publish a consistent support intake (dedicated alias, ticket category, call script).
5. Track exceptions: bounced emails, missing addresses, deceased individuals, shared accounts.

Your standard should be: communicate fast once the trigger is met, then follow up with a supplemental notice if facts evolve. Document the rationale for the timing. (Regulation (EU) 2016/679, Article 34)

Artifacts:

• Final notification content + version history
• Distribution list logic (query, filters) and counts
• Sending logs (ESP logs, mail house confirmation, in-app campaign logs)
• Support enablement materials and ticket metrics (qualitative is fine)

Step 5: Retain an “evidence packet” for defensibility

Treat each incident as an audit file:

• Detection timestamp and incident timeline
• Controller/processor determination for the affected processing
• High-risk assessment and decision record
• Approvals and communications sent
• Exceptions handling and re-send attempts
• Post-incident actions (security fixes, access reviews, third-party remediation)

This is the difference between “we did it” and “we can prove it.”

Daydream fit (earned, practical): Many teams operationalize this by keeping a requirement-specific workspace that links the SOP, templates, and incident evidence packets to a single control record, so GRC can produce the full story quickly during a regulator inquiry or customer diligence. Daydream can serve as the system of record for that evidence trail and owner accountability.

Required evidence and artifacts to retain (audit-ready list)

Use this as your minimum binder for Article 34:

• Role-and-scope register (controller/processor, systems, data categories)
• Incident intake record (who reported, when, initial facts)
• High-risk assessment (inputs, decision, sign-offs, timestamps)
• Notification package (content, approval, versions, translations if applicable)
• Delivery proof (send logs, mail confirmations, in-app campaign report)
• Exception log (undeliverable notices, data quality gaps, remediation steps)
• Communications governance (SOP, RACI, escalation path)
• Lessons learned / corrective actions tied to the breach

Common exam/audit questions and hangups

Auditors and regulators typically probe:

• “Show me how you determine ‘likely to result in a high risk.’” Provide the decision tree plus a completed example. (Regulation (EU) 2016/679, Article 34)
• “Who decides, and how quickly can they decide?” Provide RACI, on-call schedule, delegation, and timestamps from incident records.
• “Prove you are the controller for that processing.” Provide the role-and-scope register and supporting service descriptions.
• “How did you define the impacted population?” Provide the query logic, system reports, and assumptions.
• “What did you tell people, and when?” Provide the exact notice content and delivery logs. (Regulation (EU) 2016/679, Article 34)

Hangup to expect: teams often have strong security incident response but weak privacy execution, so the “high risk → data subject comms” bridge is missing.

Frequent implementation mistakes (and how to avoid them)

1. No controller/processor decision ahead of time. Fix: maintain the role-and-scope register and review it when products change.
2. Waiting for complete forensics before notifying. Fix: allow phased communications; document what is known, what is unknown, and when you will update. (Regulation (EU) 2016/679, Article 34)
3. Templates that read like PR, not protective guidance. Fix: write for the individual; include concrete protective actions relevant to the breach scenario.
4. No delivery evidence. Fix: make send logs and exception handling part of the checklist; store them with the incident evidence packet.
5. Third-party breach facts arrive too slowly. Fix: bake reporting and cooperation expectations into third-party incident clauses and test them in tabletop exercises.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this page, so this guidance does not cite specific regulator actions. Your risk exposure is still straightforward: failure to notify affected individuals when high risk is likely creates regulatory, litigation, and trust risk, and it becomes more difficult to defend your response if you cannot show a documented risk assessment and a timely decision record. (Regulation (EU) 2016/679, Article 34)

Practical 30/60/90-day execution plan

First 30 days (stabilize execution)

• Assign owners: privacy lead (process), security (facts), comms/support (channels), IT/data (contact sources).
• Draft and approve: Article 34 SOP, RACI, escalation path, and decision worksheet. (Regulation (EU) 2016/679, Article 34)
• Build notification templates and an evidence packet checklist.
• Create the role-and-scope register for controller/processor determinations across key systems.

Days 31–60 (make it real)

• Run a tabletop that forces the high-risk decision and a mock send; record gaps.
• Validate contact data sources and export mechanics; test bounce handling and exception logging.
• Add third-party incident intake requirements: who to contact, what minimum facts you need, and where you store their updates.

Days 61–90 (harden and prove)

• Run a second tabletop with a third-party scenario and after-hours approvals.
• Add recurring control testing: periodic spot-check that templates, owner lists, and delivery tooling still work.
• Centralize artifacts: SOP + templates + incident evidence packets in a single GRC repository (often where Daydream helps teams keep the control “alive” and auditable).

Frequently Asked Questions

Does Article 34 apply to processors?

Article 34 places the communication duty on the controller. If you are a processor involved in the incident, you still need an operational path to provide timely facts to the controller so they can decide and notify. (Regulation (EU) 2016/679, Article 34)

What counts as “without undue delay”?

Article 34 does not provide a fixed hour or day count in the provided excerpt. Operationally, document the timeline from discovery to decision to sending, and justify any delay with concrete constraints (e.g., confirming impacted population) rather than open-ended investigation. (Regulation (EU) 2016/679, Article 34)

How do we decide whether a breach is “likely to result in a high risk”?

Use a documented, repeatable assessment that considers data sensitivity, exposure likelihood, affected population, and credible harms to individuals. Store the completed assessment with timestamps and approver names for each incident. (Regulation (EU) 2016/679, Article 34)

Can we send an initial notice and then update people later?

Article 34 requires communication without undue delay once the high-risk trigger is met. A practical approach is an initial notice with clear “known/unknown” statements and a commitment to provide follow-up updates as facts are confirmed, with each version retained. (Regulation (EU) 2016/679, Article 34)

What evidence do auditors ask for most often?

The high-risk decision record, proof of who approved it, the exact message sent, and delivery logs. Many teams also get challenged on how they identified the impacted population, so keep the query/report outputs and assumptions. (Regulation (EU) 2016/679, Article 34)

How should we handle missing or outdated contact information?

Treat it as an exception workflow: document the percentage of unreachable individuals qualitatively if you cannot quantify, log attempted channels, and remediate the underlying contact-data quality issue as a corrective action. Keep the exception log with the incident evidence packet. (Regulation (EU) 2016/679, Article 34)