Let’s talk
Wondering how this plays out in your organisation? Get in touch — I answer personally.
Short answer
The controller sends the breach communication without undue delay to a data subject for whom the breach is likely to result in a high risk to rights and freedoms. According to the EDPB the controller should in principle send it directly to that person, in a dedicated message and preferably through a channel not affected by the breach. Under Article 34(2) GDPR the communication describes in clear and plain language the nature of the breach, its likely consequences and the measures taken or proposed by the controller. It also gives the name and contact details of the data protection officer or another contact point, and according to recital 86 GDPR and the EDPB also recommendations on how the person can mitigate the effects of the breach. The communication is not required where the controller applied appropriate protection measures to the data affected by the breach, in particular measures rendering the data unintelligible to unauthorised persons (for example encryption). Nor is it required where the controller has taken subsequent measures which ensure that the high risk is no longer likely to materialise. Where it would involve disproportionate effort, a public communication or a similar and equally effective measure takes its place. The controller must be able to demonstrate each of these exceptions.
Why this question arises at all
Notification to the President of the Personal Data Protection Office (UODO) and communication to data subjects are two obligations with different thresholds. A breach is not notified to the authority where it is unlikely to result in a risk to the rights and freedoms of natural persons (Article 33(1) GDPR). The obligation under Article 34(1) arises only where the breach is likely to result in a high risk. The EDPB explains that the higher threshold protects individuals from unnecessary notification fatigue.
High risk is determined by the likelihood and the severity of the consequences. The Polish Supreme Administrative Court described this combination in its judgment of 1 October 2025 (III OSK 1830/22). According to the court a likelihood that is not low combined with a high severity of potential impact determines the possibility of a high risk. That combination also determines the obligation to communicate the breach. The risk does not have to materialise. The case concerned an e-mail with an unencrypted attachment containing among other things the first name, surname and PESEL number (the Polish national identification number) of one person, sent to the wrong recipient. The court set aside the first-instance judgment and referred the case back to that court for reconsideration. How to assess the risk is described in Does every data breach need to be reported?.
The second source of doubt is organisational. Several teams usually work on the text at once. The lawyer looks after compliance with the provision and the communications team looks after reputation. Customer service prepares for the questions that will come the next day. Recital 86 GDPR indicates whom the text is meant to serve. The information is to allow the person to take the necessary precautions.
What has to be established before sending the communication
Who sends the communication
The obligation under Article 34(1) GDPR rests with the controller. Joint controllers determine in a transparent manner their respective responsibilities for compliance with the obligations under the Regulation by means of an arrangement between them, unless those responsibilities are determined by Union or Member State law to which they are subject (Article 26(1) GDPR). The UODO guide recommends that they also agree on the division of duties regarding communication to data subjects.
The breach communication may also be sent by a processor. According to the UODO guide this requires the controller’s written authorisation and the matter should be precisely regulated in the contract. Such arrangements do not relieve the controller of ultimate responsibility for the communication. According to the guide the text must then clearly indicate who is the controller and who is the processor acting on its behalf.
It is worth settling this in the contract before a breach occurs. In a large breach at a service provider, negotiating roles and approving the text takes time that the affected persons do not have.
When to send the breach communication
Article 34(1) GDPR requires the communication to be made without undue delay and does not set a deadline in hours. According to the EDPB this means as soon as possible.
Recital 86 GDPR gives an example of how the pace depends on the situation. The need to mitigate an immediate risk of damage would call for prompt communication with data subjects. The need to implement appropriate measures against continuing or similar breaches may justify more time for communication. In a password leak the person’s reaction time is therefore decisive. Only that person will change the password on other services where it was used.
According to recital 86 such communications should be made as soon as reasonably feasible and in close cooperation with the supervisory authority. This is done respecting guidance provided by that authority or by other relevant authorities such as law-enforcement authorities. The EDPB indicates that the controller may also consult the authority on the content of the message and on the most appropriate way to contact the persons.
Recital 88 GDPR indicates that detailed rules and procedures on notification should take into account the legitimate interests of law-enforcement authorities. This concerns a situation where early disclosure could unnecessarily hamper the investigation of the circumstances of the breach. According to the EDPB the controller may then in justified circumstances and on the advice of law-enforcement authorities delay the communication until it would not prejudice the investigation. After that time the persons must be informed promptly.
The communication concerns the persons for whom a high risk has arisen. The UODO guide describes a situation where the breach creates such a risk only for some persons. The controller should then communicate the breach only to those persons. The guide does not recommend informing persons about events without a high risk, because an excess of messages may weaken their significance.
What the breach communication must contain
Article 34(2) GDPR sets the minimum. The communication describes in clear and plain language the nature of the personal data breach. It also contains at least the information and measures referred to in points (b), (c) and (d) of Article 33(3). The text must therefore include four elements.
- A description of the nature of the breach.
- The name and contact details of the data protection officer or other contact point where more information can be obtained.
- A description of the likely consequences of the breach.
- A description of the measures taken or proposed to be taken by the controller to address the breach, including where appropriate measures to mitigate its possible adverse effects.
The reference covers points (b), (c) and (d) but not point (a). Article 34(2) therefore does not expressly require the categories and approximate number of data subjects and of records, which a notification to the authority gives where possible. The description of the nature of the breach is required by Article 34(2) itself. It is nonetheless unwise to omit the categories of the recipient’s data from the communication, because without them it is hard to describe the nature of the breach and its consequences. The UODO guide lists the lack of specific categories of data affected by the breach among the defects of a communication.
Recital 86 GDPR and the EDPB indicate one more element that the provision does not list expressly. These are recommendations for the person to mitigate potential adverse effects. The EDPB gives the example of resetting passwords where access credentials were compromised. The UODO guide also mentions placing a reservation on the PESEL number and monitoring suspicious transactions.
The guide proposes a broader scope of content than the minimum set by the provision. It includes among other things basic information about the controller and other entities involved in the incident. It adds the circumstances of the breach. These are the date and time of occurrence and end, the cause, the type and course of the breach and the type and scope of the data. It also points to consequences that have already occurred and not only possible ones.
The guide gives four example types of defects. According to it such defects may delay the response to the incident and increase the risk.
- Illogical and inconsistent information, for example consequences unrelated to the scope of the data.
- Incomplete information, for example no specific categories of data.
- Ineffective information, for example contact details that do not guarantee quick and easy communication.
- Imprecise information, for example an overly general description of the likely consequences.
Skeleton of the breach communication
I recommend a structure that leads the recipient from the facts to action. Each point answers one question that the person will ask after reading the subject line.
- A subject line that immediately says the message concerns a breach of the recipient’s data.
- The sender of the message and, where a processor writes, an indication of both roles.
- What happened and when, in two or three sentences without technical jargon.
- Which of the person’s data the event concerns.
- What may happen, that is consequences matched to the scope of the data.
- What the controller has done and what it will still do.
- What the person can do themselves, starting from the most urgent step.
- How to recognise a genuine message from the controller, for example what it will never ask for.
- The name and contact details of the data protection officer or another contact point, available at the time when the questions will come.
This is how the core part of a communication about a breach of customer data confidentiality may read, without the subject line and sender.
On 12 September an unauthorised person gained access to the mailbox of the customer service department. The mailbox contained correspondence with you that included your first name, surname, e-mail address and PESEL number. These data may be used to impersonate you or to attempt to take out loans or incur other obligations in your name. We have blocked access to the mailbox and notified the breach to the President of the UODO. We encourage you to place a reservation on your PESEL number and to be cautious about messages that refer to our company. In messages about this event we will not ask you for a password or to log in through a link. Please direct any questions to our data protection officer [name and surname] at [e-mail address] or by telephone at [number].
It is worth agreeing the skeleton with the DPO, the lawyer and the communications team. On the day of the breach the facts are then filled in and nobody argues about the structure.
What language to use
The requirement of intelligibility also follows from Article 12(1) GDPR, which covers any communication under Article 34. The controller provides it in a concise, transparent, intelligible and easily accessible form. It uses clear and plain language, in particular when writing to a child. The UODO guide adds that the language is to be adapted to the specific recipient. Where the breach affects different groups of persons in different ways, the controller adapts the content to those groups.
According to the EDPB the language used during the previous normal course of business with the recipient will generally be appropriate. The breach may however affect persons with whom the controller has not previously interacted, or particularly those who reside in a country other than the controller’s country of establishment. Communication in the local national language could then be acceptable, taking into account the resources required. The key is that the person understands the nature of the breach and the steps they can take to protect themselves.
In practice the obstacle is usually the vocabulary of the notification to the authority. Phrases such as ‘confidentiality breach’, ‘exfiltration’ or ‘attack vector’ say little to the recipient. The sentence ‘someone without authorisation copied a file with your contact details and PESEL number’ says more than a paragraph of terminology.
Which channel to use for the communication
The breach communication is in principle sent directly. The EDPB recommends dedicated messages. They should not be sent with other information, such as regular updates, newsletters or standard messages. The UODO guide puts it more strongly. According to it controllers may not combine the content of communications with other messages, for example advertisements or newsletters.
The EDPB lists examples of transparent methods. The first is direct messaging, for example e-mail and SMS. Others are prominent website banners or notifications, postal communications and prominent advertisements in print media. A notification solely confined within a press release or corporate blog would not be an effective means of communicating a breach. The EDPB recommends the methods that maximise the chance of reaching all persons. Depending on the circumstances this may mean several channels.
According to the UODO guide the recipient must be able to read the content more than once. The communication should therefore in principle be in writing, and e-mail and SMS provide that possibility. It may be provided orally at the person’s request, provided that the person’s identity is proven by other means (Article 12(1) GDPR).
The channel should also be secure. The EDPB warns against a channel compromised by the breach. Attackers may use it to impersonate the controller. Where a mailbox or customer database has been taken over, it is reasonable to assume that the persons will also receive fake communications. A sentence on what the controller will never ask for helps. So does leaving out login links from the text.
Sometimes the chosen method does not work. The UODO guide then recommends other means of communication. If those fail too, the controller should ensure that the communication can be delivered in the future, at the earliest possible opportunity. The EDPB also describes the specific case of a person for whom the controller does not hold sufficient contact data. The controller should then inform that person as soon as it is reasonably feasible. An occasion may be the person exercising the right of access under Article 15 GDPR and providing contact details.
When a public communication is enough
The exception in Article 34(3)(c) GDPR releases the controller from individual communication where it would involve disproportionate effort. The controller then issues a public communication or applies a similar measure whereby the persons are informed in an equally effective manner. The UODO guide stresses that this exception removes the obligation only as regards individual communication.
The EDPB gives examples of contact details lost as a result of the breach and of a situation where they were never known. The guide describes a fire that destroyed the paper records of several thousand customers. The controller had no copies and could not restore the contact details, and gathering them again would have involved disproportionate effort. It therefore issued a communication on its website and in local newspapers.
According to the UODO guide a public communication must give each person a real chance to read the content. The guide gives examples of a prominent place and long-term availability. The EDPB additionally allows technical arrangements that make information about the breach available on demand.
In my assessment the exception in point (c) may cover only some of the persons. On that reading the controller notifies directly the persons whose contact details it knows and addresses the public communication to the others.
When the breach communication is not required
Article 34(3) GDPR provides two further exceptions. Under point (a) the communication is not required where the controller has implemented appropriate technical and organisational protection measures and applied them to the data affected by the breach. These are in particular measures such as encryption that render the data unintelligible to unauthorised persons. Under point (b) the communication is not required where the controller has taken subsequent measures which ensure that the high risk is no longer likely to materialise.
For encryption the EDPB refers to the conditions described by the Article 29 Working Party. The conditions are met where the data were encrypted with a state-of-the-art algorithm and the key was not compromised in any security breach. The key must also have been generated so that no unauthorised person can ascertain it by available technical means. The data are then in principle unintelligible. If the controller does not have adequate backups, the loss or alteration of encrypted data may still adversely affect the persons. According to the EDPB the communication would then be required even if the data were adequately encrypted. The assessment may also change later. According to the EDPB the risk must be re-evaluated if the key turns out to be compromised or the encryption software or algorithm turns out to be vulnerable.
For point (b) the EDPB gives an example that depends on the circumstances of the case. The controller immediately identified the person who had accessed the data and took action against that person before the data could be used. Even then due regard must be given to the possible consequences of the breach of confidentiality and to the nature of the data.
Each of the three exceptions must be capable of being demonstrated. The EDPB derives this from the accountability principle in Article 5(2) GDPR. The exceptions in Article 34(3) concern communication to data subjects, while notification to the authority is governed separately by Article 33(1).
Where the controller has not yet communicated the breach to the person, the President of the UODO may under Article 34(4) GDPR require it to do so, having considered the likelihood of a high risk. The authority may also decide that one of the conditions in paragraph 3 is met. The power to order the communication is conferred on it by Article 58(2)(e). In the case in which judgment III OSK 1830/22 was given, the President of the UODO ordered in the contested decision that the person be notified within three days of service of the decision.
| Situation | What the controller does | Basis | Exceptions and limits | Since when |
|---|---|---|---|---|
| High risk, contact details known | communicates the breach directly to the person in a dedicated message | Article 34(1) and (2) GDPR, EDPB Guidelines 9/2022, paragraphs 88–92 | delay on the advice of law-enforcement authorities (recital 88, EDPB paragraph 95); exceptions in Article 34(3)(a) and (b) | provision since 25 May 2018, guidelines version 2.0 since 28 March 2023 |
| High risk, contact would involve disproportionate effort | issues a public communication or applies a similar and equally effective measure | Article 34(3)(c) GDPR, EDPB Guidelines 9/2022, paragraph 97 | the exception covers only individual communication; the communication must give a real chance to read the content (UODO guide, sections 10.1–10.2) | provision since 25 May 2018, guide version of 20 February 2025 |
| High risk, data unintelligible to unauthorised persons | does not communicate the breach and documents the basis | Article 34(3)(a) GDPR, EDPB Guidelines 9/2022, paragraphs 76–79 and 97 | the confidentiality of the key must remain intact; lack of adequate backups may restore the obligation | provision since 25 May 2018, guidelines version 2.0 since 28 March 2023 |
| High risk no longer likely to materialise after subsequent measures | does not communicate the breach and documents the basis | Article 34(3)(b) GDPR, EDPB Guidelines 9/2022, paragraphs 97–98 | the risk is re-evaluated when new information emerges; the authority may require the communication (Article 34(4)) | provision since 25 May 2018, guidelines version 2.0 since 28 March 2023 |
When another provision applies alongside the GDPR
Providers of telecommunications services are subject to a separate procedure. Under Article 402(4) of the Polish Electronic Communications Law the provider notifies without delay the subscriber or end user who is a natural person where the personal data breach may adversely affect their rights. This threshold differs from the high risk under the GDPR. The notification is made on the terms set out in Commission Regulation (EU) No 611/2013. It is not required if the provider has demonstrated the implementation of technological protection measures specified in that Regulation and their application to the data affected (Article 402(7)). Those measures must render the data unintelligible to unauthorised persons. The provider demonstrates that these conditions are met by promptly submitting the relevant documentation to the President of the UODO (Article 402(8)).
Article 95 GDPR concerns processing in connection with the provision of publicly available electronic communications services in public communication networks. In matters for which the provider is subject to specific obligations with the same objective set out in Directive 2002/58/EC, the GDPR does not impose additional obligations on it. In my assessment, where a breach concerns data processed in connection with the provision of publicly available telecommunications services, the communication therefore follows the Electronic Communications Law. On that reading Article 34 GDPR applies to the provider’s other data, such as HR data.
An essential entity or important entity may also have a separate obligation under Article 11(2b) of the Polish Act on the National Cybersecurity System (KSC). It then informs the users of its services of a significant incident that adversely affects the provision of those services. This obligation does not depend on whether the incident involved personal data. One event may therefore require two messages with different content, and the groups of recipients need not be the same.
Union or Member State law may also restrict the obligation under Article 34 by way of a legislative measure on the basis of Article 23(1) GDPR. The restriction must respect the essence of the fundamental rights and freedoms. It must be a necessary and proportionate measure in a democratic society. It must also safeguard one of the objectives listed in that provision, for example public security.
What to keep in the documentation
Under Article 33(5) GDPR the controller documents any personal data breach, comprising the facts relating to it, its effects and the remedial action taken. I recommend describing in the same entry the communication to data subjects or the reasons why it was not sent. It is worth keeping the text of each version of the communication and the list of recipients and recording the channel, date and time of sending. It is also worth recording the persons the message did not reach and further attempts to contact them. Where an exception in Article 34(3) applies, the documentation keeps the justification and evidence, for example confirmation of the state of encryption and keys. The other elements of the entry are described in What should a personal data breach register contain?.
Conclusions and next steps
Remember
The quality of a breach communication is usually decided by preparations made before the event.
On the day of the breach there is no time to settle roles, a template and a channel.
- Prepare the skeleton of the communication and agree it with the DPO, the lawyer and the communications team.
- Establish who decides whether to send the communication and who approves its content.
- Check whether the persons’ contact details are up to date and through which channel you will reach each group.
- Designate a backup channel in case the main one is affected by the breach.
- Set out in contracts with processors who prepares and sends the communication.
- Record in the procedure how you document the sending or the use of an exception.
Related materials
- Does every data breach need to be reported? — the notification threshold and the risk assessment on which the obligation to notify data subjects depends.
- How to count the 72 hours for notifying a personal data breach? — the deadline for notification to the authority, which runs in parallel.
- What should a personal data breach register contain? — the breach entry, including the communication or its absence.
- What to do after detecting an incident? — the order of actions in the first 24 hours after the event.
Sources
- Regulation (EU) 2016/679 of the European Parliament and of the Council (GDPR), consolidated version — Article 5(2), Article 12(1), Article 15, Article 23(1), Article 26(1), Article 33(1), (3) and (5), Article 34, Article 58(2)(e) and Article 95 — eur-lex.europa.eu.
- Regulation (EU) 2016/679 (GDPR), version as published in OJ EU L 119 of 4 May 2016 — recitals 86 and 88 — eur-lex.europa.eu.
- Act of 12 July 2024 – Electronic Communications Law, consolidated text as at 7 July 2026 — Article 402(4), (7) and (8) (in Polish) — isap.sejm.gov.pl.
- Act of 5 July 2018 on the National Cybersecurity System, consolidated text as at 18 August 2026 — Article 11(2b) (in Polish) — isap.sejm.gov.pl.
- Judgment of the Supreme Administrative Court of 1 October 2025, III OSK 1830/22, Central Database of Administrative Court Judgments (in Polish) — orzeczenia.nsa.gov.pl.
- Personal Data Protection Office (UODO), Guide on personal data breaches, version of 20 February 2025 — sections 6.1 and 10 (in Polish) — uodo.gov.pl.
- European Data Protection Board, Guidelines 9/2022 on personal data breach notification under GDPR, version 2.0 adopted 28 March 2023 — paragraphs 76–79, 82–83 and 87–98 — edpb.europa.eu.
Let us agree who notifies data subjects and how
The text, the channel and the division of roles are best settled before the event. Incident consultation and organisation of the response process covers the risk assessment, a recommendation on notifying data subjects and the preparation of communication with them.
This material is general and educational in nature. It is not an individual legal opinion or a recommendation for any specific organisation. The scope of the obligations should be assessed against the situation of the organisation concerned.
Legal status: October 2026.