How and when must a processor notify a personal data breach to the controller?

Why this question arises at all

Organisations entrust data to many providers, from hosting companies to accounting firms. A breach of the controller’s data may therefore occur in a system that the controller cannot see.

Article 33(2) GDPR devotes a single sentence to this situation. The processor shall notify the controller without undue delay after becoming aware of a personal data breach. The provision does not say what the notification must contain or how to proceed when one event affects the data of many of the provider’s clients.

The controller’s obligations depend on that notification. It is the controller that assesses the risk to individuals and notifies the breach to the supervisory authority, unless the risk is unlikely. It does so without undue delay and, where feasible, not later than 72 hours after becoming aware of the breach (Article 33(1) GDPR). Where the breach is likely to result in a high risk, it also communicates the breach to data subjects (Article 34(1)). It usually learns of a breach in the provider’s system from the provider itself.

In August 2026 the UODO President addressed controllers who had entrusted data to a provider of an electronic medical records system in connection with media reports of a leak at that provider. The UODO President indicated that before turning to the obligations under Article 33(1) and Article 34 the controller should receive from the processor information confirming that the incident concerned data related to its activities. The processor breach notification is therefore the first link in handling the breach.

What has to be established before notification

When the processor’s obligation arises

A processor is a natural or legal person or another body which processes personal data on behalf of the controller (Article 4(8) GDPR). A personal data breach is a breach of security leading to the accidental or unlawful destruction, loss or alteration of data. A breach of security leading to unauthorised disclosure of data or unauthorised access to data is also such a breach (Article 4(12) GDPR).

The obligation arises when the processor becomes aware of the breach. According to the EDPB the processor just needs to establish whether a breach has occurred and then notify the controller. It does not need to first assess the likelihood of risk before notifying, because it is the controller that makes this assessment.

The UODO guide illustrates this with the example of a provider that manages the IT infrastructure of an insurance company and detected a power failure. Analysis confirmed that the failure had prevented access to customer data. The processor then established that an availability breach had occurred and immediately passed the information to the controller. According to the guide processors are obliged to notify controllers of all breaches they become aware of.

Preliminary fact-finding cannot last indefinitely. According to the EDPB the controller’s preliminary actions should in most cases be completed soon after the initial alert and should take longer only in exceptional cases. The initial alert is the moment when the controller or processor suspects there has been a security incident which may involve personal data. The guidelines do not say expressly how long the provider’s fact-finding may take. In my assessment the requirement to complete preliminary fact-finding quickly also applies to the provider, because the guidelines count the initial alert from a suspicion on the part of the processor too. This reading is also supported by Article 32 GDPR, which binds the processor as well. According to the EDPB the ability to detect and address a breach and to report it in a timely manner should be seen as essential elements of the security measures.

It is a mistake for the provider to apply the risk threshold of Article 33(1), that is, to refrain from notifying when it considers the risk unlikely. Article 33(2) provides no exception for breaches where the risk is unlikely. Even a breach that the controller ultimately does not notify to the authority must be entered in its documentation under Article 33(5). Without information from the provider the controller will not record such a breach.

When to send the processor breach notification

The provision requires notification without undue delay and gives no deadline in hours. The EDPB therefore recommends that the processor promptly notifies the controller and provides further information in phases as more details become available. The guidelines link this to the 72-hour deadline within which the controller is to notify the breach to the authority.

The provider should therefore not wait until all the facts are established. In the first hours it contains the event and establishes which clients and systems it concerns. While the scope is still uncertain, it informs the clients with data in the system affected by the event. It makes clear that fact-finding is ongoing. Subsequent messages add the scale and cause of the event and the actions taken. Article 33(4) GDPR provides the same model for the controller’s notification to the authority where the information cannot be provided at the same time.

The provision does not specify the form of the notification. The message should nevertheless leave a record of the date and time of delivery. According to the EDPB the controller should in principle be considered aware of the breach once the provider has informed it of the breach. As a rule a delay by the provider therefore does not shorten the controller’s deadline.

Undue delay is an infringement of Article 33(2) on the provider’s side. It also delays the reaction of data subjects, for example changing a password or placing a reservation on their PESEL number (the Polish national identification number). The controller in turn is responsible for choosing a provider that provides sufficient guarantees (Article 28(1)). According to the EDPB it should also have in place arrangements with any processors it uses. Those processors themselves have an obligation to notify it of breaches (Article 33(2)).

A specific deadline belongs in the agreement. According to the EDPB the contract between the controller and the processor should specify how the requirements of Article 33(2) are to be met. This can include requirements for early notification by the processor. The UODO guide adds that the agreement should clearly set out detailed rules for performing this obligation. Among them it lists the deadlines and methods of passing on information.

Who receives the notification

The addressee is the controller and not the UODO President. Where one event affects the data of several controllers, the processor will have to report details of the incident to each of them. This is how the EDPB puts it for a provider that provides services to many clients.

A controller with data in the system affected by the event needs to know whether the event affected its data and which data it concerns. The provider’s record of categories of processing activities makes it easier to draw up the list of recipients. It names each controller on behalf of which the provider is acting (Article 30(2)(a)), but not every provider has to maintain it (Article 30(5)). Each client should receive a separate message without the names or data of other clients.

A general announcement on the provider’s website does not say whether the data of a specific controller are involved. It therefore does not replace individual notification.

Within the client organisation the notification should reach the person who triggers breach handling, for example the data protection officer. A message sent to a general sales address may wait several days to be read.

What the processor breach notification should contain

Article 33(2) GDPR does not list the elements of the notification. The EDPB links the processor’s role in breach notification to Article 28(3)(f). The contract is to stipulate that the processor assists the controller in ensuring compliance with the obligations pursuant to Articles 32 to 36 taking into account the nature of processing and the information available to the processor.

The point of reference is therefore the notification that the controller will make to the authority. Article 33(3) requires it at least to describe the nature of the breach, including where possible the categories and approximate number of data subjects and of personal data records. It also requires the contact details of the data protection officer or other contact point, a description of the likely consequences and the measures taken or proposed. Initially it is usually only the provider that knows the nature and scale of the breach. It is worth ensuring that the processor breach notification contains the following elements where possible.

1. The notification number and the date and time of detecting the event and of becoming aware of the breach.
2. A description and the type of the event (confidentiality, availability or integrity) and the systems and services concerned.
3. Information on whether the event affected this controller’s data (or ‘fact-finding ongoing’).
4. The categories of data and of data subjects and the approximate number of data subjects and of data records.
5. Information on whether the data were encrypted and whether the keys remained secure.
6. In the case of loss of availability, information on backups and the expected time of restoration.
7. The status of the event, the likely consequences known to the provider and the actions taken and planned by the provider, including notifications to other authorities.
8. A contact person at the provider available during the handling of the breach.
9. Information not yet established and the date of the next update.

The list is a practical proposal and not a catalogue taken from the provision. A minimum scope for the notification is set out in the standard contractual clauses adopted by Commission Implementing Decision (EU) 2021/915. The parties may use these clauses in a data processing agreement. Under Clause 9.2 the notification shall contain at least a description of the nature of the breach, the details of a contact point and the likely consequences of the breach and the measures taken or proposed to address it. Under the same clause information that is not available at once is to be provided later without undue delay. Item 9 of the list allows the controller to notify the breach to the authority in phases, and items 5 and 6 help it assess whether the breach needs to be communicated to data subjects.

What a first notification may look like

This is how a fictitious first processor breach notification sent by a provider of an HR and payroll system may read.

From it the recipient knows whose data and which data the event affected, what the provider does not yet know and when the next information will come.

What to include in the data processing agreement

The agreement makes it possible to turn ‘without undue delay’ into a specific commitment. The UODO guide recommends that the parties agree clear rules for exchanging information about potential breaches. This concerns who notifies the other parties and when and how. It is worth building the breach notification clause from several elements.

1. A deadline for the first notification counted in hours from becoming aware of the breach.
2. An obligation to alert the controller to a suspected breach before it is confirmed, together with a description of what the parties regard as a suspicion.
3. A primary and a backup channel in case the provider’s or the controller’s e-mail is unavailable or compromised.
4. Contact persons on both sides, including outside working hours.
5. A method of confirming the authenticity of the notification, for example a call-back to a known number.
6. The minimum content of the first notification and the frequency of updates.
7. An obligation to pass on information obtained from any sub-processor (another processor engaged by the processor).
8. Cooperation in the analysis, including access to event logs and the right to audit after an incident (Article 28(3)(h)).
9. A decision on whether the provider may notify the breach to the authority or communicate it to data subjects on behalf of the controller.

According to the EDPB the controller may not be regarded as aware during a short period of initial investigation, although the investigation should begin as soon as possible. An early signal of a suspicion therefore gives the controller time to prepare its assessment.

The provider may argue that meeting the contractual deadline amounts to notification without undue delay. According to recital 87 GDPR whether notification was made without undue delay should be established taking into account in particular the nature and gravity of the breach and its consequences and adverse effects for the data subject. The recital concerns notification to the authority and communication to data subjects, that is the controller’s obligations. In my assessment the same criterion applies to the provider, so the contractual deadline is an upper limit. A provider that could have notified the breach earlier should not use up the whole deadline. I recommend a deadline of no more than 24 hours from becoming aware of the breach. Where the controller is itself subject to rules that give it less time to report an incident than the GDPR, it is worth aligning the provider’s deadline with those rules.

What the processor does not do on its own

The processor does not decide for the controller on notification to the authority or on communication to data subjects. According to the EDPB it could make a notification on behalf of the controller if the controller has given it the proper authorisation and this is part of the contractual arrangements. The legal responsibility to notify remains with the controller. According to the UODO guide the processor may notify breaches only after obtaining the controller’s written authorisation.

The UODO guide sets the same conditions for communication to data subjects by the processor. In such a communication the provider must clearly indicate who is the controller and who is the processor. The other requirements are described in How do you notify data subjects of a breach and what must the communication contain?.

Nor does the provider wait passively for the controller’s decisions. According to the UODO guide processors should contain breaches they have become aware of and mitigate their effects within their own remit. In doing so they are to cooperate closely with controllers and follow their instructions.

The event may also affect data for which the provider is itself the controller. Examples are the data of its employees or the contact details of business clients. For those data the provider has its own obligations under Article 33(1) and (5) and Article 34.

What about a sub-processor

The provider may use the services of another entity, for example a data centre or an infrastructure provider. Article 28(4) GDPR requires the same data protection obligations as set out in the contract with the controller to be imposed on the sub-processor. Where the sub-processor fails to fulfil those obligations, the initial processor remains fully liable to the controller.

Article 33(2) names the controller as the addressee of the notification, and the sub-processor also processes data on the controller’s behalf. In practice the sub-processor usually knows only the processor that engaged it and notifies the breach to that processor. In my assessment such a chain is acceptable if the agreements ensure that the information reaches the controller without undue delay. The agreement with the sub-processor should therefore provide for a shorter deadline than the agreement with the controller or for parallel notification of the controller.

What the controller does after receiving the notification

According to the EDPB the controller might also want to investigate the breach, as the provider might not be in a position to know all the relevant facts. An example is a copy of the destroyed or lost data that is still held by the controller. This may affect whether the controller would then need to notify. The UODO guide describes a controller that established after a fire at its provider that it had its own complete backup of the data affected by the fire. According to the guide it therefore rightly did not find a breach. The guide assigns to the controller the verification of the information and the final analysis and classification of the incident. How the deadline is counted in such situations is described in How to count the 72 hours for notifying a personal data breach?.

Nor should the controller wait passively for a message from the provider. According to the EDPB the first information about a potential breach may come from an individual, a media organisation or another source. There is an obligation on the controller to act on any initial alert. Where the controller learns of an event at the provider from another source, it should request confirmation from the provider and check what it can check itself.

After receiving confirmation from the provider the controller analyses the risk to the rights and freedoms of natural persons. Notification to the authority and communication to data subjects depend on that analysis. Irrespective of that Article 33(5) requires any breach to be documented, comprising the facts relating to it, its effects and the remedial action taken.

When the processor is also subject to the KSC Act

A cloud computing service provider, a data centre service provider or a managed service provider may be an essential or important entity. These types of entity are listed in Annex 1 to the Polish Act on the National Cybersecurity System (KSC Act). One event may then trigger obligations under two acts, namely the GDPR and the KSC Act. The processor breach notification follows from the GDPR, and its deadline runs from becoming aware of the breach. The early warning and the significant incident report to the CSIRT follow from Article 11(1)(4) and (4a) of the KSC Act, and their deadlines run from detection of the incident.

The KSC Act also imposes its own obligation towards clients. An essential or important entity informs the users of its services of a significant incident that adversely affects the provision of those services (Article 11(2b)). That information has a different threshold and purpose from the notification under Article 33(2) GDPR, so it does not replace it. Nor does either of these messages replace the report to the CSIRT. The EDPB already described this relationship under the earlier NIS Directive. According to its example a cloud service provider notifying a breach under that Directive may also need to notify a controller. This applies where the event includes a personal data breach.

An entity has 12 months to perform the obligations under Chapter 3 of the KSC Act, including those concerning incidents. The period runs from the entry into force of the amendment on 3 April 2026 if the entity met the criteria at that time (Article 33(1) of the amending act). In other cases it runs from meeting the criteria (Article 16(1) of the KSC Act) or from service of the decision on recognition (Article 7l(7)(1) and Article 7m(6)(1)). Former operators of essential services were to start reporting significant incidents under the new rules within 6 months of the entry into force of the amendment, that is by 3 October 2026 (Article 33(4) of the amending act). The content of reports to the CSIRT is described in What does a significant incident report to a CSIRT contain?.

Division of tasks after a breach at a processor

The GDPR provisions cited in the table apply from 25 May 2018 (Article 99(2)).

Action	Who	Basis	Exceptions and limits	Since when
Establishing whether a breach has occurred	processor	Article 32 and Article 33(2) GDPR; EDPB Guidelines 9/2022, paragraphs 36, 41 and 44	no obligation to assess the risk before notifying; short preliminary fact-finding (in the author’s view, cf. EDPB paragraph 36)	from the suspicion of an incident
Notification to the controller	processor	Article 33(2) GDPR; EDPB Guidelines 9/2022, paragraphs 45–47	covers every breach the processor becomes aware of, including where the risk is unlikely; no deadline in hours; in the author’s view the contractual deadline is an upper limit	from the processor becoming aware of the breach
Notification to the processor that engaged it	sub-processor	Article 28(4) GDPR and the agreement	Article 33(2) names the controller as the addressee; in the author’s view acceptable if the information reaches the controller without undue delay; alternative — parallel notification of the controller; where the sub-processor fails to fulfil its obligations, the initial processor remains liable to the controller for it	from the sub-processor becoming aware of the breach
Assistance with the obligations under Articles 32 to 36	processor	Article 28(3)(f) GDPR	to the extent following from the nature of processing and the information available to the processor	from conclusion of the agreement
Risk assessment and notification to the UODO President	controller	Article 33(1) GDPR	without undue delay and where feasible within 72 hours, after 72 hours with reasons for the delay; no notification where the risk is unlikely; the provider may notify on behalf of the controller with its authorisation set out in the agreement (EDPB paragraph 48); according to the UODO guide only with written authorisation	in principle from receiving the information from the processor (EDPB paragraph 44)
Communication to data subjects	controller	Article 34 GDPR	only where there is a high risk; exceptions in Article 34(3); the provider may communicate on behalf of the controller on the terms set out in the UODO guide	as in the preceding row
Documenting the breach	controller	Article 33(5) GDPR	also covers breaches not notified to the authority	as in the preceding row

Conclusions and next steps

Both parties should then know who passes on the first information and when and by what route.

Steps for the processor.

1. Add the step ‘notification to controllers’ to the incident handling procedure. Designate the person who performs it and their deputy outside working hours.
2. Keep a list of clients with contacts for breach notification and the deadlines from their agreements. If you maintain a record under Article 30(2) GDPR, base the list on it.
3. Check whether you can establish within a few hours the list of clients with data in the system affected by the event.
4. Prepare a template for the first notification and a template for updates.
5. Check the notification deadlines in your agreements with sub-processors. Where an agreement cannot be negotiated, take the sub-processor’s deadline into account when setting the deadline towards clients.

Steps for the controller.

1. Compare your data processing agreements with the elements of the breach notification clause and fill the gaps by way of an amendment. Where the provider does not accept changes, assess its standard terms and record that assessment.
2. Give providers an address that is read by the person responsible for breach handling.
3. Establish who on your side receives a notification outside working hours.
4. Establish what you do when you learn of an event at a provider from the media or from its website.

Related materials

• How to count the 72 hours for notifying a personal data breach? — from when the controller counts the deadline after information from the provider.
• Does every data breach need to be reported? — the risk assessment that the controller carries out after the notification.
• How do you notify data subjects of a breach and what must the communication contain? — the content of the communication and the provider’s role in sending it.
• What should a personal data breach register contain? — the breach entry, including a breach not notified to the authority.

Sources

• Regulation (EU) 2016/679 of the European Parliament and of the Council (GDPR), consolidated version — Article 4(8) and (12), Article 28(1), (3)(f) and (h) and (4), Article 30(2)(a) and (5), Articles 32–36 and Article 99(2) — eur-lex.europa.eu.
• Regulation (EU) 2016/679 (GDPR), version as published in OJ EU L 119 of 4 May 2016 — recital 87 — eur-lex.europa.eu.
• Act of 5 July 2018 on the National Cybersecurity System, consolidated text as at 18 August 2026 — Article 7l(7)(1), Article 7m(6)(1), Article 11(1)(4) and (4a), Article 11(2b), Article 16(1) and Annex 1 (in Polish) — isap.sejm.gov.pl.
• Act of 23 January 2026 amending the Act on the National Cybersecurity System and certain other acts (Journal of Laws 2026, item 252) — Article 33(1) and (4) and Article 49 (in Polish) — isap.sejm.gov.pl.
• Commission Implementing Decision (EU) 2021/915 of 4 June 2021 on standard contractual clauses between controllers and processors under Article 28(7) of Regulation (EU) 2016/679 — Article 2 and Annex, Clause 9.2 — eur-lex.europa.eu.
• Personal Data Protection Office (UODO), Guide on personal data breaches, version of 20 February 2025 — sections 5.1, 5.2, 6.1, 9 and 10 (in Polish) — uodo.gov.pl.
• Personal Data Protection Office (UODO), “The controller must notify a leak that occurred at a processor”, announcement of 12 August 2026 (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 34, 36, 38, 40, 41, 43–48 and 136 — edpb.europa.eu.