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

To meet the article 34: communication of a personal data breach to the data subject requirement, you must notify affected individuals without undue delay when a breach is likely to create a high risk to their rights and freedoms, and you must be able to prove how you made that decision and executed the notification. This is a controller obligation under GDPR. (Regulation (EU) 2016/679, Article 34)

Key takeaways:

• Treat “high risk” as a formal decision point with documented rationale, not a gut call. (Regulation (EU) 2016/679, Article 34)
• Build a repeatable notification workflow: triage, risk decision, draft, approve, send, log, and follow up. (Regulation (EU) 2016/679, Article 34)
• Keep an evidence packet for every breach event, including decisions not to notify data subjects. (Regulation (EU) 2016/679, Article 34)

Article 34 is the GDPR requirement that forces operational clarity during the worst week of your year: if a personal data breach is likely to result in a high risk to individuals, the controller must tell those individuals without undue delay. (Regulation (EU) 2016/679, Article 34) For a Compliance Officer, CCO, or GRC lead, the hard part is not knowing the words. The hard part is making sure your incident response team can make a defensible high-risk determination quickly, identify the right population, communicate in plain language, and keep enough evidence to survive regulator questions later.

This requirement sits at the boundary of privacy, security incident response, and customer communications. If your process is vague, the common failure mode is predictable: people debate whether the event is “really a breach,” delay the risk decision, lose time finding contact details, and then send inconsistent messages across channels. Article 34 punishes indecision more than imperfect execution.

This page turns Article 34 into an operator-ready runbook: who owns what, what triggers the obligation, what steps to execute, what artifacts to retain, and where audits get stuck. (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)

Operator interpretation:
You need a documented mechanism to (1) determine whether a specific breach creates a likely high risk to people, and (2) if yes, notify impacted data subjects quickly. “Without undue delay” is a standard you must defend with your timeline, approvals, and constraints. (Regulation (EU) 2016/679, Article 34)

What an auditor will look for is simple: did you have a consistent method to decide, did you act promptly, and can you show proof. (Regulation (EU) 2016/679, Article 34)

Plain-English interpretation (what this means in practice)

Article 34 triggers when two things are true:

1. There was a personal data breach (an incident involving personal data). (Regulation (EU) 2016/679, Article 34)
2. The breach is likely to result in a high risk to individuals’ rights and freedoms. (Regulation (EU) 2016/679, Article 34)

When it triggers, you must communicate the breach to the affected people promptly. This is not the supervisory authority notification requirement; it is the individual notification requirement. (Regulation (EU) 2016/679, Article 34)

Practical “high risk” translation

“High risk” is not a label you apply after the incident is over. Treat it as a decision you must reach while facts are still incomplete, then refine as the investigation progresses. Your process should support:

• An initial risk decision based on known facts
• A refresh decision when new facts emerge (e.g., scope expands, data types clarified)

Document both decisions with timestamps and owners. (Regulation (EU) 2016/679, Article 34)

Who it applies to (entity + operational context)

Entity applicability

• Controllers: Article 34 explicitly places the obligation on the controller to communicate to data subjects. (Regulation (EU) 2016/679, Article 34)
• Processors: While Article 34 is a controller duty, processors are operationally involved because controllers rely on processor incident reporting, system logs, and scope details to decide whether notification is required. Define these responsibilities contractually and procedurally so the controller can act without delay. (Regulation (EU) 2016/679)

Operational contexts where Article 34 gets tested

• Cloud/SaaS incidents where logs and tenant scoping live with a third party
• Credential compromise where you cannot quickly confirm what was accessed
• Misconfiguration exposures where external access is possible but unproven
• Data exports or internal access misuse where “exfiltration” is uncertain

Your playbook should not assume perfect information. It should assume partial facts and time pressure.

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

Step 1: Establish role and scope up front (pre-incident)

Create and maintain a role-and-scope register:

• Are you controller, joint controller, or processor for each product/workflow?
• What personal data categories and systems are in scope?
• Who owns breach decisions and communications?

This avoids the most common stall: “Are we the controller here?” (Regulation (EU) 2016/679, Article 34)

Daydream fit: Daydream can host a requirement-specific register and link it to systems, third parties, and owners so the right approvers get pulled into the incident automatically.

Step 2: Define the Article 34 trigger as an explicit decision in incident response

Your incident runbook needs a labeled decision gate:

Decision gate: “Article 34 high-risk determination”

• Input: incident facts (data types, volume, identifiability, affected population, exposure duration, threat actor indicators)
• Output: “Notify data subjects” vs “Do not notify” vs “Defer pending facts”
• Required: documented rationale and approver

Treat “Defer pending facts” as time-boxed internally with an owner and next evidence milestone, because “without undue delay” does not tolerate open-ended deferrals. (Regulation (EU) 2016/679, Article 34)

Step 3: Build the notification workflow (draft → approve → send → confirm)

Operationalize the communication itself as a mini production process:

1. Identify affected data subjects

   • Pull affected identifiers from logs, exports, case records, or processor reports.
   • Map identifiers to contact channels (email, in-app, SMS, postal).
   • Create a deduplicated notification list with evidence of how it was derived.

2. Draft the message

   • Plain language summary of what happened
   • What data was involved (as known)
   • What you are doing about it
   • What the individual can do next (actions that reduce harm)

Keep a template library, but require incident-specific inserts so you do not send generic text that fails to inform. (Regulation (EU) 2016/679, Article 34)

3. Legal, privacy, and security approval
   • Privacy validates scope and risk framing
   • Security validates technical accuracy
   • Legal validates claims and commitments
   • Comms validates readability and channel formatting

Pre-assign approvers by role, not by name, to avoid vacation bottlenecks.

4. Send and record

   • Send via defined channels
   • Record send times, delivery status, and bounce handling
   • Preserve the exact content that was sent (final version)

5. Support readiness

   • Prepare customer support scripts and escalation paths
   • Create a mechanism to authenticate data subject follow-ups without exposing more data

Step 4: Maintain a defensible timeline (“without undue delay”)

You need a timeline that shows:

• When you became aware of the breach
• When the Article 34 decision was made
• When communications were approved
• When communications were sent

If there was delay, document why it was not “undue” (e.g., inability to identify affected individuals, need to confirm whether personal data was involved, channel constraints). Keep this factual, not argumentative. (Regulation (EU) 2016/679, Article 34)

Step 5: Close the loop with post-incident controls

After sending (or deciding not to send):

• Record final scope and corrected facts
• Capture lessons learned and update templates/runbooks
• Track remediation that reduces recurrence

This is where you convert one painful event into a stronger control environment. (Regulation (EU) 2016/679, Article 34)

Required evidence and artifacts to retain (audit-ready)

Maintain an “Article 34 evidence packet” for each breach, even if you decide not to notify:

• Role determination (controller/processor) for the affected processing activity (Regulation (EU) 2016/679)
• Incident summary: what happened, affected systems, confirmed/estimated data involved
• High-risk determination record:
  • decision outcome
  • rationale tied to known facts
  • approver(s) and timestamps (Regulation (EU) 2016/679, Article 34)
• Data subject scoping method:
  • queries/log sources used
  • list generation method
  • deduplication approach
• Notification artifacts:
  • final approved message content
  • channel used
  • send logs / delivery reports
  • customer support script
• Delay rationale (if any) with dated milestones (Regulation (EU) 2016/679, Article 34)
• Remediation tracker: corrective actions and completion evidence

Daydream fit: Daydream works well as the system of record for the evidence packet because it can attach approvals, decision notes, and artifacts in one place, reducing “lost in Slack/email” risk.

Common exam/audit questions and hangups

Expect these questions in a regulator inquiry, customer due diligence, or internal audit:

• “Show me how you decide whether a breach is likely to result in a high risk.” (Regulation (EU) 2016/679, Article 34)
• “Who can approve a decision not to notify data subjects?”
• “How do you ensure you can contact the affected population without delay?”
• “Where is the final notification text you sent, and when was it sent?” (Regulation (EU) 2016/679, Article 34)
• “How do third parties (processors) provide the facts you need to make the Article 34 decision?” (Regulation (EU) 2016/679)

Hangups usually come from missing timestamps, unclear ownership, and inability to reproduce the affected-population list.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	What to do instead
Treating Article 34 as “security’s job”	Security can’t own the legal risk decision alone	Make a named privacy owner accountable for the Article 34 decision gate. (Regulation (EU) 2016/679, Article 34)
No written criteria for “high risk”	Decisions look arbitrary after the fact	Create a short decision record template that forces consideration of data type, identifiability, and likely harm. (Regulation (EU) 2016/679, Article 34)
Waiting for perfect facts	Drives delay and inconsistent comms	Make an initial decision, send what you know, and update if scope materially changes. (Regulation (EU) 2016/679, Article 34)
Losing the exact message version	You can’t prove what data subjects were told	Store the final approved text and channel-specific variants in the evidence packet.
Third-party bottleneck	Controllers can’t notify without processor facts	Add processor incident reporting requirements and drill them; test contact paths. (Regulation (EU) 2016/679)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this page, so this guidance avoids case-specific claims.

Operationally, your risk is not limited to fines. Article 34 failures create downstream exposure: inconsistent customer communications, contractual disputes (especially in B2B data processing), and reputational damage because affected individuals hear about the breach through other channels first. Anchor your program on speed, accuracy, and provable decision-making. (Regulation (EU) 2016/679, Article 34)

Practical execution plan (30/60/90-day)

Exact timelines depend on your environment and incident readiness, so treat this as a phased plan, not a calendar promise.

First 30 days (Immediate foundation)

• Publish an Article 34 operating procedure with owners, decision gate, and required approvals. (Regulation (EU) 2016/679, Article 34)
• Stand up the role-and-scope register across products/workflows, including key third parties. (Regulation (EU) 2016/679)
• Create notification templates for major channels plus an approval checklist.
• Define the “Article 34 evidence packet” structure in your GRC system (Daydream or equivalent) and run a tabletop exercise focused on the notification decision and timeline.

By 60 days (Operationalize and test)

• Integrate the Article 34 decision gate into incident tooling (ticketing/IR platform) so it cannot be skipped.
• Validate that you can generate an affected data subject list from logs and systems, and document the method.
• Add processor dependencies: escalation contacts, minimum incident fact set, and delivery deadlines for scoping data. (Regulation (EU) 2016/679)

By 90 days (Harden and audit-proof)

• Run a second tabletop with a “messy facts” scenario where scope changes midstream.
• Audit two things: (1) completeness of evidence packets, (2) time from awareness to decision to communication. (Regulation (EU) 2016/679, Article 34)
• Close gaps through runbook updates, template refinements, and expanded access to logs needed for scoping.

Frequently Asked Questions

Does Article 34 apply to processors?

The communication obligation is on the controller. Processors still matter operationally because controllers may rely on processor facts to assess high risk and identify affected people. (Regulation (EU) 2016/679, Article 34)

What does “without undue delay” mean operationally?

It means you should not wait longer than necessary once you determine the breach is likely to create high risk. Your defensibility comes from a clear timeline and documented reasons for any delay tied to concrete constraints. (Regulation (EU) 2016/679, Article 34)

Do we have to notify data subjects for every personal data breach?

No. Article 34 triggers when the breach is likely to result in a high risk to individuals’ rights and freedoms. You still need a documented decision record when you choose not to notify. (Regulation (EU) 2016/679, Article 34)

Who should approve the decision to notify (or not notify) individuals?

Assign an accountable owner in privacy/compliance, with required consultation from security and legal. Make the approver role-based and document the approval in the incident record. (Regulation (EU) 2016/679, Article 34)

What evidence should we keep if we decide not to notify data subjects?

Keep the high-risk determination record, the facts used to reach it, timestamps, and approvers. Auditors will test whether the decision was consistent and timely, not whether you can restate the policy. (Regulation (EU) 2016/679, Article 34)

How do we handle breaches that affect multiple products or business units?

Use a single incident evidence packet with clear sub-scoping per system: role (controller/processor), data categories, and affected population derivation per environment. This prevents conflicting messages and makes approvals cleaner. (Regulation (EU) 2016/679, Article 34)