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 — because the provider’s database contained data for which you, not the provider, are the controller.
This scenario is affecting a growing number of companies. The number of breach notifications submitted to the President of the UODO is rising rapidly — from 14,069 in 2023 to 22,435 in 2025 (UODO 2025 Annual Report). 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 — but we do know that the controller is responsible for notifying the breach, not the provider.
In this article, you will find:
- An explanation of why the provider’s notification does not replace your own.
- A schedule of actions for the first 72 hours.
- Pitfalls when counting data subjects.
- Specific recommendations — from securing the account to drafting a notice for business partners.
Key terms you need to know before reading further
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.
| Term | What it means | Why it matters |
|---|---|---|
| Data controller | The entity that determines the purposes and means of processing personal data. If you store your business partners’ data in an invoicing system, you are the controller of that data. | You are responsible for notifying the UODO of the breach. |
| Data processor (processor) | An entity that processes data on behalf of the controller — e.g. a SaaS provider or accounting firm. | The processor reports the breach to you, not to the supervisory authority. |
| Personal data breach (Article 4(12) GDPR) | An incident resulting in the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data. | An attack on a provider in which data was downloaded from your account constitutes a breach for you as the controller. |
| Initial notification (Article 33(4) GDPR) | A notification containing estimates and ranges, supplemented at a later stage. | You do not have to wait for precise data from the provider — you can (and should) report what you know. |
| Breach register (Article 33(5) GDPR) | Internal documentation of every breach — its circumstances, consequences, and remedial action. | You must maintain it even if you conclude that there is no risk and do not submit a notification. |
Why the provider’s notification does not replace your own
This is the most common mistake. The management board sees the provider’s announcement: “We have reported the breach to the President of the UODO and notified CERT Polska and the Police” — and assumes the matter is closed.
It is not.
The provider reports the breach insofar as it concerns data for which the provider itself is the controller — namely, the service users’ account data (email address, encrypted password, telephone number, account identifier). Your business partners’ data — records, invoice contents, bank account numbers, addresses, amounts — has a different controller. You.
Article 33(1) GDPR states explicitly that it is the controller that notifies the supervisory authority of a breach. Article 33(2) requires the processor to notify the controller “without undue delay” — but it does not specify a particular number of hours. A detailed deadline should be set out in the data processing agreement.
The UODO has confirmed this principle: the obligation to notify remains with the controller when the incident occurred at the processor (UODO — The controller must report a breach at a processor).
What this means for your company
| Who | What is reported | To whom | Legal basis |
|---|---|---|---|
| SaaS provider (processor) | A breach involving the service users’ account data | To the President of the UODO — as the controller of that data | Article 33(1) GDPR |
| SaaS provider (processor) | The fact that a breach occurred | To you — as the controller of your business partners’ data | Article 33(2) GDPR |
| Your company (controller) | A breach involving the data of business partners, invoices, and contractors | To the President of the UODO | Article 33(1) GDPR |
| Your company (controller) | Information about the breach | To data subjects — if the risk is high | Article 34(1) GDPR |
Two separate notifications concerning the same incident. Two different scopes of data. Two different 72-hour deadlines.
Contact us — we will help you assess whether and to what extent you need to report the breach.
When your 72-hour period begins
The deadline runs from the moment the controller becomes aware of the breach — not from the attack on the provider, not from the notification submitted by the provider, and not from the moment the provider makes a dashboard available showing the scope of the downloaded data.
“Becoming aware of the breach” does not require establishing every detail of the incident. A reasonable degree of certainty that a breach has occurred is sufficient.
When the deadline begins — examples
| Situation | When you become aware of the breach |
|---|---|
| A business partner forwards you a notice from the provider | When you read the message |
| You see an announcement on the provider’s website | When you read the announcement |
| A member of your team learns about it from industry media | When that person becomes aware of the information — not when they pass it on to the management board |
| The provider sends a notice to the account owner’s email address | When the message is delivered to the inbox |
Therefore, the first thing to do after learning about an incident is to determine and record the exact moment you became aware of the breach (date, time, source of information). Then check with everyone who has access to the provider’s account whether anyone knew about the incident earlier.
If it turns out that an employee in the finance department saw the provider’s announcement two days before the management board meeting, your 72-hour period may have started running at that point.
A note on weekends
If the 72-hour period expires on a Saturday or Sunday, finalising the notification on the last business day before the deadline is the only safe organisational decision. The form on biznes.gov.pl is available online, but it must be signed by a person authorised to represent the company.
Schedule for the first 72 hours — what to do and in what order
Below is a schedule based on a scenario in which the company learns about the incident in the afternoon of Day D. Adapt it to your circumstances.
Day D — from the moment you become aware of the breach
| Time (approximate) | Action | Person responsible |
|---|---|---|
| D, immediately | Record when you became aware of the breach. Check whether anyone in the company knew about it earlier. | The person who first received the information + DPO |
| D, within 2 hours | Secure the account with the provider: change all users’ passwords, enable two-factor authentication, and review the user list (including access granted to the accounting firm and former contractors). | IT / account administrator |
| D, within 2 hours | Verify the bank account number in the account settings and on issued documents. | Finance department |
| D, within 2 hours | Generate new API tokens and replace them in all integrations. If the application connects to KSeF using a token — revoke it and generate a new one. | IT |
Day D+1 — before the 72-hour deadline
| Time (approximate) | Action | Person responsible |
|---|---|---|
| D+1, by 9:00 | Compile the number of individuals by category (details in the next section). | DPO / legal department + finance department |
| D+1, by 9:00 | Send the provider an enquiry through an official channel, referring to Article 28(3)(f) GDPR: whether your account is among those from which data was downloaded, when the provider will make the dashboard showing the scope of the download available, and whether KSeF access credentials were downloaded. | DPO / legal department |
| D+1, 9:00–9:30 | Decision-making meeting: management board + DPO + lawyer. Risk assessment. Decision: submit a notification or document why the risk is unlikely. | Management board |
| D+1, by 13:00 | Draft the initial notification and the entry in the breach register. | DPO / legal department |
| D+1, by 15:00 | Submit the initial notification using the form on biznes.gov.pl, signed by the governing body authorised to represent the company. | Management board |
| D+1, by the end of the day | Draft a notice for business partners. Send it where contracts provide for their own incident notification deadlines. | DPO / legal department + sales department |
After receiving details from the provider (several days later)
- Submit a supplementary notification under Article 33(4) GDPR.
- Identify the recipients and payers listed on invoices — this category has no separate records and is only visible in the contents of documents.
- Update the entry in the breach register.
How to count data subjects — five pitfalls
The notification form asks about individuals, not records. One person with ten invoices counts as one person. But identifying these people in an invoicing system can be more difficult than it seems.
Pitfall 1: a named email address with blank fields
A corporate business partner has blank “first name” and “last name” fields in its record, but the contact field contains the address jan.kowalski@firma.pl. This is personal data. This person must be included in the count.
Pitfall 2: partnerships
A civil-law partnership called “Kowalski and Nowak s.c.” or a registered partnership whose business name contains its partners’ surnames — they appear in the system as business entities, but the partners’ surnames are personal data.
Pitfall 3: re-invoicing to personal details
Invoices for sports and medical packages recharged to B2B contractors and former contractors contain: first and last name, home address, personal email address, and amounts. This is the group with the broadest scope of disclosed data — and the one most often overlooked because it is not associated with “customers”.
Pitfall 4: invoice recipient and payer
Individuals may be listed on invoices as recipients or payers — without having their own records in the system. You need to look for them in the contents of documents, not in the business partner database. In the initial notification, mark this item as “being determined”.
Pitfall 5: special categories of data in invoice line items
The mere description “medical package” or “sports package” on an invoice does not constitute health data within the meaning of Article 9 GDPR. However, if a line item on the document identifies a specific service — “rehabilitation”, “perinatal care”, or a specific medical specialty — it does constitute health data. And it will usually determine that the individuals must be notified under Article 34 GDPR.
Check the descriptions of line items on issued recharge invoices — not the name of the service in the agreement with the benefits provider.
Initial notification — do not wait for the provider’s dashboard
The provider announces a dashboard that, once you log in, will show what data was downloaded from your account, from which periods, and how many records were involved. The dashboard appears after several days — that is, after your deadline has expired.
The decision is simple: you submit a notification based on what you know and supplement it later.
Article 33(4) GDPR explicitly allows information to be provided in phases without undue further delay. Recital 85 GDPR confirms that information may be provided gradually. The form on biznes.gov.pl accepts estimates and ranges.
What to enter in the initial notification
| Form field | What to enter | Notes |
|---|---|---|
| Nature of the breach | Unauthorised access to data processed by a processor (SaaS provider) | State that your systems were not compromised |
| Categories of data subjects | Business partners (sole traders), contact persons, B2B contractors, individuals (recharged costs) | Mark items that are still being determined |
| Approximate number of individuals | A range, e.g. “30–60 people” | The form does not require an exact figure |
| Categories of data | Identification, address, and financial data (bank account numbers, invoice amounts) | Indicate whether special categories of data may be involved |
| Consequences | Risk of bank account substitution fraud, risk of phishing | Be specific rather than vague |
| Remedial measures | Password changes, 2FA, new tokens, notice to business partners | List the actions taken and planned |
| Information about supplementation | “Initial notification — supplementary information will be provided after detailed data is received from the processor” | State this clearly |
The notification must be signed by the governing body authorised to represent the company — e.g. the president of the management board. Not the DPO.
The main risk after an invoicing data breach is not account takeover
In the event of a breach involving data from an invoicing system, the main threat is bank account substitution fraud. The attacker knows the parties to the transactions, the amounts, and which invoices remain unpaid. They can impersonate your company when contacting your customers — or impersonate your suppliers when contacting you.
A message requesting a bank account change may be indistinguishable from a genuine one.
What to do immediately
- Send your business partners a brief notice containing three points: the incident occurred at the service provider, not in your systems; your bank account number has not changed; every request to change a bank account number must be confirmed by telephone using a previously known number.
- Introduce a permanent internal procedure: confirm every change to a supplier’s bank account number by telephone and check it against the VAT taxpayers register.
- Train the finance and sales teams to recognise bank account substitution fraud — using real-world examples.
If a payment is made to a substituted account, recovery of the funds is not guaranteed. Article 143 of the Payment Services Act provides for a recovery mechanism, but the recipient’s bank does not guarantee repayment (Financial Ombudsman — incorrect bank transfer). A rapid response and immediate contact with the bank are crucial (Police — transfer to a fraudster).
KSeF streamlines the circulation of invoices themselves, but it does not protect against payment instructions sent outside the system. The Ministry of Finance recommends treating KSeF tokens and certificates as sensitive data and protecting them to the same standard as online banking credentials (KSeF certificates — ksef.podatki.gov.pl).
Breach register — mandatory even if you do not submit a notification
Article 33(5) GDPR imposes an obligation to document every breach — its circumstances, consequences, and remedial action. This also applies where, after assessing the risk, you conclude that notification to the UODO is not required.
In that case, the entry should explain the reasons for that assessment. No entry means no evidence that a risk assessment was carried out — and this may become a problem during a UODO inspection.
UODO penalties — confirmed fines for breaches of Article 33 GDPR
The UODO imposes fines for failing to report a breach or reporting it late. Confirmed cases:
| Entity | Fine | Circumstances |
|---|---|---|
| Bank Millennium | over PLN 350,000 | UODO announcement of 16.12.2025 |
| Medical University of Silesia | PLN 25,000 | Upheld by the Supreme Administrative Court in 2025 |
| Court enforcement officer | PLN 7,700 (failure to notify) + PLN 13,200 (failure to inform data subjects) | UODO announcement of 17.11.2025 |
| Housing association | PLN 5,000 | UODO announcement of 20.04.2026 |
(UODO — fine for a housing association)
None of the confirmed cases concerned exclusively an incident on the processor’s side. However, the mere fact that the breach occurred at the provider does not release the controller from the obligation to report it.
The data processing agreement under scrutiny — what to demand from the provider after an incident
Article 28(3)(f) GDPR gives you a basis for requesting specific information from the provider about the scope of the breach affecting your account. Use it.
What to check in the data processing agreement after an incident
- Did the provider comply with its obligation under Article 33(2) GDPR — did it notify you as the controller, or only the account user?
- Does the agreement specify a particular deadline for providing information about a breach (e.g. 24 or 48 hours)?
- Does the agreement specify the scope of information the provider must supply after an incident?
- Does the provider maintain a breach register and make documentation available on request?
From the controller’s perspective, a model clause should provide for: an emergency deadline (e.g. 24 hours for an initial analysis of the causes), an obligation to submit a partial report without waiting for the full findings, an update schedule, and a dedicated reporting channel.
If your agreement does not contain such provisions — this is a good time to renegotiate it. Or change providers.
Parallel reporting obligations — GDPR is not the only route
If your company is subject to the Act on the National Cybersecurity System (amendment of 23 January 2026, effective from 3 April 2026, Journal of Laws 2026, item 252), the same incident may need to be reported to the relevant CSIRT (MON, NASK, or GOV).
A report to a CSIRT and a notification to the UODO are separate obligations based on different criteria. The transfer of a report from one CSIRT to another is not equivalent to notifying the President of the UODO (UODO — one incident, two legal regimes).
Financial entities may also have obligations under the DORA Regulation (EU 2022/2554) — a third reporting route to sectoral authorities.
Liability for damages — who will pay
Article 82(1) GDPR grants data subjects the right to compensation for material or non-material damage. In Case C-300/21 (Österreichische Post), the CJEU confirmed that there is no minimum threshold for non-material damage — but a GDPR infringement does not automatically constitute damage; the individual must demonstrate specific harm (C-300/21 — EUR-Lex).
The controller may be sued even if the breach occurred within the SaaS provider’s infrastructure. After paying compensation, the controller has a right of recourse against the processor (Article 82(4)–(5) GDPR). A contractual clause excluding liability towards third parties does not deprive them of their statutory right under Article 82.
How to prepare before an incident occurs
The first 72 hours after becoming aware of a breach should not involve improvisation. Prepare the following in advance:
- A map of SaaS applications with data categories and roles (controller/processor) — a separate entry for each application or a link in the record of processing activities (UODO — recording processing activities).
- A provider enquiry template referring to Article 28(3)(f) GDPR.
- A notice template for business partners — three sentences ready to be personalised.
- A management decision-making process — who calls the meeting, who decides whether to submit a notification, and who signs the form.
- An initial notification template with fields marked for completion.
- A breach register — even if you have never had an incident, the register should exist as a document ready to be completed.
We can help you
Handling a breach within 72 hours requires simultaneous action on several fronts: securing the account, taking an inventory of the data, assessing the risk, notifying the UODO, issuing a notice to business partners, and making an entry in the register. During a first incident, every one of these steps raises questions that must be answered under time pressure.
We support technology and B2B companies in three ways:
| Option | What it includes | Who it is for |
|---|---|---|
| Operational minimum | Breach response procedure + breach register | Companies that want to have a procedure in place before an incident |
| Solid foundation | Procedure + templates (notification, notice, provider enquiry) + review of data processing agreements + team training | Companies using several SaaS applications containing business partner data |
| Comprehensive protection | Provider audit + map of data in SaaS applications + on-call incident support + end-to-end handling of the notification before the UODO | Companies with a large business partner database and numerous integrations |
We combine GDPR expertise with an understanding of IT and contracts — because a breach at a SaaS provider lies at the intersection of data protection, contract law, and technical security.
A breach at your provider is your problem — but it can be managed
The provider’s notification does not replace your own. The 72-hour deadline runs from the moment you (or anyone in your organisation) learned about the incident. You do not need to know everything — Article 33(4) GDPR allows you to submit an initial notification and supplement it later. The main risk after an invoicing data breach is bank account substitution fraud, not account takeover.
If you use external invoicing, CRM, or document workflow applications and want to have a procedure ready in case of an incident at a provider — contact us. We will help you prepare a data map, notification templates, and a decision-making process before the pressure of the 72-hour deadline arises.
Frequently asked questions
Our system provider has already reported the breach to the UODO — do we really have to report the same incident again?
Yes. The provider reported the breach insofar as it concerned data for which the provider itself is the controller (service user accounts). The data of your business partners in records and invoice contents has a different controller — you. The UODO has confirmed that the obligation to notify remains with the controller when the incident occurred at the processor.
Exactly when does the 72-hour period begin if I learned about the incident by chance from a business partner?
From the moment you have a reasonable degree of certainty that a breach has occurred. If a business partner forwarded you a notice from the provider — from the moment you read that message. If anyone in your organisation had previously seen an announcement on the provider’s website or in the media — from that earlier moment.
What should I do if I do not know within 72 hours how much of our data was actually breached?
Submit an initial notification with estimates and ranges. Article 33(4) GDPR explicitly allows information to be provided in phases. The form on biznes.gov.pl accepts estimates. The alternative is not a more precise notification — it is a late notification.
Do I have to inform business partners if our systems were not attacked?
If the breach is likely to result in a high risk to the rights or freedoms of individuals — yes (Article 34(1) GDPR). In the case of an invoicing data breach, the risk of bank account substitution fraud is real. Irrespective of the formal obligation, a prompt notice warning about attempts to substitute bank account numbers protects both your business partners and your reputation.
Does re-invoicing a medical package mean that health data has been breached?
Not automatically. The mere description “medical package” on an invoice does not constitute health data within the meaning of Article 9 GDPR. However, if a line item on the document identifies a specific service — e.g. “rehabilitation” or a specific medical specialty — it constitutes special-category data. Check the descriptions of line items on issued documents, not the name of the service in the agreement with the benefits provider.
What if, after assessing the risk, we conclude that notification is not required — does that mean we do not have to do anything?
You must make an entry in the breach register under Article 33(5) GDPR. The entry should explain the reasons for concluding that the risk is unlikely. No entry means no evidence that an assessment was carried out — and this may become a problem during a UODO inspection.
