What must the controller do when a provider reports a personal data breach?

Why this question arises at all

Article 33(2) GDPR devotes one sentence to the processor. After becoming aware of a breach it notifies the controller without undue delay. The rules entrust notification to the supervisory authority and communication to data subjects to the controller. The GDPR does not set out the order of actions between the message from the provider and the notification.

In August 2026 the President of the UODO issued an announcement entitled “The controller must notify a leak that occurred at the processor”. It was addressed to controllers that had entrusted data to the provider of the MyDr electronic medical records system. It recalled that an analysis of the risk to the rights or freedoms of natural persons is necessary. Notification to the authority and communication to data subjects depend on its outcome.

What has to be established after the provider’s message

The controller establishes the scope of the event in its own data and the moment of becoming aware of the breach. It also limits the effects on its own side at once. It then assesses the risk and decides on notification and communication. Whatever the outcome, it documents the breach. Where the event is also an incident within the meaning of the Polish KSC Act (Article 2(5)), an essential or important entity classifies it against the thresholds for a significant incident (Article 11(1)(3)). It submits an early warning of a significant incident to the competent sectoral CSIRT without delay and no later than 24 hours after its detection. It submits the incident notification without delay and no later than 72 hours after detection (Article 11(1)(4) and (4a)). A controller that is a trust service provider notifies a significant incident to the competent sectoral CSIRT without delay and no later than 24 hours after detection (Article 11(1a)). All these deadlines run from the detection of the significant incident and not from becoming aware of the personal data breach. These obligations do not apply in the banking and financial market infrastructure sectors (Article 8i(1)). The thresholds for a significant incident differ from the risk threshold in Article 33(1) GDPR. A controller subject to these obligations therefore classifies the incident against the thresholds and separately assesses the risk under Article 33(1) GDPR, because one assessment does not replace the other.

Did the breach at a provider cover the controller’s data

The first question concerns scope. According to the announcement of the President of the UODO of 12 August 2026, before proceeding with the obligations under Article 33(1) and Article 34 the controller should receive from the processor information confirming that the incident concerned data connected with its activity. A general message about an “incident in our systems” does not contain such information.

The controller has a basis for requesting it. The data processing agreement must stipulate that the processor assists the controller in ensuring compliance with the obligations pursuant to Articles 32 to 36 GDPR. That assistance takes into account the nature of processing and the information available to the provider (Article 28(3)(f)). The first answers may therefore be incomplete. The EDPB recommends that the provider promptly notifies the breach and provides further information in phases as more details become available (paragraph 45).

It is worth including four requests in the first question to the provider.

• confirmation whether the event covered the data entrusted by this controller, with the categories and approximate number of individuals and records;
• a description of what happened and whether the data reached unauthorised persons or only became unavailable;
• information on the actions the provider has taken and on the timing of further findings;
• the period during which the data were exposed and the accounts and keys that may have been compromised.

These questions help to gather the information that the controller provides in its notification to the President of the UODO (Article 33(3)). The request is best sent through the contact channel named in the agreement, which leaves a record with the date and time. The same channel should be used to confirm that the message about the breach really comes from the provider, because high-profile leaks are sometimes exploited to impersonate providers.

When the breach occurred at a sub-processor

A service provider often engages further processors, for example a data centre or a cloud computing service. The provider must impose on such a sub-processor the same data protection obligations as it has towards the controller (Article 28(4)). Where that sub-processor fails to fulfil them, the initial provider remains fully liable to the controller for the performance of the sub-processor’s obligations.

In practice the controller addresses its questions to its own provider, which is liable to it for the sub-processor. The controller’s obligations under Articles 33 and 34 do not change.

When the controller starts counting the 72 hours

According to the EDPB the controller uses the processor to achieve its own purposes. Therefore in principle the controller should be considered aware once the provider has informed it of the breach (Guidelines 9/2022, paragraph 44). The UODO guide adopts the same rule and adds that the controller remains responsible for verifying the information and for the final analysis and classification of the incident.

The announcement of the President of the UODO can be read as if the deadline started only with confirmation of the scope. It is safer to count the 72 hours from the provider’s first message about the breach, even when the confirmation has not yet arrived. A mere message that the provider is investigating a suspected incident is usually not yet information about a breach. According to the EDPB, however, preliminary actions after such an initial alert should in most cases be completed soon (paragraph 36). The message can be information about a breach when it already gives a reasonable degree of certainty that data have been compromised (paragraph 31). The UODO guide does not accept waiting for the end of an investigation or for complete information as a justification for delay. Where information is missing it points to an initial notification followed by a supplement (example 9.2.1).

The opposite also happens. The controller learns of the event from the media or from a patient before the provider writes to it. The EDPB then allows a short period of investigation during which the controller is not yet regarded as aware. The investigation should, however, begin as soon as possible. In most cases it should be completed soon after the initial alert and take longer only in exceptional cases (paragraphs 34 and 36).

In my assessment the provider’s silence does not extend the preliminary investigation after an alert from another source. Where the controller has a reasonable degree of certainty that the event covered its data, it becomes aware of the breach even without confirmation from the provider. This reading is supported by paragraph 31 of the guidelines, that is a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised. Paragraph 34 also links the start of a short investigation to the first information from an individual, a media organisation or another source. Against it stands the announcement of the President of the UODO, according to which the controller should receive from the provider information confirming that the incident concerned its data before performing its obligations. On the reading based on paragraphs 31 and 34 the absence of confirmation before the 72 hours expire does not hold back the notification. Unless the risk is unlikely, it is safer to submit an initial notification and supplement it without undue further delay after the provider’s answers (Article 33(4), UODO guide 9.2). The notification should state that the scope of the data is awaiting the provider’s confirmation and give the date of the questions. Whichever reading is adopted, it is worth recording when the questions were sent to the provider and when the answers arrived.

According to the UODO guide the deadline also runs at weekends and on other non-working days. Detailed counting of the deadline is described in How to count the 72 hours for notifying a personal data breach?.

What the provider does not know and the controller must assess

According to the EDPB the provider does not need to first assess the likelihood of risk before notifying the breach to the controller. It just needs to establish whether a breach has occurred and notify it. It is the controller that must make this assessment on becoming aware of the breach (paragraph 44).

The controller knows more about its data than the provider. It knows whether the data concern patients, children or employees. It knows what data it entered into the system and whether it holds a copy. The EDPB lists risk assessment factors, among them the type of breach and the nature, sensitivity and volume of personal data. Ease of identification of individuals, severity of consequences and the number of affected individuals also count (paragraphs 106 to 118). Two factors concern the individuals and the controller itself, so the controller usually knows them better than the provider. The first is special characteristics of the individuals, for example children. The second is special characteristics of the controller, for example a medical organisation (paragraphs 116 and 117). If in doubt, the controller should err on the side of caution and notify (paragraph 119).

The EDPB adds that the controller might want to investigate the breach itself, as the provider might not be in a position to know all the relevant facts. An example is a copy of the data destroyed or lost by the provider that the controller still holds. It may affect whether the controller would need to notify (paragraph 44). The UODO guide describes a fire at the provider’s servers holding backup copies. The controller established that it held its own complete copy of that data and according to the guide rightly did not “become aware” of a breach (example 5.2.4). A copy limits the effects of loss or destruction of data but does not remove the risk after unauthorised disclosure of or access to the data. Even in the case of loss it does not always close the matter. In its part on encryption the EDPB states that the loss of encrypted data may still be a reportable breach despite a backup. This depends on the time taken to restore the data and the effect that lack of availability has on individuals (paragraph 79).

According to the UODO guide controllers should know the risk assessment process well enough to supervise it and to take the final decisions themselves in every case. They must also be ready to demonstrate that they assessed the risk properly and acted on that basis. For encrypted data the EDPB notes that the situation may change over time and the risk would have to be re-evaluated (paragraph 78). Every new piece of information from the provider is worth treating in the same way, for example confirmation of a leak after an earlier message about unavailability of data only.

What the controller does itself before the provider completes its analysis

In its notification to the President of the UODO the controller describes the measures taken or proposed to be taken by itself to address the breach (Article 33(3)(d)). According to the UODO guide remedying breaches applies to all breaches the controller has become aware of, regardless of the outcome of the risk assessment.

The controller can take some actions on its own side. In practice this means changing passwords and API keys and revoking active sessions in the provider’s service. It also means switching off integrations that fetch or send data. Sometimes access also needs to be restricted until the event is clarified. The UODO guide lists similar containment methods, including blocking accounts and isolating the systems affected by the breach. Some actions in the service can be performed only by the provider, for example forcing a password change for all of the controller’s users. Requests for such actions are best sent through the same channel as the questions, so that a record with the time remains. It is also worth revoking credentials to the controller’s systems that the provider stored, for example service accounts and integration tokens. Each such action is worth recording with the time, because it will go into the notification and the documentation.

Does the provider’s assessment release the controller

It does not. The provider may write that in its view notification to the authority is not needed. For the controller such an opinion is one piece of information for the assessment and not a decision. The basis is paragraph 44 of the guidelines and the UODO guide, which assigns the final classification of the incident to the controller.

The same applies to the provider’s announcement that it “will take care of the notification”. According to the EDPB a processor could make a notification on behalf of the controller if the controller has given it the proper authorisation as part of the contractual arrangements. The legal responsibility to notify remains with the controller (paragraph 48). The UODO guide allows notification by the provider only with the controller’s written authorisation.

Who notifies a breach at a provider to the President of the UODO

The controller notifies, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons (Article 33(1)). According to the EDPB a provider serving multiple controllers affected by the same incident will have to report details of the incident to each of them (paragraph 47). Each of these controllers assesses the risk and, unless the risk is unlikely, notifies the breach in its own name. In a group of companies the obligation lies with each company that is a separate controller. Where companies in the group are joint controllers, the arrangement under Article 26 should determine which of them is responsible for notifying the breach and communicating it to data subjects (EDPB paragraph 42). A company that is a separate controller cannot rely on a notification that another group company submitted in its own name.

The controller does not have to wait for the provider’s full report. Where and in so far as it is not possible to provide the information at the same time, the controller may provide it in phases without undue further delay (Article 33(4)). A notification made after 72 hours must be accompanied by reasons for the delay (Article 33(1)). The UODO guide does not accept as a justification for delay the leave of the person responsible without a substitute arranged or the management’s lack of time to approve the notification (example 9.2.1). The President of the UODO recommends using the notification form template available on the authority’s website. The UODO guide lists the electronic form on biznes.gov.pl, sending the completed form through ePUAP or as a general letter and traditional post.

When to inform data subjects of a breach at a provider

The controller communicates the breach to data subjects without undue delay when it is likely to result in a high risk to their rights and freedoms (Article 34(1)). The communication describes in clear and plain language the nature of the breach and contains at least the information and measures referred to in Article 33(3)(b) to (d) (Article 34(2)). These are the name and contact details of the data protection officer or other contact point. They also include the likely consequences of the breach and the measures described in Article 33(3)(d).

Article 34(3) lists three situations in which the communication is not required. The first concerns appropriate protection measures applied to the data affected by the breach, in particular those that render the data unintelligible to unauthorised persons, such as encryption. The second concerns subsequent measures which ensure that the high risk is no longer likely to materialise. The third concerns disproportionate effort. In that last case there is instead a public communication or a similar measure informing data subjects in an equally effective manner.

In the announcement of 12 August 2026 the President of the UODO gave examples of the content of the communication. Where a PESEL number is involved, the controller may point to the risk of fraudulent loans and recommend restricting the number. Where health data are involved, it may point among other things to the risk of discrimination and propose psychological support in situations of severe stress or anxiety.

The provider may communicate the breach to data subjects on behalf of the controller. According to the UODO guide this requires written authorisation, and the matter should be precisely regulated in the agreement. The controller nonetheless remains ultimately responsible. According to the guide the provider must then state clearly in the communication who the controller is and who is acting on its behalf. The channel and language of the communication are described in How do you notify data subjects of a breach and what must the communication contain?.

How to document a breach at a provider

The controller documents any personal data breaches, comprising the facts relating to the breach, its effects and the remedial action taken (Article 33(5)). According to the UODO guide documentation covers all breaches the controller has become aware of, regardless of the outcome of the risk assessment. The documentation may take the form of a breach register, although according to the guide a separate register is not mandatory.

For a breach at a provider it is worth recording the moment the message was received and the dates of the questions and answers. It is also worth attaching the reasoning behind the risk assessment and keeping all correspondence with the provider. If the controller waited for confirmation from the provider, the reason and length of the wait are worth recording. The documentation must enable the authority to verify compliance with Article 33, so it should also show the moment of becoming aware of the breach. According to the UODO guide the controller should also document an incident found not to be a breach, together with the reason for that decision.

What happens with the provider after the breach

The controller uses only processors providing sufficient guarantees to implement appropriate technical and organisational measures (Article 28(1)). A breach at a provider is a reason to assess those guarantees again. The data processing agreement stipulates that the provider makes available all information necessary to demonstrate compliance with the obligations in Article 28 and allows for audits (Article 28(3)(h)). This includes information on the measures required pursuant to Article 32, which the provider takes in accordance with Article 28(3)(c).

It is also worth checking whether the agreement sets a deadline in hours for notifying a breach and the scope of the first information. According to the EDPB the contract should specify how the requirements of Article 33(2) are to be met (paragraph 46). The provider’s side is described in How and when must a processor notify a personal data breach to the controller?.

The controller’s steps after a breach at a provider

The controller is responsible for all the steps in the table. For the steps under Articles 32 to 36 GDPR the provider assists within the scope of Article 28(3)(f). It also makes available the information necessary to demonstrate compliance with the obligations in Article 28 and allows for audits (point (h)).

Step	Basis	When	Exceptions and limits
Confirmation whether the event covered the controller’s data	Article 28(3)(f) GDPR, announcement of the President of the UODO of 12 August 2026	immediately after the provider’s message	safer not to wait for confirmation before counting the deadline
Establishing the moment of becoming aware	Article 33(1) GDPR, EDPB Guidelines 9/2022 paragraphs 31, 34 and 44	in principle the moment of the provider’s message	where the alert came from another source, a short investigation
Remedial action on the controller’s side	Article 33(3)(d) GDPR, UODO guide 6.1 and 7.1	immediately	regardless of the outcome of the risk assessment
Assessment of the risk to individuals	Article 33(1) and Article 34(1) GDPR, EDPB paragraphs 44 and 106 to 119	within 72 hours and again after new information from the provider	the provider’s assessment does not replace the controller’s
Classification of the incident (essential or important entity)	Article 11(1)(3), (4) and (4a) and (1a) and Article 8i(1) of the Polish KSC Act	immediately; early warning without delay and no later than 24 hours after detection; incident notification without delay and no later than 72 hours after detection, and for a controller that is a trust service provider 24 hours (Article 11(1a))	only an incident within the meaning of the Act; not in the banking and financial market infrastructure sectors
Notification to the President of the UODO	Article 33(1), (3) and (4) GDPR	without undue delay and, where feasible, within 72 hours; later with reasons for the delay	not where the risk is unlikely; a copy of the data held by the controller may change this in the case of loss or destruction of data, though not always; the EDPB illustrates this with encrypted data (paragraph 79); by the provider on behalf of the controller only with authorisation in the agreement, written according to the UODO guide
Communication to data subjects	Article 34 GDPR	without undue delay	only where the risk is high; exceptions in Article 34(3); by the provider on behalf of the controller only with authorisation in the agreement, written according to the UODO guide
Documentation of the breach	Article 33(5) GDPR, UODO guide 8.1	after becoming aware of the breach or deciding that there is none, and with each new piece of information	regardless of the outcome of the risk assessment; according to the UODO guide also an incident found not to be a breach; a register is not a mandatory form
Reassessment of the provider	Article 28(1) and (3)(h) GDPR	once the event is under control	scope of audit according to the agreement

Conclusions and next steps

The provider establishes whether a breach has occurred and notifies it to the controller without undue delay. The controller verifies the event and makes the final classification. It also assesses the risk, takes the decisions and is responsible for them.

1. Record the time of the provider’s message, check that it is genuine through the channel in the agreement and immediately ask for confirmation whether the event covered your data.
2. Limit the effects on your own side at once and record each action with the time.
3. Establish whether you hold a copy of the data and whom it concerns, then assess the risk within your own team.
4. If you are an essential or important entity outside the banking and financial market infrastructure sectors, check whether the event is a significant incident. Submit the early warning of a significant incident to the competent sectoral CSIRT without delay and no later than 24 hours after detection. Submit the incident notification without delay and no later than 72 hours after detection, or within 24 hours as a trust service provider.
5. Notify the breach to the President of the UODO without undue delay and, where feasible, within 72 hours. The exception is a breach that is unlikely to result in a risk to individuals. Supplement the information you do not yet have in phases. Name the person who will approve the notification at weekends too.
6. Decide on communicating the breach to data subjects and agree with the provider who will send it and on whose behalf.
7. Document the breach and plan a reassessment of the provider and a review of the data processing agreement.

Related materials

• How and when must a processor notify a personal data breach to the controller? — the provider’s obligations and the terms of the agreement.
• How to count the 72 hours for notifying a personal data breach? — the moment of becoming aware and counting the deadline.
• Does every data breach need to be reported? — the notification threshold and general rules of risk assessment.
• How do you notify data subjects of a breach and what must the communication contain? — the content, channel and language of the communication.
• What should a personal data breach register contain? — the entry on a breach, including one that was not notified.
• What must a personal data processing agreement contain? — the terms on notifying breaches and on audits.

Sources

• Regulation (EU) 2016/679 of the European Parliament and of the Council (GDPR), consolidated version — Article 26(1), Article 28(1), (3)(c), (f) and (h) and (4), Article 33 and Article 34 — eur-lex.europa.eu.
• Act of 5 July 2018 on the National Cybersecurity System, consolidated text as at 18 August 2026 — Article 2(5), Article 8i(1) and Article 11(1)(3), (4) and (4a) and (1a) (in Polish) — isap.sejm.gov.pl.
• European Data Protection Board, Guidelines 9/2022 on personal data breach notification under GDPR, version 2.0 adopted on 28 March 2023 — paragraphs 31, 34, 36, 42, 44 to 48, 78, 79 and 106 to 119 — edpb.europa.eu.
• Personal Data Protection Office (UODO), Guide on personal data breaches, version of 20 February 2025 — sections 5.2, 6.1, 7.1, 8.1, 9.2 and 10.2 (in Polish) — uodo.gov.pl.
• Personal Data Protection Office (UODO), announcement “The controller must notify a leak that occurred at the processor” of 12 August 2026 (in Polish) — uodo.gov.pl.