{"id":3262,"date":"2026-11-09T11:44:21","date_gmt":"2026-11-09T11:44:21","guid":{"rendered":"https:\/\/sawaryn.com\/us\/?p=3262"},"modified":"2026-11-09T11:44:21","modified_gmt":"2026-11-09T11:44:21","slug":"invoicing-provider-breach-reporting-poland","status":"publish","type":"post","link":"https:\/\/sawaryn.com\/us\/invoicing-provider-breach-reporting-poland\/","title":{"rendered":"Your Invoicing Provider Was Hacked: Who Must Report the Data Breach in Poland?"},"content":{"rendered":"

Your invoicing system provider has been hacked. It has reported the breach to Poland\u2019s data protection authority, notified CERT Polska and the police, replaced security keys, and emailed users. Your own servers were not affected.<\/p>\n

That does not close the matter for your company. The provider\u2019s database may also have held personal data for which your company\u2014not the provider\u2014is the controller<\/strong>. In that case, you must assess your own reporting obligations, and your own 72-hour notification period may already be running.<\/p>\n

Breach notifications to the President of the Personal Data Protection Office rose from 14,069 in 2023 to 22,435 in 2025, according to the UODO 2025 annual report<\/a>. There is no public breakdown showing how many involved SaaS processors. The operational point remains: a provider\u2019s notification does not, by itself, discharge its customer\u2019s obligations as a controller.<\/p>\n

This article explains how to establish responsibility, organize the first 72 hours, count affected individuals, and address the payment-fraud risks that can follow an invoicing data breach.<\/p>\n

First, establish who controls which data<\/h2>\n

Poland\u2019s Personal Data Protection Office is commonly referred to as UODO<\/strong>. Its President is the Polish supervisory authority to which personal data breaches are notified under the GDPR.<\/p>\n\n\n\n\n\n\n\n\n\n
Term<\/th>\nWhat it means in this scenario<\/th>\nWhy it matters<\/th>\n<\/tr>\n<\/thead>\n
Controller<\/strong><\/td>\nThe entity that determines why and how personal data is processed. If you hold business partners\u2019 personal data in an invoicing application, you are the controller of that data.<\/td>\nYou must assess whether to notify UODO and affected individuals.<\/td>\n<\/tr>\n
Processor<\/a><\/strong><\/td>\nAn entity processing data on a controller\u2019s behalf, such as a SaaS provider or accounting firm.<\/td>\nAs processor, the provider must tell you about a breach without undue delay.<\/td>\n<\/tr>\n
Personal data breach<\/strong> \u2014 Article 4(12) GDPR<\/td>\nAn incident leading to accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data.<\/td>\nData downloaded from your account following an attack on the provider can constitute a breach affecting you as controller.<\/td>\n<\/tr>\n
Initial notification<\/strong> \u2014 Article 33(4) GDPR<\/td>\nA notification based on the information currently available, followed by further details.<\/td>\nYou need not wait until the provider can give you exact figures.<\/td>\n<\/tr>\n
Breach register<\/strong> \u2014 Article 33(5) GDPR<\/td>\nYour internal record of a breach, its circumstances, consequences, and remedial action.<\/td>\nYou document the breach even if your risk assessment concludes that notification to UODO is not required.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Why the provider\u2019s UODO filing is not yours<\/h3>\n

A provider may act in two different capacities in the same incident. It can be the controller<\/strong> of its service users\u2019 account data\u2014such as email addresses, encrypted passwords, phone numbers, and account identifiers\u2014and the processor<\/strong> of data you placed in its invoicing system. Your business partners\u2019 records, invoice contents, bank account numbers, addresses, and transaction amounts fall into the latter category.<\/p>\n

Under Article 33(1) GDPR, the controller notifies the supervisory authority of a reportable breach. Under Article 33(2), a processor notifies its controller without undue delay<\/strong>. That provision does not set a specific number of hours for the processor\u2019s notice; a more precise deadline should be addressed in the data processing agreement. UODO has confirmed that the controller\u2019s notification obligation remains with the controller when the incident occurs at a processor<\/a>.<\/p>\n\n\n\n\n\n\n\n\n
Who acts<\/th>\nData or information concerned<\/th>\nRecipient<\/th>\nGDPR provision<\/th>\n<\/tr>\n<\/thead>\n
SaaS provider, as controller<\/td>\nBreach involving its service users\u2019 account data<\/td>\nPresident of UODO<\/td>\nArticle 33(1)<\/td>\n<\/tr>\n
SaaS provider, as your processor<\/td>\nNotice that a breach has occurred<\/td>\nYour company, as controller<\/td>\nArticle 33(2)<\/td>\n<\/tr>\n
Your company, as controller<\/td>\nBreach involving personal data in business partner records, invoices, or contractor records<\/td>\nPresident of UODO, where notification is required<\/td>\nArticle 33(1)<\/td>\n<\/tr>\n
Your company, as controller<\/td>\nInformation about the breach<\/td>\nAffected individuals, where the breach is likely to result in a high risk to their rights and freedoms<\/td>\nArticle 34(1)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The same attack can therefore lead to two separate UODO notifications covering different data<\/strong>, assessed against separate 72-hour periods. A notice to CERT Polska or the police is not a substitute for either GDPR assessment.<\/p>\n

If you need to establish whether your company must notify, and what the notification should cover, contact us<\/a>.<\/p>\n

When does your 72-hour period start?<\/h2>\n

For the controller, the period runs from becoming aware of the breach<\/strong>. It does not start automatically on the date of the attack, the date of the provider\u2019s UODO filing, or the date on which the provider releases a dashboard showing exactly what was downloaded.<\/p>\n

You do not need every detail before you become aware. A reasonable degree of certainty that a personal data breach has occurred is enough.<\/p>\n\n\n\n\n\n\n\n\n
How the information reaches your company<\/th>\nAwareness point identified in the source scenario<\/th>\n<\/tr>\n<\/thead>\n
A business partner forwards the provider\u2019s breach notice<\/td>\nWhen the message is read<\/td>\n<\/tr>\n
Someone sees a notice on the provider\u2019s website<\/td>\nWhen the notice is read<\/td>\n<\/tr>\n
A team member learns of the incident through industry media<\/td>\nWhen that person learns of it\u2014not when management is later briefed<\/td>\n<\/tr>\n
The provider emails the account owner<\/td>\nWhen the message is delivered to the inbox<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Immediately record the date, time, and source of the first information.<\/strong> Check with everyone who can access the provider account to establish whether someone knew earlier. If a finance employee saw the provider\u2019s notice two days before a management meeting, your 72-hour period may have begun then.<\/p>\n

Plan for weekends. If the period ends on a Saturday or Sunday, completing the notification on the preceding business day is the safe organizational choice described in the source. The form on biznes.gov.pl<\/strong>, Poland\u2019s online business services portal, is available online, but the company still needs an authorized representative to sign.<\/p>\n

The first 72 hours: an operational timetable<\/h2>\n

The following schedule assumes the company learns of the incident on the afternoon of Day D<\/strong>. Adjust the times to your actual awareness point; do not treat Day D+1 as an extension of the legal deadline.<\/p>\n

Day D: preserve the timeline and secure access<\/h3>\n\n\n\n\n\n\n\n\n
Target time<\/th>\nAction<\/th>\nLead<\/th>\n<\/tr>\n<\/thead>\n
Immediately<\/td>\nRecord when the company became aware and check whether anyone knew earlier.<\/td>\nFirst recipient of the information and data protection officer (DPO)<\/td>\n<\/tr>\n
Within two hours<\/td>\nChange all users\u2019 provider-account passwords, enable two-factor authentication, and review access\u2014including the accounting firm\u2019s access and accounts held by former contractors.<\/td>\nIT or account administrator<\/td>\n<\/tr>\n
Within two hours<\/td>\nCheck the bank account number in account settings and on invoices already issued.<\/td>\nFinance<\/td>\n<\/tr>\n
Within two hours<\/td>\nReplace API tokens in every integration. If the application uses a token to connect to KSeF<\/strong>, Poland\u2019s National e-Invoicing System, revoke that token and generate a new one.<\/td>\nIT<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Day D+1: assess, decide, and prepare the filing<\/h3>\n\n\n\n\n\n\n\n\n\n\n
Target time<\/th>\nAction<\/th>\nLead<\/th>\n<\/tr>\n<\/thead>\n
By 9:00 a.m.<\/td>\nEstimate the number of affected individuals by category.<\/td>\nDPO or legal team, with finance<\/td>\n<\/tr>\n
By 9:00 a.m.<\/td>\nAsk the provider through an official channel whether your account was among those from which data was downloaded, when account-specific details will be available, and whether KSeF credentials were downloaded. Refer to Article 28(3)(f) GDPR.<\/td>\nDPO or legal team<\/td>\n<\/tr>\n
9:00\u20139:30 a.m.<\/td>\nHold a management, DPO, and legal decision meeting. Assess risk and decide whether to notify UODO or document why a risk to individuals is unlikely.<\/td>\nManagement<\/td>\n<\/tr>\n
By 1:00 p.m.<\/td>\nDraft the initial notification and breach-register entry.<\/td>\nDPO or legal team<\/td>\n<\/tr>\n
By 3:00 p.m.<\/td>\nSubmit the initial breach notification<\/a> through biznes.gov.pl, signed by someone authorized to represent the company.<\/td>\nManagement<\/td>\n<\/tr>\n
By the end of the day<\/td>\nDraft a business-partner notice and send it where contracts impose their own incident-notification deadlines.<\/td>\nDPO or legal team, with sales<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

When the provider supplies details several days later:<\/strong> submit supplementary information under Article 33(4) GDPR, identify individuals named only as invoice recipients or payers, and update the breach register.<\/p>\n

Count people, not invoices: five common mistakes<\/h2>\n

A notification asks for an approximate number of individuals<\/strong>, not database records. One person appearing on ten invoices is one person. Conversely, a search limited to named customer records can miss people whose data appears elsewhere in the system.<\/p>\n

    \n
  1. A named email address in a company record.<\/strong> The first-name and last-name fields may be blank, while a contact address such as jan.kowalski@firma.pl<\/code> identifies a person. Include that person in the assessment.<\/li>\n
  2. Names in partnership records.<\/strong> A Polish sp\u00f3\u0142ka cywilna<\/em> (civil-law partnership) or sp\u00f3\u0142ka jawna<\/em> (registered partnership) may be recorded as a business entity, but a partner\u2019s surname in its name is still personal data.<\/li>\n
  3. Charges passed on to contractors using their private details.<\/strong> Invoices passing on the costs of sports or medical packages to B2B contractors and former contractors may contain names, home addresses, personal email addresses, and amounts. This group can have a particularly broad range of disclosed data yet be overlooked because it is not labeled \u201ccustomers.\u201d<\/li>\n
  4. Recipients and payers named only on invoices.<\/strong> An individual may appear as the recipient or payer in the document body without a separate contact record. Search invoice contents, not just the business partner database. Mark the count as \u201cbeing determined\u201d in the initial notification if necessary.<\/li>\n
  5. Health-related detail in line items.<\/strong> In the approved source\u2019s analysis, the description \u201cmedical package\u201d or \u201csports package\u201d alone does not constitute health data<\/strong> under Article 9 GDPR. A line item identifying a specific service\u2014such as \u201crehabilitation,\u201d \u201cperinatal care,\u201d or a particular medical specialty\u2014does. The source notes that this will usually be decisive for notifying individuals under Article 34. Check the issued invoices\u2019 line items, not merely the name of the service in the benefits-provider agreement.<\/li>\n<\/ol>\n

    Notify with what you know; supplement later<\/h2>\n

    A provider may promise an account dashboard showing which data, time periods, and records were downloaded. If it arrives only after your deadline, waiting for it is not a sound notification plan.<\/p>\n

    Article 33(4) GDPR allows information to be provided in phases without undue further delay. The source also points to Recital 85 and notes that the biznes.gov.pl<\/strong> form accepts estimates and ranges. Prepare an initial filing based on what is known, identify what remains under investigation, and follow up when the provider supplies account-specific facts.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n
    Initial notification item<\/th>\nPractical content<\/th>\n<\/tr>\n<\/thead>\n
    Nature of the breach<\/td>\nUnauthorized access to data processed by your SaaS provider; explain that your own systems were not compromised, if that is established.<\/td>\n<\/tr>\n
    Categories of individuals<\/td>\nFor example, sole traders, business-partner contact persons, B2B contractors, and individuals whose costs were passed on through invoices. Identify categories still being checked.<\/td>\n<\/tr>\n
    Approximate number<\/td>\nA supported range\u2014for example, \u201c30\u201360 people\u201d\u2014rather than an unsupported exact figure.<\/td>\n<\/tr>\n
    Categories of data<\/td>\nIdentification, address, and financial data, including bank account numbers and invoice amounts. Indicate whether special-category data may be involved.<\/td>\n<\/tr>\n
    Likely consequences<\/td>\nSpecific risks such as bank-account substitution fraud and phishing.<\/td>\n<\/tr>\n
    Measures taken or planned<\/td>\nPassword changes, two-factor authentication, replacement tokens, and business-partner warnings, as applicable.<\/td>\n<\/tr>\n
    Further information<\/td>\nState clearly that this is an initial notification and that details will follow after the processor provides them.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    In the source\u2019s filing process, the notification is signed by the company\u2019s authorized representative\u2014for example, the president of its management board\u2014not by the DPO.<\/p>\n

    Address the payment-fraud risk, not just account access<\/h2>\n

    After an invoicing data breach, the source identifies bank-account substitution fraud<\/strong> as the principal practical threat. Someone with invoice data may know who trades with whom, the amounts, and which invoices are unpaid. They may impersonate your company when approaching customers or impersonate a supplier when approaching your finance team. A request to \u201cupdate\u201d payment details can look convincing.<\/p>\n

    Take three immediate steps:<\/p>\n

      \n
    1. Warn business partners briefly.<\/strong> Say that the incident occurred at the service provider rather than in your systems, if confirmed; that your bank account number has not changed, if true; and that any request to change payment details must be verified by calling a number already known to the recipient.<\/li>\n
    2. Make independent verification routine.<\/strong> Confirm every supplier bank-account change by phone using an established number and check the account against Poland\u2019s VAT taxpayer register.<\/li>\n
    3. Train finance and sales teams.<\/strong> Use realistic examples of bank-account substitution requests, including messages that appear to refer to genuine invoices.<\/li>\n<\/ol>\n

      Money sent to a substituted account may not be recovered. Article 143 of Poland\u2019s Payment Services Act provides a recovery mechanism, but the recipient\u2019s bank does not guarantee repayment; see the Financial Ombudsman\u2019s explanation of mistaken transfers<\/a>. If a fraudulent transfer occurs, Polish police emphasize acting immediately and contacting the bank<\/a>.<\/p>\n

      KSeF organizes the circulation of invoices; it does not stop a payment instruction sent outside that system. Poland\u2019s Ministry of Finance recommends treating KSeF tokens and certificates<\/a> as sensitive and protecting them to the standard applied to online-banking credentials.<\/p>\n

      Document the breach even if you do not notify UODO<\/h2>\n

      Article 33(5) GDPR requires controllers to document every personal data breach<\/a>, including its circumstances, consequences, and remedial measures.<\/p>\n

      That includes a breach for which you conclude, after assessing risk, that UODO notification is not required. Record why you concluded that a risk to individuals is unlikely<\/strong>. Without the entry, you may have no evidence of the assessment if UODO reviews the incident.<\/p>\n

      What the enforcement examples show\u2014and do not show<\/h3>\n

      The source identifies the following Polish fines concerning failures to notify or inform individuals:<\/p>\n\n\n\n\n\n\n\n\n
      Entity<\/th>\nFine<\/th>\nSource description<\/th>\n<\/tr>\n<\/thead>\n
      Bank Millennium<\/td>\nOver PLN 350,000<\/td>\nUODO announcement of December 16, 2025<\/td>\n<\/tr>\n
      Medical University of Silesia<\/td>\nPLN 25,000<\/td>\nUpheld by the Supreme Administrative Court in 2025<\/td>\n<\/tr>\n
      Court enforcement officer<\/td>\nPLN 7,700 for failure to notify, plus PLN 13,200 for failure to inform individuals<\/td>\nUODO announcement of November 17, 2025<\/td>\n<\/tr>\n
      Housing association<\/td>\nPLN 5,000<\/td>\nUODO announcement of April 20, 2026; UODO information<\/a><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

      None of these examples concerned only<\/strong> an incident on a processor\u2019s side. They should not be presented as precedents for this exact SaaS scenario. They do illustrate that failure to meet notification duties can carry a financial consequence; an incident\u2019s location in a provider\u2019s infrastructure does not itself release the controller from its obligations.<\/p>\n

      Require useful information from the provider<\/h2>\n

      Article 28(3)(f) GDPR provides a basis for seeking the processor\u2019s assistance in establishing the scope of a breach affecting your account. Request facts you can use in your own assessment, rather than waiting for a general public announcement.<\/p>\n

      After the incident, review your data processing agreement:<\/p>\n

        \n
      • Did the provider notify your company as controller<\/strong>, or only an individual account user?<\/li>\n
      • Does the agreement set a specific notice period, such as 24 or 48 hours?<\/li>\n
      • Does it specify what information the provider must supply following an incident?<\/li>\n
      • Does the provider maintain breach documentation and make it available on request?<\/li>\n<\/ul>\n

        From a controller\u2019s perspective, a stronger clause provides an urgent reporting deadline\u2014for example, 24 hours for an initial assessment of causes\u2014requires partial information before every fact is known, sets an update schedule, and identifies a dedicated incident channel. If those provisions are absent, consider renegotiating the agreement or changing providers.<\/p>\n