Fakturownia Data Breach: Who Is Responsible and What Businesses Should Do
In late September 2026, an unknown person gained access to the systems of the Polish service Fakturownia and copied a significant part of its database. The incident affected all accounts, but the type of information available to the attacker differs depending on the period when it was added and the functions used.
For businesses, the main difficulty is that the service provider itself was hacked, while GDPR obligations may also arise for its customers. If a company or individual entrepreneur stored in Fakturownia the data of their customers, buyers, contractors, or employees of counterparties, the service user remains the controller of this data.
At the same time, the most likely losses are not limited only to fines or compensation claims. Information about invoices, payments, counterparties, and bank details can be used to create convincing emails requesting that money be transferred to a new account.
We analyze which data was affected, whether it is necessary to notify the Polish regulator UODO, and how businesses should act after the data breach.
What Happened to Fakturownia
According to Fakturownia’s official information, unauthorized access continued from approximately 03:20 on 27 September until approximately 17:45 on 28 September 2026.
The attacker gained access to the system and copied the data to their own servers. The incident was classified as a confidentiality breach: the information was not simply viewed but was extracted from the service’s infrastructure.
After discovering the attack, Fakturownia blocked access, replaced system keys and passwords, moved traffic to new servers, and deactivated compromised keys. On 29 September, the service reported the incident to UODO, CERT Polska, and the police, and on 1 October began sending individual notifications to account owners and users.
However, a notification submitted by Fakturownia itself does not always release its customers from their own assessment of the incident. To apply GDPR requirements, it is necessary to determine whose data was stored in the specific account and what role each party performed.
What Data Was Copied
According to the service, the exported database could contain:
- company names, NIP numbers, addresses, and bank details
- users’ first names, surnames, email addresses, and phone numbers
- password hashes, session identifiers, API tokens, and integration keys
- counterparty information, including names, addresses, NIP numbers, phone numbers, email addresses, and account numbers
- invoice amounts, payment information, and outstanding debts
- the full content of some older invoices
- names of goods and services from certain documents
- information about payments, goods, price lists, and warehouse operations
- data from completed imports and exports
Different time limits apply to different categories. For example, the full content was copied only for invoices issued before 22 March 2021, while invoice line items were copied for documents created before 6 June 2019. At the same time, amounts, certain descriptive fields, and data of additional invoice parties could have been included in the export for later periods as well.
According to the official statement, KSeF certificates, internet banking login details, and payment card data were not affected. Fakturownia does not store banking login credentials or card details. The exact scope of information should be checked in the incident panel inside the account. The service’s general statement alone is not sufficient for an individual risk assessment.
Why Different Parties Are Responsible for the Same Incident
Fakturownia performs different roles depending on the category of information. With regard to the data of account owners and service users, Fakturownia independently determines the purposes and means of processing. For this data, it acts as the controller.
A different situation arises with information that a customer entered into the system about their own customers, buyers, contractors, or other individuals. In this case, the customer remains the controller, while Fakturownia acts as a processor that stores the information on the customer’s behalf.
Therefore, a company using the service for issuing invoices must independently determine:
- whether the affected information relates to personal data
- which individuals were affected
- what consequences may arise for them
- whether UODO needs to be notified
- whether the affected individuals themselves need to be informed about the breach
Fakturownia may provide the categories of affected data, the timeline, and a technical description of the incident. However, the service does not know the context of the relationship between the customer and the individuals mentioned in the invoices, and therefore cannot perform the final risk assessment on behalf of the user.
Which Information Is Considered Personal Data
Data relating to a legal entity itself generally does not constitute personal data. The name of a sp. z o.o., its NIP number, registered address, or a general email address such as biuro@company.pl usually does not allow a specific individual to be identified.
However, invoices and counterparty records may contain employees’ names, individual email addresses, phone numbers, and personal bank accounts. Such information relates to individuals and falls under the GDPR.
Information about an individual entrepreneur registered as a JDG is also considered personal data, even if some of it is publicly available in CEIDG. The public availability of information does not change its legal nature.
At the same time, UODO indicates that a breach involving only publicly available information from CEIDG, such as a person’s name, business name, NIP number, and official address, usually creates a low risk. The assessment may change if account numbers, payment history, purchase information, contact details, or other information useful for fraud and social engineering are disclosed together with this data.
When UODO Must Be Notified
Article 33 of the GDPR requires notification of the supervisory authority if a breach may create a risk to the rights and freedoms of individuals. UODO must be notified not because of the scale of the attack itself, but based on an assessment of the specific data involved. The consequences of the same Fakturownia incident may differ for two users.
For example, a company that issued invoices only to legal entities and stored publicly available corporate details may conclude that a risk to individuals is unlikely.
A different assessment would be required for a clinic, psychologist, online store, B2C service, or professional who worked with individuals. Personal identification numbers (PESEL), personal bank accounts, information about purchased services, health data, and other information that can enable fraud or reveal confidential details about a person are particularly significant.
Even if notification to UODO is not required, the company must record the incident in its internal breach register. The record should state what happened, what data was affected, what risks were considered, and why the decision was made not to submit a notification.
From Which Moment Are the 72 Hours Counted
The notification must be submitted without undue delay and, where possible, no later than 72 hours after the controller becomes aware of the breach with a sufficient degree of certainty.
When the incident occurs at a processor, this moment is usually when the controller receives information from the processor. For many Fakturownia account owners, this may be the email sent on 1 October 2026. However, the moment may be earlier if the company already received sufficiently specific information from Fakturownia’s official announcement of 29 September or from another reliable source.
Therefore, the documentation should record not only the date of the email but also the moment when the company actually obtained sufficient information that the data from its account may have been affected. If 72 hours have already passed, this does not remove the obligation to submit a notification. The GDPR allows a later notification if the reasons for the delay are explained. If information is incomplete, an initial notification may be submitted and later supplemented as the analysis progresses.
A delayed notification with an explanation is generally preferable to complete inaction if the assessment shows that a risk exists.
Do Counterparties Need to Be Informed?
Notification to UODO and notification to affected individuals are two different obligations. A person must be informed under Article 34 of the GDPR when the breach is likely to result in a high risk to their rights and freedoms. For ordinary risk, notification of the regulator is sufficient. For low risk, neither external notification may be required, although internal documentation remains mandatory.
A high risk may arise if the breach includes PESEL numbers, health information, personal financial data, or detailed information that allows someone to convincingly impersonate a company, bank, or counterparty.
The notification should be written in clear language and explain:
- what happened
- which categories of data were affected
- what consequences are possible
- what the company has already done
- what actions the person is recommended to take
- where to contact for additional information
The GDPR does not require a paper letter to be sent to every counterparty in all cases. If individual notification would require disproportionate efforts, it may be replaced with a public announcement or a similar measure that informs affected individuals equally effectively.
However, publishing an announcement on a website is not automatically a replacement for individual notifications. The company must justify why direct contact with individuals is impossible or disproportionately difficult and why the chosen method will allow them to actually become aware of the incident.
The Main Practical Risk Is the Substitution of Bank Details
The attacker may have obtained real amounts, payment dates, names of goods and services, information about outstanding debts, and bank account numbers.
This data makes it possible to create an email that looks like a continuation of a genuine conversation. The recipient may see the correct company name, the old account number, the usual amount, and a familiar project description. The only difference will be the new bank account number. To use such a scheme, the attacker does not necessarily need access to the company’s email. It is enough to send the accounting department a convincing message on behalf of a supplier asking to use updated payment details.
After the incident, businesses should establish a separate rule: any change of bank account details must be confirmed through an independent channel. The call should be made to a phone number that was known before receiving the email, not to contact details provided in the message containing the new account information.
A Polish VAT payer’s account should additionally be verified in the VAT taxpayer white list. However, such verification does not replace confirmation with the counterparty itself, especially when working with foreign companies, individuals, and suppliers who are not registered as VAT payers.
For significant transfers, it is useful to introduce dual approval: one employee verifies the document and counterparty, while another independently confirms the payment.
What Fakturownia Users Need to Do
Companies and entrepreneurs who used the service should take the following steps:
- Save the Fakturownia email and record the date and time it was received.
- Open the incident panel and determine the categories, periods, and number of affected records.
- Change the password, review account users, and enable two-factor authentication.
- Update API keys and check all connected integrations.
- Make sure that correct bank details are stored in invoice templates.
- Determine whether the account contained data of individuals, JDG entrepreneurs, employees of counterparties, or consumers.
- Separately identify PESEL numbers, personal accounts, health information, and other confidential data.
- Conduct and document a risk assessment.
- Notify UODO if the breach may create a risk for individuals.
- Inform affected individuals if the risk is high.
- Warn the accounting department and counterparties about possible substitution of payment details.
- Review retention periods for old data and delete information that is no longer needed and is not subject to mandatory retention.
Old invoices should not be automatically deleted solely based on the document date. Tax retention periods, ongoing audits, disputes, limitation periods, and other lawful grounds for retention must be taken into account. However, keeping information without a defined purpose and retention period also contradicts the principle of storage limitation.
Who Is Responsible for the Damage Caused
Article 82 of the GDPR allows an individual to claim compensation for material or non-material damage from a controller or processor.
The controller is responsible for violations related to processing carried out under its control. The processor is responsible if it violated obligations directly imposed on processors by the GDPR or acted outside the lawful instructions of the controller.
If several parties participated in the same processing operation and are responsible for the damage caused, the affected person may claim full compensation from any of them. After payment, the parties may distribute the costs between themselves through recourse claims, taking into account their respective share of responsibility.
This does not mean that a Fakturownia customer is automatically responsible for all consequences of the breach or that all responsibility unquestionably lies with the service provider. It is necessary to determine what violations were committed by each party, whether security measures were sufficient, and how the specific violation is connected to the damage.
The Court of Justice of the European Union in case C-340/21 clarified that the mere fact of a successful cyberattack does not prove that security measures were insufficient. However, the controller must be able to demonstrate that appropriate technical and organizational measures were implemented.
The Court also recognized that a justified fear of possible unlawful use of data may constitute non-material damage. At the same time, the affected person must demonstrate the existence of actual harm and a connection with the breach. A GDPR violation alone is not sufficient to award compensation.
Limitation of Liability in the Service Terms
Fakturownia’s terms limit the service’s liability towards customers who are not consumers to the amount of the current subscription fee and actual damage. In addition, the relevant provision links contractual liability to a culpable and intentional act of the provider.
However, the existence of such a clause does not mean that all claims are excluded in advance. Its applicability depends on the customer’s status, the circumstances of the breach, mandatory provisions of Polish law, and the legal basis of the specific claim.
A contractual limitation of liability also does not remove the rights of affected individuals under Article 82 of the GDPR and does not restrict UODO’s powers. Therefore, companies should not assume that all costs of investigation, notifications, legal assistance, or fraudulent transfers can automatically be recovered from the service provider.
What This Incident Teaches SaaS Companies
The Fakturownia incident is important not only for users of accounting services. It demonstrates the risks of any SaaS product where customers store data of their own clients.
After discovering an incident, a processor must inform controllers without undue delay and provide the information necessary for risk assessment. Without this, customers will not be able to fulfill their own obligations within the 72-hour period.
A DPA should define an emergency communication channel, responsible persons, the content of the initial notification, and the procedure for subsequent updates. It is useful to establish a specific internal notification deadline that is shorter than the regulatory 72-hour period.
A SaaS provider should also prepare an incident response plan in advance: infrastructure isolation, key replacement, log collection, cooperation with external specialists, customer communication, and preservation of evidence.
Retention periods are a separate issue. The existence of a tax obligation to retain certain documents does not mean that all information must remain indefinitely in the main production database. A service may provide for deletion of unnecessary data, archiving, separate encryption of older periods, and clear retention settings.
What Should Be Checked in Agreements with SaaS Providers
The incident shows that a standard GDPR reference in a user agreement is not sufficient. Companies should check:
- whether a DPA has been concluded
- which categories of data are transferred to the service
- where the data is physically stored
- whether subprocessors are involved
- within what period the provider reports incidents
- which information the provider must provide
- whether data can be exported and deleted
- how backups are organized
- whether audits and confirmation of security measures are provided for
- how contractual liability is allocated
Wolja Digital helps companies assess whether notification to UODO is required, prepare incident documentation, and draft communications for affected individuals. For SaaS projects, we develop DPAs, breach response policies, and contractual mechanisms that allow companies to act according to a prepared plan rather than create one after an attack has already occurred.
A breach at a service provider does not always mean that its customer violated the GDPR. However, after receiving a notification, inaction is no longer an option: it is necessary to determine the scope of affected data, assess the risk, and document the decision made.