A stack of printed invoices and a binder on a desk in the back room of a small business, with a closed laptop next to them

Fakturownia data breach: what to report to the UODO and when

In brief

  • Unauthorized access to Fakturownia servers lasted through September 27 and 28, 2026. The company reported the breach to the President of the UODO on September 29.
  • Notices to users went out by email on October 1. From the day you learned about the case, you count your own 72 hours for a report under Article 33 of the GDPR.
  • In scope are account data, password hashes, session tokens plus API and integration tokens, bank account numbers, and invoices issued before 2023.
  • The report filed by Fakturownia is not a report on your behalf: for your business partners' data, you are the controller.
  • The most realistic risk: a fake invoice with a changed account number, sent to your client.

The Fakturownia data breach is the result of the break-in of September 27 and 28, 2026, which the company confirmed in its statement of September 29. If you invoice in this system, you now have two jobs: secure the account and decide whether you report the breach to the UODO yourself.

What happened at Fakturownia

According to the company statement someone exploited a flaw in the PDF generation mechanism, reached the configuration files, and then gained read access to a replica of the production database. Fakturownia writes that the incident concerns every account, although the scope of data differs from one to the next.

The attacker signing as “Fingerprint” claims to have taken about 6 terabytes of invoices. The write-up at Niebezpiecznik indicates that for about 2,250 accounts everything in the system was downloaded. KSeF certificates and payment card data stayed outside that scope.

September 27 and 28 the window of unauthorized access

approx. 2,250 accounts with the full scope of data from the system

72 hours to report, counted from finding the breach

If you do not know where the Fakturownia keys sit in your site or store, start with a free website and store audit and write your integrations down on paper.

Who in Poland is affected by the Fakturownia data breach

Every account, but not every one to the same degree. A bakery with two invoices a month has a different scope than a clinic that keeps patient names in the buyer field, or a repair shop invoicing a fleet for several companies.

The problem sits on your business partners' side. Invoices hold names, addresses, NIP tax numbers and bank account numbers, sometimes the names of private individuals. You are the controller of that data, and Fakturownia was the processor.

What this means for your business

An invoice, an account number, and a real payment history are ready-made material for the “we have changed our bank account number” scam. Your client gets a message where the amount, the date, and the name of the service all match, so nothing sets off an alarm. More urgent than the report itself is warning your clients and agreeing with them that any change of account is confirmed by phone. The second issue is tokens: if your store issues invoices automatically, the integration token may have leaked along with the rest.

What to do now

  1. Set your own date. Find the email with the personal data breach notification and write down when you received it. Your 72 hours run from that moment, not from the date of the Fakturownia statement.
  2. Close the door. Change the password, turn on two-step login, generate your API and integration tokens again, and disconnect the ones you no longer use.
  3. Assess the risk and decide. A report under Article 33 of the GDPR is required when the breach may result in a risk to the rights or freedoms of natural persons. You also file after the deadline, adding the reason for the delay. Whatever you decide, enter the event in your breach register.
  4. Warn your business partners. A short message: what happened, which of their data may have leaked, and that your account number is not changing. We described how to send it across your whole list in the guide to the first email campaign for a small business.
  5. Check your store. Invoicing usually hangs on a plugin with a saved key, and with older integrations nobody remembers that key anymore. This is the step from the guide to setting up an online storethat gets forgotten the fastest.

Note

Changing the password alone is not enough if you do not rotate the tokens. An API token works independently of the password, and in WooCommerce stores it is often entered in two places: in the invoicing plugin and in an old automation.

The French thread: VosFactures

The same technology runs in France under the VosFactures brand. According to reporting by CyberDefence24 the French publisher of the service learned about the attack from the Polish provider on September 29, and the French agency responsible for e-invoicing suspended data exchange with the platform. So the case is under supervisory scrutiny in two countries.

What we still do not know

We do not know how many reports from controllers have reached the UODO in this case. There is also no confirmation whether 6 terabytes is the real scale or just a number from the attacker's announcement, nor whether the data went up for sale. This is a description of events, not legal advice: talk the risk assessment for your own database through with a lawyer or a data protection officer.

If you want someone from the outside to review the integrations and forms on your site, order a free audit or call 511 608 362, Mon-Fri 10am-6pm.

Frequently asked questions

Do I have to report the Fakturownia breach to the UODO?

Not automatically. The duty arises when the leak may put at risk the people whose data sits in your invoices, and you make that assessment for your own scope of data. Write the decision and the reasons for it in your breach register.

The 72 hours are up, what now?

You file the report and explain the reason for the delay. Missing information can be added in a follow-up letter.

Did the passwords to my account leak?

According to the company statement, password hashes are in scope, that is, scrambled versions of them, not passwords in plain form. If you use the same password in another service, change it there too.

Share this article