Article 34 GDPR breach communication to data subjects: evidence

What Article 34 asks you to do when individuals are at high risk

Article 34 requires the controller to tell affected individuals directly and without undue delay when a personal data breach is likely to result in a high risk to their rights and freedoms. The duty sits alongside the supervisory authority notification under Article 33, not after it, and it is triggered by the risk to people, not by the size of the incident or the number of records. Once a breach is confirmed, the team's first decision is whether this high-risk test is met, and that decision should be written down with the facts available at the time. The harm Article 34 targets is the damage a person can suffer if they do not know their data was exposed. Identity theft, fraud, discrimination, loss of confidentiality about health or financial matters and physical safety risks all depend on whether individuals can act to protect themselves, such as changing credentials, watching accounts or contacting the controller. The high-risk test is the hard part because it asks for a judgment about the likely consequences for specific people, based on the nature of the data, the vulnerability of the individuals, how easily they can be identified and who obtained the data. Organizations often have incomplete facts on day one, so the assessment must be revisited as the forensic picture improves. The Hôpital Privé de la Loire case shows that the affected population is not limited to the hospital's own patients. The CNIL's decision of 3 September 2026 included an Article 34 failure because 202,246 people designated as trusted third parties, whose data were also stolen, received no direct information. Your breach register and affected-person lists should therefore be built from the data actually taken, including contacts, guardians, employers and other linked people, not only from your primary customer or patient table. Confirm with your legal team which parties in your own data model fall into this group before an incident occurs.

Which breaches and people fall under Article 34

Article 34 applies only when a breach is likely to result in a high risk, and the set of people who must be told depends on how the breach is characterized. Each card below names one scoping decision and what it changes in the notification work, from the risk test to cross-border populations.

Clearing the high-risk threshold

Article 34 is triggered by a likely high risk to individuals, a higher bar than the risk test that governs notification to the supervisory authority. Document the assessment for each breach, weighing the sensitivity of the data, the ease of identifying people and the severity of likely consequences. Ask who owns the sign-off and whether the decision is recorded with its reasons so it can be reviewed later.

Data categories and their sensitivity

The type of data drives the risk outcome. Credentials, financial records, health data and identity documents typically push a breach toward high risk, while low-sensitivity contact details may not. Map which systems hold which categories so the team can answer quickly which people are exposed and whether the data was in a form an attacker could read.

Volume of affected individuals

The number of people involved affects both the scale of the communication and the choice of channel. A small group can usually be contacted directly, while a large population may push the controller toward a public communication. Ask how records are counted, whether duplicates across systems are removed, and how the count is updated as forensic work narrows the scope.

Indirect data subjects

Affected people are not always the controller's own customers. In the CNIL's September 2026 decision on Hôpital Privé de la Loire, a EUR 500,000 fine included an Article 34 failure because 202,246 people designated as trusted third parties, whose data were also stolen, received no direct information. Build a list of every person whose data was exposed, including contacts, guarantors and family members named in records.

Processor-held data

When a processor holds the data, the controller remains responsible for telling the data subjects, even though the processor detected the breach. Contracts should require the processor to share the affected-person records, contact details and forensic findings quickly enough for the controller to act. Confirm in the processing agreement who sends the communication and who pays for it.

Cross-border populations

Breaches often reach people in several EU Member States and in Iceland, Liechtenstein and Norway, where the GDPR also applies under the EEA arrangement. Group affected individuals by country and language so the communication meets the clear and plain language requirement in each market. Confirm with counsel how national supervisory authorities and local communication practice affect the timing and wording.

How to build a communication process that meets Article 34

The sequence turns Article 34 from a legal reading into a repeatable process: the high-risk test is agreed before an incident, the notice content is pre-drafted, the people and channels are ready, and each decision to communicate directly, publicly or not at all is recorded with its reasons. The output is a process an incident team can run under pressure and an assessor can trace.

Define high-risk criteria with the Article 33 assessment
The privacy office and the security lead agree written criteria for when a breach is likely to result in a high risk to individuals, using the same risk assessment that decides whether the supervisory authority must be notified. Categories of data, volume, identifiability, vulnerable groups and likely misuse such as fraud or discrimination should appear as explicit factors. The output is a short risk rubric approved by the data protection officer or accountable owner, held with the incident response plan so responders do not have to invent the test during an incident.
Draft the Article 34 notice template
Prepare a template that covers the content Article 34(2) requires: a description of the breach in clear and plain language, the name and contact details of the data protection officer or other contact point, the likely consequences, and the measures taken or proposed, including advice to individuals on how to limit harm. Keep placeholders for facts that are unknown at first, and have legal review the wording and language variants for each market where affected people live. The output is an approved template with a fill-in guide, not a blank page written at the time of the incident.
Build contact lists and delivery channels
Map which records hold contact details for each affected group, including customers, employees, patients, and any third parties whose data was also exposed, and confirm that those details are current and lawful to use for notice. Identify secondary channels in case email is unavailable, such as postal mail or in-app messages, and assign the people who can approve and send. The output is a documented contact source for each data group, a named sender, and a tested route to reach people who cannot be reached through the usual account channel.
Decide direct versus public communication
Write the decision logic for three outcomes: direct communication to each affected person, a public communication where direct contact would involve disproportionate effort, and no communication where Article 34(3) conditions are met. Include who can approve each path and what evidence must be gathered before choosing it. The output is a decision flow that routes each incident to one path, with a pre-approved public notice format for the disproportionate effort case. Ask counsel to confirm the thresholds for your sector and member states.
Document each exemption decision
Record every decision not to communicate directly, whether the data were unintelligible through encryption, later measures removed the likelihood of high risk, or the effort was judged disproportionate. The record should name the decision owner, the facts relied on, the date, and the evidence, such as key-management logs or a description of the controls that rendered the data unintelligible. For encryption, confirm that the keys were not also compromised. The output is an exemption entry in the breach register that an assessor or supervisory authority can review.
Rehearse the process with the incident team
Run a tabletop exercise that starts from a realistic scenario involving several data groups, including one where third parties are affected, and walk through the risk rubric, template, contact lists, and decision path. Test whether the team can identify who must be contacted and whether the notice can be approved and sent under the time pressure the response plan sets. Record gaps, assign owners, and update the templates and lists. The output is a dated exercise report with corrective actions tracked to closure.

How an assessor or supervisory authority tests Article 34

This table lists each element an assessor or supervisory authority checks when reviewing a data subject communication under Article 34, what evidence it looks for and where organizations commonly fall short. Read it as a checklist to run against your own breach file before a regulator or auditor does.

Test element	What the reviewer checks	Evidence that passes	Common finding
High-risk assessment	Whether the controller assessed the likelihood and severity of risk to individuals and recorded the outcome	Dated risk assessment naming data categories, volumes, vulnerable groups and likely consequences, signed off by the accountable owner	No record of the assessment, or a conclusion reached after the notice was already sent
Timing of notice	Whether individuals were told without undue delay once high risk was found	Timeline showing when high risk was identified, when notices were approved and when they were dispatched	Notices delayed while the organization waited for complete forensic detail rather than sending a phased update
Content against Article 34(2)	Whether the notice describes the breach in clear, plain language and gives contact details, likely consequences and measures taken or proposed	Notice template and sent copies showing each required element, with a named contact point reachable by individuals	Technical jargon, no contact route, or consequences and remedial steps left out
Coverage of affected individuals	Whether every group whose data was taken received a direct notice, including people held as third parties or contacts in the data	Reconciliation of the affected population against the notice distribution list and the dispatch log	Omitted affected groups, such as trusted third parties or relatives whose data was also stolen
Encryption or intelligibility exemption	Whether data was actually rendered unintelligible to the unauthorized party and the claim is supported by technical evidence	Key custody records, encryption configuration and proof the keys were not compromised	Exemption claimed for data that was only partly encrypted, with file names or metadata exposed
Later-measures exemption	Whether subsequent measures really make the high risk no longer likely, and when they took effect	Dated evidence of containment steps, with analysis showing the risk to individuals was removed	Assertion that risk was mitigated without evidence, or measures applied after the individuals had already been exposed
Disproportionate effort exemption	Whether direct contact was truly disproportionate and whether a public communication replaced it	Documented effort estimate, reasons direct contact was not feasible and a public notice that reached the affected people	Exemption used to avoid contact that was practical, or a public notice that was not published in an accessible form
Supervisory authority order	Whether the authority required communication and whether the controller complied with the order	Copy of the order, the communication sent in response and the date it was completed	Order not acted on in full, or only part of the affected population contacted after the order

When the encryption and other exemptions actually apply

Article 34(3) lists three situations in which the controller does not have to tell individuals directly: the data were rendered unintelligible to anyone not authorized to access them, later measures mean the high risk is no longer likely, or direct communication would involve disproportionate effort. Each one is a claim the controller must be able to prove to a supervisory authority, so the question to answer before relying on any of them is what evidence would survive scrutiny. Encryption is the most common argument and the easiest to overstate. Encryption helps only if the decryption keys were not also taken. A breach in which the attacker obtained both the ciphertext and a usable key has not made the data unintelligible in any meaningful sense. Confirm where keys are held, who can read them, and whether the incident could have exposed them. Nextcloud's server-side encryption, for example, keeps keys on the server and protects file contents at rest, but it does not encrypt file names or folder structure. A breach of such a server may therefore expose sensitive information in names and paths even when contents are unreadable. Check which data sits outside the encrypted scope before treating the whole dataset as unintelligible.

The later-measures exemption requires showing that the risk actually fell, not that the controller hopes it did. Typical evidence includes forced credential resets, revoked tokens, confirmed deletion of exfiltrated copies with verification, and logs showing the attacker's access ended. Keep the timeline of those steps, since an assessor will compare it with the moment the breach was identified. The disproportionate-effort exemption is the narrowest: it applies only where contacting each person is genuinely impractical, and a public communication must still be made in its place. Decide early which route you would take, and record the reasoning in the breach file so that the choice is documented before the pressure of the incident sets in.

Evidence that shows Article 34 was met

Article 34 is tested by what the controller can show after the fact: why it decided to communicate or not, who received a notice, and what was said. The cards below cover the artifacts an assessor or supervisory authority will ask for, and the routine that keeps them usable when an incident happens.

High-risk assessment record

A dated record of the risk judgment that decided whether Article 34 applied, written by the people who made it. It should list the categories of data, the number and type of individuals, the likely consequences, and the reasoning for the outcome. Check that the record shows when the assessment was made, because a later revision should be visible rather than overwritten. Without this record, a decision not to communicate is hard to defend.

Notice template and sent notices

Keep the approved notice template, the version history of changes, and a copy of each notice as it was actually sent. Each copy should carry its send date and the recipient group it reached. The content should match the elements Article 34(2) names: plain-language nature of the breach, contact details, likely consequences, and measures taken or proposed. Confirm that a reviewer can compare the template against each sent copy.

Distribution logs

Logs showing which channel delivered each notice, when it was sent, and whether it bounced or was returned. Postal, email and in-app notices each leave different traces, so record the method used for each group. Retain failed attempts and any follow-up, since an assessor will ask how the controller tried to reach people it could not contact directly.

Affected individuals list and method

The register of the people notified, together with a note of how it was built from the source systems. Explain which logs, backups or database extracts were queried, and how duplicates and unknown individuals were handled. Include people who were not controllers' direct customers but whose data was also taken, such as persons referred to in a dataset. The CNIL's 2026 decision against Hôpital Privé de la Loire found a failure to inform 202,246 people designated as trusted third parties whose data were also stolen.

Exemption decisions with proof

When the controller relies on Article 34(3), keep the evidence for each exemption. For encryption, record the algorithm, key location, and proof that the keys were not compromised. For later measures, keep the timeline showing the risk fell away. For disproportionate effort, record the cost estimate and why a public notice was used instead. An exemption without proof is treated as no exemption.

Public notices and supervisory correspondence

Keep any public communication, its publication location and dates, and every exchange with the supervisory authority about the breach. If an authority ordered communication under Article 34(4), file the order, the controller's response, and the proof that notices followed. Store these alongside the Article 33 notification so the sequence of events can be reconstructed from one place.

Using DFIR-IRIS and OpenBao to support the evidence

DFIR-IRIS is an open-source incident response case management platform licensed under LGPL-3.0-or-later. Its main value for Article 34 work is that it keeps the facts of one breach in one case: which systems were involved, which indicators were found, what tasks were done and by whom, and how the picture changed over time. When a controller must decide whether affected individuals need to be told, the reasoning depends on exactly these facts, and a case record with an audit trail is far easier to defend than scattered chat messages and spreadsheets.

Assets and affected records: Record the systems and data stores involved as assets in the case so the team can link each one to the categories of data and the individuals affected.
Consolidated timeline: Build the investigation timeline inside the case, so the date the controller became aware and the dates of containment and remediation can be shown with the supporting alerts.
Alert intake: Triage alerts from SIEM, EDR and REST sources into cases, which helps show when the breach was first detected.
Evidence handling: Log evidence with SHA-256 verification and chain of custody, so extracts used in a communication or regulator briefing can be traced back to their source.
Report generation: Generate reports from case data, then have legal and the data protection officer review the wording before anything goes to individuals.

Before relying on the case record, confirm that the version you deploy supports the integrations, retention and access controls your SIEM, EDR and identity systems require.

Where organizations fall short on Article 34

Most Article 34 failures are not about whether a notice was sent. They come from gaps in who gets told, how the high-risk decision is made and recorded, and whether the notice can reach people quickly. Each card below pairs a gap with the check or fix that closes it.

Omitting indirect data subjects

Breach scoping often counts only the customers or patients in the primary database. Data about trusted third parties, emergency contacts, guarantors or employees' dependants can sit in other tables, exports or logs and still be exposed. Check every system in the incident scope, including backups and support tickets, and build a list of every category of person whose data was taken. Illustrative case: a notice covers patients but not the contacts stored alongside them.

Relying on encryption without key analysis

Article 34(3) excuses notice where data were rendered unintelligible, but encryption only helps if the attacker did not also obtain the keys or a way to unlock them. Server-side encryption that keeps keys on the same server, for example, may not protect data if an attacker reached the server. Document where keys were stored, whether they were exposed, and whether any were rotated. Nextcloud's server-side encryption, for instance, does not cover file names or folder structure, so metadata may still reveal personal data.

No pre-approved notice template

Teams that write a notice from scratch during an incident often produce text that is vague, technical or missing required elements. Article 34(2) requires plain language describing the nature of the breach, contact details, likely consequences and measures taken or proposed. Prepare a template in advance with placeholders for categories of data, contact point, and steps, and have legal and communications review it before any incident. Test the template in a tabletop exercise.

Sending notices without a recorded high-risk decision

Notification to individuals depends on a judgment that the breach is likely to result in high risk. Organizations that send notices without recording that judgment cannot show their reasoning to a supervisory authority, and those that never decide may miss the duty altogether. Record who assessed the risk, the facts used, the time of decision, and the reasons for any exemption. Keep this record in the breach register alongside the notification decision.

No channel for stale contact data

Article 34 requires communication directly to data subjects where feasible, but contact details in CRM, HR or patient systems are often out of date. If a notice bounces or cannot be delivered, the controller still needs a route to the person. Verify which contact fields are current for each affected group, and define in advance a fallback such as registered mail, an in-app message or a public notice. Where direct contact would involve disproportionate effort, Article 34(3) requires a public communication instead, so plan that path too.

Unclear ownership between controller and processor

A processor that suffers a breach must notify the controller, but the controller owns the decision and the notice to individuals. When contracts do not state who drafts the message, who approves it, and who sends it, notices are delayed or sent inconsistently. Agree in the processing contract which party contacts individuals, what information the processor supplies, and how quickly. Confirm that your own runbook matches the contract terms.

Questions buyers ask about Article 34 cost, effort and outside help

Does Article 34 require a certification or audit report?

No. Article 34 does not require a certification, attestation or audit report, and no body issues a certificate for compliance with it. The GDPR as a whole requires no audit or certificate. Certification under Article 42 is voluntary and does not reduce the controller's responsibility for compliance. What a supervisory authority will ask for after a breach is evidence that the controller decided whether individuals had to be told, what it told them, and how it reached each decision. Any outside party you hire can prepare that evidence, but only the controller owns the decision to communicate.

What drives the effort of preparing for Article 34 communications?

The effort depends on how well the organization can answer three questions quickly after a breach: who is affected, what data was exposed, and whether that data was unintelligible to the attacker. Effort rises when personal data sits in many systems, when affected people are not known to the controller directly (for example, people whose data a third party holds), and when no template or contact list exists before an incident. Effort falls when data classification, encryption status and contact routes are documented in advance. Ask any provider to break its estimate into these work items rather than quoting a single figure.

How long does it take to prepare Article 34 communication readiness?

No researched timeline is available for this, so treat any duration you hear as something to verify against your own environment. In general terms, readiness work covers mapping data stores, confirming which systems hold encrypted or pseudonymized data, drafting plain-language notice templates, and rehearsing how contact details are retrieved and how public notices would be published. The duration depends on the size of the estate, the number of data stores, and how many teams must sign off. Ask for a written plan with milestones and dependencies before agreeing to a schedule.

What must our team supply before an implementation partner can help?

A partner needs access to the information only your organization holds. Typically this includes:

A current inventory of systems and data stores that hold personal data, with owners
Documented encryption and key management arrangements, including where keys are held
Existing contact data for individuals, and the rules that govern its use
Your incident response plan, escalation contacts and decision-making authority
Contracts with processors and sub-processors that set notice duties to you

The controller remains responsible for deciding whether a breach is likely to result in high risk and for signing off any communication. Confirm these inputs and the review steps in the written scope.

Can an in-house team prepare for Article 34 without outside help?

Often yes, if the team has the right skills and time. The work is mostly documentation, data mapping and rehearsal, which internal privacy, security and legal staff can do. Outside help becomes more useful when the estate is large, when systems are self-hosted and configured across several environments, or when no one has tested how to reach affected individuals at speed. A common hybrid approach keeps decisions and sign-off in-house while a specialist prepares the technical evidence, such as encryption configuration records and log retrieval procedures. Decide which parts you can own before you request a quote.

What does a fixed-scope DeployOpen engagement for Article 34 cover?

DeployOpen works from a written scope agreed before work starts, so deliverables and timelines are defined in advance. For this topic, a scope may cover preparing self-hosted platforms for breach investigation and evidence handling, configuring encryption and key management in your own infrastructure, and documenting how investigation records support the decision on communicating with individuals. DeployOpen does not issue audit reports or certificates and does not make the communication decision for your organization. Ask for the exclusions in writing, including any legal advice, which is outside the scope of the engagement.

What should we ask for in a quote for Article 34 readiness work?

Ask for a quote that follows from a written scope and lists each work item, the deliverable it produces and who performs it. Request the assumptions behind each item, such as the number of systems, environments and data stores in scope. Clarify what is one-time, such as the initial mapping, templates and rehearsal, and what recurs, such as review after system changes, retesting or retainer support. Confirm who owns the outputs and whether the organization keeps the configuration and documentation after the engagement ends. DeployOpen does not publish a price list, so the quote comes from the agreed scope.

Which DeployOpen services support Article 34 readiness?

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For breach communication readiness, relevant work can include configuring case management for incident records, using encryption features such as Nextcloud server-side encryption where it fits your design, and setting up key management with OpenBao transit encryption. Security testing and private cyber ranges can also rehearse the response. Confirm which of these fit your environment during scoping, since each capability depends on your platform choices.

What meeting Article 34 costs in money and effort

This table breaks down the cost components of preparing to notify data subjects under Article 34, who is paid for each, whether it is one-time or recurring, and what drives it up. Use it to build a quote request and to see where open-source tooling reduces license spend, while people, contact data work and rehearsal remain the larger share of effort.

Cost component	One-time or recurring	Who is paid or who carries the work	Main cost drivers
Communication template and process design	One-time, reviewed on change	Internal legal and privacy team, with an outside adviser if engaged	Number of data categories, languages needed and how many notice variants are required
Contact data inventory and quality work	One-time build, then recurring upkeep	Internal data owners, often with an implementation partner for system mapping	Volume of records, number of source systems, and how many contact fields are missing or outdated
Tooling for notice dispatch and case records	Mostly one-time setup, plus recurring hosting and support	Internal platform team; self-hosted open-source components carry no license fee, but hosting and staff time remain	Whether existing mail, case and logging systems can be reused, and the hosting footprint inside the organization's own infrastructure
Rehearsal and tabletop exercises	Recurring, usually at least yearly and after major changes	Internal incident response, privacy, communications and executive participants	Number of teams involved, number of countries, and whether third parties such as processors take part
Evidence upkeep and breach records	Recurring	Internal compliance staff, with records kept in the same case system used for incident handling	Breach frequency, retention period set by the organization, and how many notices must be traced to a source record
Multi-country and language review	Recurring per breach	Local counsel or in-house staff in each affected country where the organization decides to use one	Number of member states where data subjects are located and the number of languages required
External review of templates and process	Optional, periodic or per engagement	Independent counsel, consultant or auditor; DeployOpen prepares systems and evidence but does not issue opinions or reports	Scope of review, regulatory exposure and whether the review covers the technical controls behind Article 34(3)
Software license spend	Recurring where commercial tools are used	Vendor of any commercial tool; open-source components of the implementation carry no license fee under their licenses	Choice between commercial and open-source components, and support contracts the organization chooses to buy

How DeployOpen prepares Article 34 processes and evidence

DeployOpen helps organizations prepare the technical side of Article 34 communication: how breach notices to affected individuals are triggered, what they must contain, and what evidence shows the controller acted. The organization keeps ownership of its decisions and notices, and DeployOpen implements and documents the systems and records that support them.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
The written scope names the systems that hold personal data and the data subject groups a breach could reach.
Scope also records which notice channels, contact points and encryption controls the organization already operates.
Any third parties, such as trusted partners who also hold data, are listed so their notification path is covered.

How we build

We configure case management so each incident keeps a timeline of decisions on risk and affected individuals.
We set up key management for encrypted data so the controller can show whether data were unintelligible to outsiders.
We build notice templates that map to the required content elements, with fields the response team completes.
Test paths confirm that affected individuals in each data group can be reached through the chosen channel.

How we hand over

Deliverables include a written communication procedure, decision records and the notice templates in use.
Handover covers the evidence set: case records, audit trails, encryption configuration and channel test results.
We document the roles that approve high-risk determinations and the criteria for public communication instead.
Operators receive runbooks to rehearse notices without relying on the implementation team.

How we support

Ongoing support and upgrades are available as a retainer, covering platform changes that affect notice channels.
Periodic exercises can test whether the communication process works within the organization's own timelines.
Confirm with your legal counsel and supervisory authority guidance which notice wording and channels they expect.
Ask any implementation partner to state in writing that the organization, not the partner, decides and issues notices.