Data Leak at a SaaS Provider: What You Must Do Within 72 Hours, Even Though You Were Not Attacked

On Friday afternoon, you receive a forwarded message from a client: your invoicing application provider has been attacked, and its database has ended up on third-party servers. Your systems are untouched. The provider has already reported the breach to the UODO, notified CERT Polska and the Police. It may seem that the matter does not concern you.

It does — and you have 72 hours to deal with it, starting from the moment you read that email.

The provider’s notification covers only the data for which it is the controller — the service’s user accounts. The details of your business partners in the records, invoice contents, addresses, amounts and bank account numbers have a different controller. You. And it is you who is responsible for reporting the breach to the UODO pursuant to Article 33(1) GDPR.

This article provides a structured course of action: from determining when the deadline starts running, through securing the account, identifying the individuals affected and assessing the risk, to submitting the notification and communicating with business partners. It is all based on an anonymised, real-life incident with a D / D+1 timeline.

Key concepts before you take action

Before moving on to the specific steps, make sure you understand the terminology. There is no time to look up definitions during an incident.

Why your provider’s notification does not protect you

This is the most common mistake after receiving information about a breach at a processor. The management board sees the provider’s announcement: “we have reported the breach to the UODO and notified CERT Polska and the Police” — and assumes the matter is closed.

It is not. And this follows directly from the legislation.

Article 33(1) GDPR places the obligation to notify the supervisory authority of a breach on the controller. Article 33(2) requires the processor to notify the controller — not the authority. These are two separate obligations imposed on two different entities and addressed to different recipients.

The SaaS provider reported the breach as the controller of its own data — the service’s user accounts. Your business partners’ details in the records, the amounts on invoices, addresses and bank account numbers are data for which you are the controller. The provider did not report them on your behalf because it could not do so.

The UODO imposes fines for late or omitted notifications. Confirmed fines have been imposed on both small entities (PLN 5,000 — UODO decision DKN.5131.30.2022) and financial institutions (over PLN 350,000 — Bank Millennium, decision upheld by the Supreme Administrative Court). The amount depends on the criteria set out in Article 83(2) GDPR: the nature of the breach, intent and cooperation with the authority.

A mass notification sent by the provider to your address as a user of the service does not fulfil its obligation under Article 33(2) towards you as the controller. It is a marketing communication, not a formal notification from the processor addressed to the data controller.

Contact us if you need assistance assessing whether your notification obligation has already arisen.

When your 72-hour period starts

The deadline starts running when the controller becomes aware of the breach — not when the provider was attacked, not on the date of its announcement, and not when the provider submitted its own notification.

You become aware of the breach when anyone in your organisation learns about the incident. This may happen through:

1. An email from a business partner forwarding the provider’s notification to you
2. An announcement on the provider’s website read by someone on your team
3. Information in industry media
4. A direct notification from the provider

If your employee read the announcement on the provider’s website on Thursday morning and you learned about it on Friday afternoon — the deadline starts running on Thursday. That is why the first step is to establish and record the exact time when anyone in the organisation learned about the incident.

What to do if the deadline falls on a weekend

If the 72-hour period expires on Sunday evening, completing the notification by 15:00 on Friday is the only safe organisational decision. The form on biznes.gov.pl is available online, but using a qualified electronic signature or trusted profile requires the availability of a person authorised to represent the organisation.

Sample timeline

Securing the account — before you start counting anything

The first hour after becoming aware of a breach should be spent securing the account, not analysing the incident. The order matters:

1. Change the passwords of all users in the provider’s application — yours, your accounting firm’s, your associates’ and former associates’
2. Enable two-factor authentication (2FA) on every account that does not yet have it
3. Review the list of users with access — does the accounting firm still need access, and do former associates still have active accounts?
4. Verify the bank account number in the application settings and on issued documents — compare it with the account number that is actually yours
5. Generate new API tokens and replace them in all integrations — including the accounting system, CRM and other tools
6. Revoke the KSeF integration token if the connection uses a token rather than a certificate — the process is quick and free of charge

If the provider has not confirmed that integration credentials were not downloaded, assume that they were.

How to count the data subjects — not the records

The notification form on biznes.gov.pl asks for the approximate number of natural persons, the categories of individuals and the categories of data. It does not ask for the number of database records. One person with ten invoices is still one person.

Whom you need to count

An inventory of a typical B2B company’s invoicing database reveals categories you may not initially consider:

In the anonymised incident on which this article is based, the inventory identified several dozen natural persons — in a database that initially appeared to contain “companies only”.

When an invoice becomes health data

If you rebill employees or associates for non-salary benefits — medical packages, sports packages or insurance — review the line-item descriptions on issued invoices, not the names of the services in the agreement with the benefits provider.

Article 4(15) GDPR defines data concerning health as personal data related to the physical or mental health of a natural person, including the provision of healthcare services, which reveals information about their health status.

If the leak included invoices naming specific medical services, you are dealing with special categories of data under Article 9 GDPR. This will usually determine that the individuals must be notified under Article 34.

Note: there is no official position from the UODO or EDPB establishing an unequivocal rule that “medical package = special category of data”. The classification depends on the content and context of the information. A safe rule is that the more detailed the line-item description, the greater the risk that it falls within Article 9.

Initial notification — how to meet the deadline when you do not know the full extent of the breach

The provider announces that it will launch a dashboard showing what data was downloaded from your account, from what periods, and how many records were taken. The dashboard is not available during the first few days. Waiting for it means waiting until your notification is late.

Article 33(4) GDPR expressly permits information to be provided in phases: “Where, and in so far as, it is not possible to provide the information at the same time, the information may be provided in phases without undue further delay.”

The alternative to an initial notification is not a more precise notification. It is a late notification.

How to complete the initial notification

1. Go to biznes.gov.pl and select the online service for reporting a personal data breach
2. In field 1.A, select the notification type: initial
3. Enter approximate figures and ranges — the form allows this
4. For information you do not yet know, clearly mark it as: “under investigation”
5. Sign the notification using a qualified electronic signature or trusted profile — it must be signed by the body authorised to represent the controller (the management board), not the DPO or an attorney-in-fact (unless they have the appropriate authority)
6. Keep the submission confirmation

EDPB Guidelines 9/2022 (published by the UODO) describe three forms of notification: complete, initial and supplementary. An initial notification is intended to ensure that the deadline is met. It does not release you from the obligation to provide additional information once it becomes available.

Supplementary notification

After receiving details from the provider — usually several days after the incident — you submit a supplementary notification using the same form and selecting the “supplementary/amending” option. You add categories omitted earlier: recipients and payers named in the documents, the exact number of individuals and the period covered by the data.

Risk assessment and the management board’s decision

Before submitting the notification, conduct a risk assessment and seek the opinion of the data protection officer (if one has been appointed). The management board’s decision must leave an audit trail — minutes, a memo or an email with the date and time.

In the event of an invoicing data leak, the main risk is not the takeover of an account in the application. It is bank account substitution fraud.

An attacker who has downloaded the invoicing database knows:

1. The parties to each transaction — who invoices whom
2. The amounts — the value of each payment
3. Payment status — which invoices remain unpaid
4. Bank account numbers — where previous payments were sent

This makes it possible to prepare a message indistinguishable from a genuine one: “Please be advised that our bank account number has changed. Please pay invoice no. X for the amount of Y into the new account Z.” An employee in the business partner’s finance department has no reason to be suspicious.

Organised criminal groups specialising in this type of fraud operate in Poland. In disclosed cases, losses exceeded PLN 4 million, while assets worth more than PLN 21 million were secured (Central Bureau for Combating Cybercrime, 16.06.2025; Central Bureau for Combating Cybercrime, 18.08.2026).

Basing the risk assessment solely on the provider’s assurance that “passwords were encrypted” is insufficient. Passwords are one issue. Invoicing data — numbers, amounts, bank accounts and addresses — is another.

Communication to business partners — three elements and nothing more

Article 34(1) GDPR requires data subjects to be notified where the breach “is likely to result in a high risk to the rights and freedoms of natural persons”. The notification must be written in clear and plain language.

Article 34(2) GDPR (in conjunction with Article 33(3)(b), (c) and (d)) requires the communication to contain at least: a description of the nature of the breach, the DPO’s contact details, a description of the likely consequences and a description of the remedial measures taken. The UODO also points out the need to provide practical recommendations to individuals.

In the context of an invoicing data leak, the communication should contain three elements and nothing more:

1. The incident occurred at the provider — a brief description of the incident, without technical details
2. Our bank account number has not changed — this is the most important operational information
3. Confirm every request to change the bank account by telephone using a previously known number — a specific protective recommendation

Keep a copy of the communication, the date it was sent and the number of recipients. Attach this information to the supplementary notification.

The UODO has not published an official template for a communication under Article 34 GDPR — only materials describing the required elements are available.

Breach register — even if you do not submit a notification

Article 33(5) GDPR requires the documentation of every personal data breach — its circumstances, consequences and the remedial action taken. This obligation applies regardless of whether you decide to notify the UODO.

If you have decided that there is no risk and you will not submit a notification — the reasons for that assessment must be included in the breach register entry. Failure to make an entry after deciding “we will not report it” constitutes a separate basis for finding an infringement during a UODO inspection.

The breach register entry should include:

1. The date and time when you became aware of the breach
2. A description of the incident and its circumstances
3. The categories of individuals and data affected by the breach
4. The risk assessment and its reasoning
5. The decision whether or not to report the breach, together with the reasons
6. A description of the remedial action taken
7. The date of notification to the UODO (if applicable) and the date of communication to the individuals

Requesting information from the SaaS provider

Article 28(3)(f) GDPR provides a legal basis for requesting specific information from the provider. The processor is required to assist the controller in fulfilling its obligations under Articles 32–36 GDPR.

Send the provider a single letter through an official channel — not through a user support ticket, but in your capacity as the data controller. Refer to Article 28(3)(f) and ask:

1. Whether your account is among those affected by a complete data download
2. What data was downloaded and what period it covered
3. When a dashboard or report containing detailed information will be available
4. Whether the KSeF credentials for your account were downloaded

Keep the correspondence. The provider’s response (or lack of response) will affect your assessment of your future relationship and any potential claims.

KSeF and the risk of bank account substitution

KSeF standardises the handling of the invoice itself — a centralised record and a QR code for verification may reduce the risk of a document being altered after it is issued. However, KSeF is not a bank account verification mechanism. The available materials from the Ministry of Finance do not describe any function for blocking bank account changes or comparing an account with the register of taxpayers (ksef.podatki.gov.pl).

Additional gaps:

1. Invoices may be issued outside KSeF in offline and emergency modes
2. The obligation to include the KSeF number with payments has been postponed until the end of 2026
3. A payment instruction sent outside the system is not subject to any KSeF verification

Implementing KSeF does not eliminate the need to verify bank account changes independently. Introduce a standing rule: confirm every change to a supplier’s bank account number by telephone using a previously known number and check it against the VAT taxpayer register.

Concurrent obligations — the GDPR and the National Cybersecurity System Act

The same event may require two separate notifications:

Neither notification replaces the other. The fact that the provider reported the incident to CERT Polska does not release you from your obligation — if your company is an entity covered by the National Cybersecurity System Act.

Is your company subject to the National Cybersecurity System Act? This requires an analysis of the full text of the Act and its transitional provisions. If you operate in the energy, transport, health, digital infrastructure, finance, digital services, food or waste sector and are not a micro-enterprise — check this before an incident, not during one.

First 72 hours playbook — checklist

Prepare these documents before an incident occurs. There will be no time to create them during an incident.

Pitfalls that only become apparent during an incident

1. Waiting for the provider’s dashboard — a tool showing the extent of the leak from your account may not be launched until several days later, after the notification deadline has passed. Do not wait.
2. Counting records instead of individuals — the form asks about individuals. One person with ten invoices is still one person.
3. Omitting named email addresses — jan.kowalski@firma.pl is personal data, even when the “first name” and “surname” fields in the records are blank.
4. Treating partnerships solely as entities — civil-law partnerships and registered partnerships add their partners’ personal data to the data set.
5. Basing the assessment on “encrypted passwords” — in an invoicing data leak, the risk is not account takeover but payment fraud.
6. Failing to make a register entry after deciding “we will not report it” — this constitutes a separate basis for finding an infringement during an inspection.
7. The work exceeding the scope of a legal services subscription — handling a single incident will realistically exceed standard hourly limits. Be prepared for hourly billing.

How we can help you

Handling a personal data breach within 72 hours requires simultaneous action in three areas: legal, organisational and communications. Most companies lack the internal resources to manage this on their own — especially during their first incident.

We support B2B companies and technology firms in two ways:

Reactive support — when an incident is already in progress:

1. Determining when you became aware of the breach and verifying the deadline
2. Risk assessment and legal opinion for the management board
3. Preparing and submitting an initial notification to the UODO
4. Preparing the communication to data subjects
5. Making an entry in the breach register
6. Submitting a supplementary notification after obtaining data from the provider
7. Sending a letter to the provider under Article 28(3)(f) GDPR

Preventive support — before an incident occurs:

1. A first 72 hours playbook with document templates
2. Review of data processing agreements with SaaS providers — deadlines, scope of information and contact channels
3. A procedure for verifying changes to bank account numbers
4. Training for finance and sales teams on the bank account substitution fraud scenario
5. Review and update of the breach register

Contact us

Data leak at a SaaS provider — summary and next steps

A SaaS provider’s notification to the UODO does not replace your notification. The 72-hour period starts when anyone in your organisation learns about the incident. An initial notification containing approximate figures is better than a late notification containing exact figures. You must maintain a breach register even if you determine that there is no risk.

The greatest threat after an invoicing data leak is not a fine from the UODO. It is a payment made to a substituted bank account — because the attacker knows your business partners, the amounts and which invoices remain unpaid.

Prepare a playbook before you need one. And if an incident is already in progress — contact us. We will help you submit the notification on time and protect your company against financial and legal consequences.

Frequently asked questions

The provider has already reported the breach to the UODO — why should I report the same thing again? It is not “the same thing”. The provider reported the breach as the controller of its own data — the service’s user accounts. Your business partners’ details in the records and the contents of invoices have a different controller: you. Article 33(1) GDPR places the notification obligation on the controller, while Article 33(2) requires the processor to notify the controller — not the authority. The processor’s notification triggers your obligation but does not fulfil it.

Exactly when does my 72-hour period start? When the controller becomes aware of the breach — that is, when anyone in your organisation learns about the incident. Not on the date of the attack on the provider and not on the date of its announcement. If your employee read an announcement on the provider’s website before you did — the deadline starts running from that earlier time. That is why the first step is to ask your team and record the exact date and time.

What should I do if the deadline is approaching and the provider has not yet told me the extent of the leak from my account? Submit an initial notification. Article 33(4) GDPR allows information to be provided in phases — enter approximate figures, mark items as “under investigation” and provide additional information once you obtain it. The form on biznes.gov.pl includes the “initial” notification type specifically for situations like this. Waiting for the provider’s dashboard means waiting until your notification is late.

Do I need to notify all business partners, or is an announcement on the website enough? Article 34(1) GDPR requires individuals to be notified when the breach is likely to result in a high risk. In the event of an invoicing data leak — where the attacker knows the parties to transactions, the amounts and which invoices remain unpaid — the risk of bank account substitution fraud is real. Article 34(3)(c) permits a public communication instead of individual notifications where contacting each person individually would involve disproportionate effort. With several dozen individuals, individual notification is feasible and safer.

I rebill employees for a medical package — does this mean health data has been leaked? It depends on the invoice line-item descriptions. The description “medical package” alone is unlikely to reveal a person’s health status. A description such as “rehabilitation” or “cardiology consultation” does, because it indicates the use of a specific healthcare service. Review the line-item descriptions on issued documents, not the names of the services in the agreement with the benefits provider. If you find the names of specific services — this increases the assessed risk and will usually determine that the individuals must be notified under Article 34.

If I determine that there is no risk and do not report the breach, do I still need to document anything? Yes. Article 33(5) GDPR requires every breach to be documented — including its circumstances, consequences and the remedial action taken. This obligation applies regardless of whether you decide to submit a notification. If you have decided that there is no risk — the reasons for that assessment must be included in the breach register entry. Failure to make an entry constitutes a separate basis for finding an infringement during a UODO inspection.