- Article 33 of the GDPR says when a breach goes to the supervisory authority.
- Article 34 says when the people whose data it was must be told.
- The clock in Article 33(1) is “where feasible, not later than 72 hours”.
It usually starts with something small. A support agent notices that one customer can see another customer’s invoice. An export lands in the wrong inbox. A storage folder turns out to have been open to anyone with the link. Within the hour, someone senior asks two questions: whose data was it, and who do we have to tell?
The rules behind the second question are Articles 33 and 34 of Regulation (EU) 2016/679, the General Data Protection Regulation. This guide sets out what those two articles say, in plain terms, with the source linked next to each legal fact.
It is not legal advice, and it does not tell you whether your product or your company meets the law. That judgement is yours and your advisers’ to make. If your customers also ask about incident reporting under the NIS2 Directive, NIS2, for product leaders who sell to regulated customers covers that separate regime. This guide stays with personal data.
What counts as a breach
The regulation defines it in Article 4(12): a “personal data breach” means “a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed”.
Two words in that sentence matter for a product. “Accidental” means no attacker is needed: a wrong permission or a misdirected email can be enough. And “destruction” and “loss” mean that data nobody saw can still count, if it is gone.
Telling the supervisory authority
Article 33 is headed “Notification of a personal data breach to the supervisory authority”. Its first paragraph sets the clock. The controller “shall without undue delay and, where feasible, not later than 72 hours after having become aware of it, notify the personal data breach to the supervisory authority competent in accordance with Article 55, unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons.”
The same paragraph covers a late notice: “Where the notification to the supervisory authority is not made within 72 hours, it shall be accompanied by reasons for the delay.”
Read the sentence slowly. The clock runs from when the controller became aware, not from when the breach began. The duty applies unless the breach is unlikely to result in a risk, so deciding that no notice is needed is itself a judgement to be made and recorded. The controller is the person or body that decides why and how the data is processed (Article 4(7)). If you process data on behalf of your customers instead, Article 33(2) says “the processor shall notify the controller without undue delay after becoming aware of a personal data breach.”
What the notice must contain
Article 33(3) says the notification shall at least:
- describe the nature of the breach, “including where possible, the categories and approximate number of data subjects concerned and the categories and approximate number of personal data records concerned”;
- give the name and contact details of the data protection officer “or other contact point where more information can be obtained”;
- describe “the likely consequences of the personal data breach”;
- describe the measures taken or proposed to address the breach, “including, where appropriate, measures to mitigate its possible adverse effects”.
Not everything will be known on the first day, and the article allows for that. Article 33(4): “Where, and in so far as, it is not possible to provide the information at the same time, the information may be provided in phases without undue further delay.”
There is one duty that applies to every breach, notified or not. Under Article 33(5), the controller “shall document any personal data breaches, comprising the facts relating to the personal data breach, its effects and the remedial action taken.”
Telling the people affected
Article 34 is headed “Communication of a personal data breach to the data subject”. The threshold is higher than in Article 33: “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.”
The message itself, under Article 34(2), “shall describe in clear and plain language the nature of the personal data breach” and contain at least points (b), (c) and (d) of Article 33(3): the contact point, the likely consequences, and the measures taken or proposed.
Article 34(3) lists three conditions under which this message is not required:
- the controller had applied appropriate protection measures to the affected data, “in particular those that render the personal data unintelligible to any person who is not authorised to access it, such as encryption”;
- the controller has taken later measures which ensure that the high risk “is no longer likely to materialise”;
- “it would involve disproportionate effort”. In that case “there shall instead be a public communication or similar measure whereby the data subjects are informed in an equally effective manner.”
And the decision is not only the controller’s. Under Article 34(4), if the people affected have not been told, the supervisory authority “may require it to do so or may decide that any of the conditions referred to in paragraph 3 are met.”
Three product questions
Whether there is a risk, or a high risk, is a legal judgement. What a product can do is make sure the people making that judgement have facts to work with, fast. Three questions, answered before the first incident, carry most of the weight.
Who decides? Name the person or role who is told first, who judges the risk, and who sends the notice. Write down how they are reached outside office hours. A 72-hour clock does not wait for Monday.
What can the product tell them? Article 33(3) asks for categories and approximate numbers of people and records. Ask now whether your product could answer “whose data, which fields, since when” within a day. If it cannot, that is a product gap worth closing on its own terms. Your customers ask the same question when they want to know who changed what in their account, and showing your customers who changed what is a use case built around that answer.
Who writes to the people affected? Article 34(2) asks for clear and plain language. Decide who owns that message and which channel reaches your users: email, the product itself, or both. A draft written in a calm week reads better than one written in a hard one.
Answer those three once, and the first hours of an incident become a sequence of known steps rather than a search for owners. You can lift your eyes from the alarm to the people it concerns.
Where we come in
We do not advise on the GDPR, and we promise nothing about whether your product meets Articles 33 and 34. That call stays with you and your advisers.
What we can do is build the changes to your product that you decide on. The work lands in your own code repository. The code we build for you is yours. You decide what ships. Nothing reaches your users without your approval.
It starts with a conversation, with no obligation.
