{"id":5134,"date":"2026-11-09T11:57:22","date_gmt":"2026-11-09T11:57:22","guid":{"rendered":"https:\/\/sawaryn.com\/?p=5134"},"modified":"2026-11-09T12:00:42","modified_gmt":"2026-11-09T12:00:42","slug":"saas-provider-breach-uodo-notification","status":"publish","type":"post","link":"https:\/\/sawaryn.com\/en\/publikacje\/saas-provider-breach-uodo-notification\/","title":{"rendered":"A Breach at a SaaS Provider. Why Your Company Has Its Own 72 Hours to Notify the UODO."},"content":{"rendered":"

Your invoicing system provider has been hacked. It reported the breach to the UODO, notified CERT Polska and the Police, replaced its keys, and emailed users. Your servers remain untouched. And this is precisely when your own 72-hour clock starts ticking \u2014 because the provider\u2019s database contained data for which you, not the provider, are the controller.<\/p>\n

This scenario is affecting a growing number of companies. The number of breach notifications submitted to the President of the UODO is rising rapidly \u2014 from 14,069 in 2023 to 22,435 in 2025 (UODO 2025 Annual Report<\/a>). The lack of a public breakdown by provider category means that we do not know how many of these notifications concerned breaches at SaaS processors \u2014 but we do know that the controller is responsible for notifying the breach<\/strong>, not the provider.<\/p>\n

In this article, you will find:<\/p>\n

    \n
  1. An explanation of why the provider\u2019s notification does not replace your own.<\/li>\n
  2. A schedule of actions for the first 72 hours.<\/li>\n
  3. Pitfalls when counting data subjects.<\/li>\n
  4. Specific recommendations \u2014 from securing the account to drafting a notice for business partners.<\/li>\n<\/ol>\n

    Key terms you need to know before reading further<\/h2>\n

    Before we get to the heart of the matter, let us clarify a few terms. Without them, it is difficult to understand who is responsible for what after a breach at a provider.<\/p>\n\n\n\n\n\n\n\n\n\n
    Term<\/th>\nWhat it means<\/th>\nWhy it matters<\/th>\n<\/tr>\n<\/thead>\n
    Data controller<\/strong><\/td>\nThe entity that determines the purposes and means of processing personal data. If you store your business partners\u2019 data in an invoicing system, you are the controller of that data.<\/td>\nYou are responsible for notifying the UODO of the breach.<\/td>\n<\/tr>\n
    Data processor<\/a> (processor)<\/strong><\/td>\nAn entity that processes data on behalf of the controller \u2014 e.g. a SaaS provider or accounting firm.<\/td>\nThe processor reports the breach to you, not to the supervisory authority.<\/td>\n<\/tr>\n
    Personal data breach<\/strong> (Article 4(12) GDPR)<\/td>\nAn incident resulting in the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data.<\/td>\nAn attack on a provider in which data was downloaded from your account constitutes a breach for you as the controller.<\/td>\n<\/tr>\n
    Initial notification<\/strong> (Article 33(4) GDPR)<\/td>\nA notification containing estimates and ranges, supplemented at a later stage.<\/td>\nYou do not have to wait for precise data from the provider \u2014 you can (and should) report what you know.<\/td>\n<\/tr>\n
    Breach register<\/strong> (Article 33(5) GDPR)<\/td>\nInternal documentation of every breach \u2014 its circumstances, consequences, and remedial action.<\/td>\nYou must maintain it even if you conclude that there is no risk and do not submit a notification.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    Why the provider\u2019s notification does not replace your own<\/h2>\n

    This is the most common mistake. The management board sees the provider\u2019s announcement: \u201cWe have reported the breach to the President of the UODO and notified CERT Polska and the Police” \u2014 and assumes the matter is closed.<\/p>\n

    It is not.<\/p>\n

    The provider reports the breach insofar as it concerns data for which the provider itself is the controller<\/strong> \u2014 namely, the service users\u2019 account data (email address, encrypted password, telephone number, account identifier). Your business partners\u2019 data \u2014 records, invoice contents, bank account numbers, addresses, amounts \u2014 has a different controller. You.<\/p>\n

    Article 33(1) GDPR states explicitly that it is the controller<\/strong> that notifies the supervisory authority of a breach. Article 33(2) requires the processor to notify the controller \u201cwithout undue delay” \u2014 but it does not specify a particular number of hours. A detailed deadline should be set out in the data processing agreement.<\/p>\n

    The UODO has confirmed this principle: the obligation to notify remains with the controller when the incident occurred at the processor (UODO \u2014 The controller must report a breach at a processor<\/a>).<\/p>\n

    What this means for your company<\/h3>\n\n\n\n\n\n\n\n\n
    Who<\/th>\nWhat is reported<\/th>\nTo whom<\/th>\nLegal basis<\/th>\n<\/tr>\n<\/thead>\n
    SaaS provider (processor)<\/td>\nA breach involving the service users\u2019 account data<\/td>\nTo the President of the UODO \u2014 as the controller of that data<\/td>\nArticle 33(1) GDPR<\/td>\n<\/tr>\n
    SaaS provider (processor)<\/td>\nThe fact that a breach occurred<\/td>\nTo you \u2014 as the controller of your business partners\u2019 data<\/td>\nArticle 33(2) GDPR<\/td>\n<\/tr>\n
    Your company (controller)<\/td>\nA breach involving the data of business partners, invoices, and contractors<\/td>\nTo the President of the UODO<\/td>\nArticle 33(1) GDPR<\/td>\n<\/tr>\n
    Your company (controller)<\/td>\nInformation about the breach<\/td>\nTo data subjects \u2014 if the risk is high<\/td>\nArticle 34(1) GDPR<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    Two separate notifications concerning the same incident. Two different scopes of data. Two different 72-hour deadlines.<\/p>\n

    Contact us<\/a> \u2014 we will help you assess whether and to what extent you need to report the breach.<\/p>\n