W niedzielę 27 września 2026 roku, w nocy, ktoś zalogował się do infrastruktury jednego z najpopularniejszych w Polsce programów do wystawiania faktur i zaczął kopiować bazę danych. Kopiowanie trwało do poniedziałku 28 września. Tego dnia spółka wykryła nieuprawniony dostęp, zablokowała napastnika, wymieniła klucze i przeniosła usługę na nowe serwery. We wtorek 29 września opublikowała komunikat. O godzinie 18:51 informacja trafiła do serwisów ogólnopolskich, a wieczorem wicepremier Krzysztof Gawkowski zapewnił, że sprawcy „są ścigani i poniosą surowe konsekwencje".

Tymczasem w jednej ze spółek komunalnych pod Rzeszowem referentka z księgowości, która od lat wystawia przez Fakturownię faktury za wywóz nieczystości, otworzyła we wtorek rano pocztę i znalazła wiadomość z tematem „Informacja o incydencie bezpieczeństwa". Przeczytała ją, uznała, że to sprawa dostawcy, i wróciła do pracy. Nikt nie powiadomił prezesa, nikt nie zajrzał do umowy powierzenia, nikt nie policzył godzin. A one płynęły.

Ta historia jest wymyślona, ale każda jej scena zdarza się dziś w setkach polskich firm. Wyciek z dostawcy oprogramowania działa jak awaria wspólnego przewodu: wszyscy odbiorcy dowiadują się o niej w tej samej minucie, a każdy z nich dostaje własny, osobny rachunek obowiązków. Poniżej tłumaczymy, jak ten rachunek wygląda w przypadku Fakturowni, i dlaczego bez względu na to, kim jest sprawca, ciężar odpowiedzialności za dane kontrahentów leży w twoim biurze, nie w serwerowni dostawcy.

Co ustalono, a co jest tylko doniesieniem prasowym

Zacznijmy od rozdzielenia faktów od atrybucji, bo w tej sprawie granica jest cienka. Spółka potwierdziła, że osoba nieuprawniona miała dostęp do jej systemów w nocy z 27 na 28 września, że skopiowała znaczną część bazy i że incydent dotyczy wszystkich kont użytkowników. Według komunikatu ujawnieniu mogły ulec dane kont, skróty haseł, dane kontrahentów dodanych do 16 października 2024 roku (nazwy, numery NIP, adresy, dane kontaktowe), dane z faktur z różnych okresów, numery rachunków bankowych i informacje płatnicze, tokeny API i klucze integracyjne oraz identyfikatory sesji. Spółka zaznacza, że nie przechowuje certyfikatów KSeF, danych logowania do bankowości ani numerów kart płatniczych, więc te elementy nie mogły wyciec.

Media podają tu różne granice czasowe: część mówi o fakturach sprzed 2023 roku, komunikat spółki o kontrahentach z okresu sprzed 16 października 2024 roku. Różnica nie jest błędem dziennikarskim, tylko skutkiem tego, że różne kategorie danych mają różne okresy ekspozycji. Dla administratora wniosek jest praktyczny: nie opieraj oceny na nagłówku z portalu, tylko na komunikacie dostawcy i na szczegółach dla twojego konta, które spółka udostępnia po zalogowaniu.

Ministerstwo Finansów oświadczyło, że zdarzenie nie dotyczy danych zgromadzonych w Krajowym Systemie e-Faktur i że w samym KSeF nie stwierdzono naruszenia zasad bezpieczeństwa. To rozróżnienie ma znaczenie: ktoś, kto wyciągnął bazę dostawcy aplikacji, nie włamał się do państwowej infrastruktury. Spółka zgłosiła sprawę do Prezesa UODO, CERT Polska i Centralnego Biura Zwalczania Cyberprzestępczości, a indywidualne powiadomienia klientów zaczęła wysyłać 1 października. Media mówią o ponad sześciuset tysiącach klientów; to liczba z doniesień, a nie ustalenie organu.

Odrębną warstwą jest atrybucja. Serwis Zaufana Trzecia Strona łączy ten atak z tymi samymi sprawcami, którzy według doniesień stali za wyciekami z MyDr i Medyc, i wskazuje pseudonim „Fingerprint" oraz sześć terabajtów faktur. To hipoteza dziennikarska i tak ją traktujemy. Nie zmienia ona jednak ani jednej linijki obowiązków prawnych, bo art. 33 RODO nie pyta, kto włamał się do dostawcy, tylko kiedy administrator dowiedział się o naruszeniu.

Kto tu jest administratorem, a kto procesorem

Fakturownia, świadcząc usługę wystawiania i przechowywania faktur, występuje wobec swoich klientów jako podmiot przetwarzający w rozumieniu art. 4 pkt 8 RODO. To klient decyduje, jakie dane kontrahentów wprowadzić do systemu, w jakim celu i jak długo je trzymać, więc to klient jest administratorem danych z art. 4 pkt 7. Dostawca ma własny status administratora w zakresie danych swoich użytkowników, takich jak loginy czy dane rozliczeniowe konta, ale baza kontrahentów i faktur jest w jego rękach powierzona.

Konsekwencja jest ostra, choć rzadko wypowiadana na głos. Jeśli twoja spółka wprowadziła do systemu dane tysiąca odbiorców usług, w tym osób fizycznych prowadzących jednoosobową działalność, rolników i konsumentów, to naruszenie ich poufności jest twoim naruszeniem. Nie dlatego, że zawiniłeś, ale dlatego, że przepisy rozkładają ciężar odpowiedzialności według ról, a nie według winy technicznej. Dostawca odpowiada przed organem za własne uchybienia z art. 32 RODO i przed tobą za naruszenie umowy powierzenia z art. 28. Obowiązków zgłoszeniowych z art. 33 i 34 jednak za ciebie nie przejmie.

Ten sam mechanizm opisywaliśmy przy wycieku z systemu rezerwacyjnego w hotelach, w tekście o roli administratora i procesora w sprawie Hotres, oraz przy incydencie MyDr, gdzie tysiące przychodni dowiedziało się o własnym obowiązku z internetu. Fakturownia jest kolejnym w ciągu dwóch miesięcy przykładem tej samej konstrukcji. Za każdym razem inny sektor, ten sam błąd po stronie klientów: założenie, że komunikat dostawcy kończy sprawę.

Zegar z art. 33: od kiedy liczyć siedemdziesiąt dwie godziny

Art. 33 ust. 1 RODO nakazuje administratorowi zgłosić naruszenie organowi nadzorczemu bez zbędnej zwłoki, a jeżeli to możliwe, nie później niż w terminie siedemdziesięciu dwóch godzin od stwierdzenia naruszenia, chyba że jest mało prawdopodobne, by skutkowało ono ryzykiem naruszenia praw lub wolności osób fizycznych. Art. 33 ust. 2 nakłada na procesora obowiązek zawiadomienia administratora bez zbędnej zwłoki po stwierdzeniu naruszenia.

Kluczowe pytanie brzmi: od kiedy administrator „wie". Wytyczne Europejskiej Rady Ochrony Danych w sprawie powiadamiania o naruszeniach wskazują, że administrator jest świadomy naruszenia, gdy ma uzasadnioną pewność, że doszło do incydentu bezpieczeństwa skutkującego kompromitacją danych osobowych. Przy procesorze oznacza to, że zegar administratora rusza zwykle w chwili, gdy otrzyma on wiarygodną informację od dostawcy. Spór może dotyczyć tego, czy był to komunikat publiczny z 29 września, czy dopiero indywidualne powiadomienie z 1 października. My doradzamy ostrożność: wobec administratorów, którzy 29 września widzieli komunikat i znali skalę zdarzenia, rozsądnie jest przyjąć, że termin upłynął 2 października.

Dziś jest 6 października. Jeśli twoja firma nie zgłosiła jeszcze niczego do UODO i nie udokumentowała decyzji, że zgłoszenie nie jest wymagane, jesteś już poza terminem. To nie jest katastrofa. Art. 33 ust. 1 zdanie drugie przewiduje wprost, że zgłoszenie dokonane po upływie siedemdziesięciu dwóch godzin powinno zawierać wyjaśnienie przyczyn opóźnienia. Prezes UODO w decyzjach znacznie surowiej traktuje brak zgłoszenia i brak jakiejkolwiek dokumentacji niż zgłoszenie spóźnione o kilka dni, ale sensownie uzasadnione. Opisywaliśmy to przy okazji kar za brak współpracy z organem: najdroższa jest cisza.

Jedna uwaga praktyczna. Zgłoszenie można złożyć etapami, zgodnie z art. 33 ust. 4. Nie czekaj więc na komplet informacji z dostawcy. Złóż zgłoszenie wstępne z tym, co wiesz, i dosyłaj uzupełnienia. Organ woli niepełną informację dziś niż pełną za miesiąc.

Czy to wysokie ryzyko: dlaczego numer rachunku waży więcej niż PESEL

Zgłoszenie do organu wymaga oceny, że naruszenie może skutkować ryzykiem dla osób. Zawiadomienie osób, których dane dotyczą, z art. 34 RODO wymaga ryzyka wysokiego. Tu ocena w przypadku Fakturowni nie jest oczywista, więc warto ją przeprowadzić uczciwie, a nie z odruchu.

Po stronie łagodzącej jest to, że w bazie nie ma numerów PESEL w takiej skali jak w systemach medycznych, nie ma danych o zdrowiu i nie ma kart płatniczych. Dane kontrahentów to w większości dane firm. Po stronie obciążającej są trzy rzeczy. Po pierwsze, w bazie znajdują się dane osób fizycznych prowadzących działalność gospodarczą, rolników ryczałtowych i konsumentów, a więc osób, dla których adres i numer rachunku są jednocześnie danymi prywatnymi. Po drugie, kombinacja nazwy, NIP-u, adresu, numeru rachunku i historii faktur to gotowy materiał do oszustwa. Po trzecie, dane z faktur ujawniają relacje handlowe: kto komu i za co płaci, w jakich kwotach i w jakich terminach.

Najbardziej realnym scenariuszem nie jest kradzież tożsamości w klasycznym rozumieniu, tylko oszustwo „na fakturę". Napastnik, który zna prawdziwy numer faktury, kwotę, termin płatności i nazwę dostawcy, wysyła kontrahentowi wiadomość o zmianie numeru rachunku bankowego. Wiadomość jest tak wiarygodna, że księgowa, która widzi swój własny numer dokumentu, nie ma powodu jej kwestionować. Straty z takich oszustw w polskich firmach liczy się w dziesiątkach tysięcy złotych na jedno zdarzenie, a odzyskanie pieniędzy po trzech dniach jest rzadkie. To właśnie dlatego uważamy, że dla większości klientów Fakturowni ocena „ryzyko jest wysokie" jest bezpieczniejsza i lepiej obroniona niż ocena odwrotna, zwłaszcza jeśli w systemie były dane osób fizycznych.

Pamiętaj, że sama decyzja o niezgłaszaniu jest też decyzją, którą trzeba udokumentować. Art. 33 ust. 5 RODO wymaga od administratora prowadzenia rejestru wszystkich naruszeń, wraz z okolicznościami, skutkami i podjętymi działaniami zaradczymi, także tych, których organowi nie zgłoszono. Brak wpisu w rejestrze po wycieku o takiej skali jest samodzielnym uchybieniem, ujawnianym przez organ w kilka minut.

Skróty haseł, klucze API i sesje: co jest groźniejsze od samych faktur

Dane kontrahentów robią największe wrażenie w nagłówkach, ale z operacyjnego punktu widzenia groźniejsze mogą być elementy techniczne. Komunikat spółki wymienia tokeny API i klucze integracyjne oraz identyfikatory sesji. To są obiekty, które pozwalają działać w imieniu konta bez znajomości hasła.

Spółka twierdzi, że po wykryciu rotowała klucze po swojej stronie. To jednak nie unieważnia kluczy, które twoja firma wygenerowała i wkleiła do integracji ze sklepem internetowym, systemem magazynowym, programem do windykacji lub bankiem. Takie klucze trzeba wymienić ręcznie i zrobić to po wycieku, a nie w następnym kwartale. Na tej samej zasadzie hasło do konta należy zmienić, a wszędzie, gdzie było używane powtórnie, także. Skróty haseł to nie hasła, ale ich odporność zależy od algorytmu i soli, których nie znamy, a ataki słownikowe na słabe hasła są tanie. Ostrożność kosztuje pięć minut, a ryzyko to dostęp do wystawiania faktur w imieniu spółki.

W praktyce proponujemy trzy ruchy w kolejności: unieważnić wszystkie sesje i klucze, włączyć uwierzytelnianie dwuskładnikowe dla każdego użytkownika konta, a następnie przejrzeć listę użytkowników i uprawnień. Ten ostatni krok najczęściej ujawnia konta byłych pracowników i biur rachunkowych, które od roku nikt nie używa. Na koniec warto przejrzeć dziennik zdarzeń konta pod kątem nietypowych logowań i zmian numerów rachunków na własnych fakturach.

Zawiadomienie kontrahentów: kiedy obowiązek, a kiedy dobra praktyka

Art. 34 RODO wymaga zawiadomienia osoby, której dane dotyczą, gdy naruszenie może powodować wysokie ryzyko, i to bez zbędnej zwłoki. Treść ma być napisana prostym językiem i zawierać co najmniej opis charakteru naruszenia, dane kontaktowe inspektora lub innego punktu kontaktowego, opis możliwych skutków oraz środki zastosowane lub proponowane w celu zaradzenia naruszeniu.

W przypadku Fakturowni najważniejsze praktyczne pytanie dotyczy kontrahentów będących firmami. Formalnie RODO chroni tylko osoby fizyczne, ale kontrahent, który otrzyma od ciebie ostrzeżenie „mogło dojść do ujawnienia naszych danych bankowych, prosimy o weryfikację telefoniczną każdej zmiany rachunku", zyska realną ochronę przed oszustwem. Dla ciebie to również ochrona wizerunku, bo klient, który dowie się o wycieku od oszusta, a nie od ciebie, nie zapomni tej kolejności.

Dobry komunikat do kontrahentów ma pięć zdań, nie pięć stron. Mówi, co się stało, jakie dane mogły być ujawnione, co kontrahent ma zrobić, jak nie dać się oszukać i z kim się kontaktować. Nie przepraszamy w nim wylewnie, nie tłumaczymy architektury chmury i nie obiecujemy rzeczy, których nie kontrolujemy. Opisywaliśmy to w tekście o zawiadamianiu pacjentów po wycieku MyDr; zasady redakcji są takie same, zmienia się tylko adresat.

Umowa powierzenia: co sprawdzić w dokumencie, który leżał w szufladzie

Art. 28 ust. 3 RODO wymaga umowy lub innego instrumentu prawnego, który określa przedmiot i czas przetwarzania, charakter i cel, rodzaj danych i kategorie osób oraz obowiązki i prawa administratora. Wśród obowiązkowych postanowień są: zobowiązanie procesora do zawiadamiania administratora o naruszeniu bez zbędnej zwłoki, do pomocy przy realizacji obowiązków z art. 32–36 i do udostępniania informacji niezbędnych do wykazania zgodności oraz umożliwienia audytów.

Po takim zdarzeniu otwórz swoją umowę z dostawcą i sprawdź cztery rzeczy. Czy zawiera konkretny termin powiadomienia o naruszeniu, a nie sformułowanie „niezwłocznie". Czy daje prawo do uzyskania raportu poincydentowego. Czy wskazuje listę podprocesorów i miejsce przetwarzania. Czy przewiduje odpowiedzialność odszkodowawczą w zakresie wykraczającym poza opłatę abonamentową za kilka miesięcy. W wielu umowach standardowych dostawców SaaS odpowiedź na ostatnie pytanie brzmi: nie. Zwracamy na to uwagę w tekście o karze UODO w sprawie podwykonawców i umów powierzenia: organ nie przyjmuje argumentu, że umowa była wzorcem dostawcy.

Dla administratora to także moment na zadanie pytania, które powinno paść przed podpisaniem umowy: czy dostawca ma wdrożony system zarządzania bezpieczeństwem informacji, certyfikat ISO 27001 lub równoważny raport z audytu i czy dane starsze niż okres potrzebny do celów księgowych są usuwane. Z komunikatu spółki wynika, że dane kontrahentów dodanych przed październikiem 2024 roku były w bazie nadal, co wskazuje na to, że retencja po stronie dostawcy nie była ścisła. Wracamy tu do zasady ograniczenia przechowywania z art. 5 ust. 1 lit. e RODO, która wiąże także ciebie: dane, których nie potrzebujesz, nie powinny leżeć w chmurze, bo tam też wyciekają.

NIS-2 i łańcuch dostaw: dlaczego to nie jest wyłącznie sprawa RODO

3 października 2026 roku minął termin wpisu do wykazu podmiotów kluczowych i ważnych w krajowym systemie cyberbezpieczeństwa. Pisaliśmy o tym w tekście o wykazie KSC i osiemdziesięciu tysiącach podmiotów. Wpis do wykazu zamyka etap „czy mnie to dotyczy" i otwiera etap „co mam wykazać". Dyrektywa NIS-2 w art. 21 ust. 2 lit. d wymienia wśród środków zarządzania ryzykiem bezpieczeństwo łańcucha dostaw, w tym relacji z bezpośrednimi dostawcami i usługodawcami.

Dla spółki wodociągowej, ciepłowni czy zakładu gospodarki odpadami dostawca programu fakturowego jest takim ogniwem. Nie jest to system sterowania procesem, ale wyciek z niego daje napastnikowi mapę zależności finansowych, listę kontrahentów, numery rachunków i dane do wiarygodnego podszywania się. Organ nadzoru, który po incydencie zapyta o oceniane ryzyko dostawców, nie przyjmie odpowiedzi, że dostawca jest „renomowany". Oczekuje rejestru dostawców, kryteriów ich oceny, wymagań umownych i dowodów, że ktokolwiek je przeglądał. Opisywaliśmy podobny mechanizm w analizie ataku na łańcuch dostaw sieci handlowej.

Dla samorządów i spółek komunalnych dochodzi jeszcze jeden wymiar. Dane kontrahentów w takich systemach często obejmują mieszkańców: odbiorców usług komunalnych, najemców, uczestników programów. Wyciek z dostawcy oznacza więc incydent, który burmistrz wyjaśnia nie tylko organowi, ale też radnym i lokalnej prasie. Inspektor ochrony danych, który wcześniej nie miał kompletnego rejestru dostawców chmurowych, w takim momencie dowiaduje się, jak wiele rzeczy trzeba było zrobić w spokojny dzień.

Czego nie robić w tygodniu po wycieku

Po takich zdarzeniach powtarzają się cztery błędy. Pierwszy to czekanie na „kolejną informację od dostawcy", jakby ona miała zmienić rachunek obowiązków. Nie zmieni. Drugi to klikanie w wiadomości o incydencie bez weryfikacji nadawcy: po każdym głośnym wycieku pojawiają się fałszywe komunikaty „od dostawcy" z linkiem do zmiany hasła. Właściwe źródło to adres wpisany ręcznie w przeglądarce albo link z oficjalnej strony spółki, a nie z wiadomości. Trzeci to ogłaszanie w mediach społecznościowych, że „nas to nie dotyczy", zanim ktokolwiek sprawdzi, jakie dane trzymasz w systemie. Czwarty to przerzucanie całej odpowiedzialności na księgową, która obsługuje konto, bez wiedzy zarządu. Zgodnie z logiką NIS-2 i krajowych przepisów to kierownictwo odpowiada za nadzór nad ryzykiem i za zatwierdzenie środków, nie dział księgowości.

Dlaczego z Fib.Code

Zajmujemy się bezpieczeństwem informacji w sektorach, w których incydent z dostawcą kończy się nie tylko na skrzynce zgłoszeń UODO: w samorządach, spółkach komunalnych, wodociągach, ciepłowniach, placówkach medycznych i firmach sektora MŚP. Pełnimy funkcję inspektora ochrony danych i pełnomocnika do spraw bezpieczeństwa informacji, wdrażamy systemy zarządzania według ISO 27001 i przygotowujemy organizacje do wymogów krajowego systemu cyberbezpieczeństwa. Znamy decyzje Prezesa UODO i orzeczenia sądów administracyjnych na tyle dobrze, żeby przewidzieć, jakie pytanie organ zada po zgłoszeniu.

Pracujemy według trzech zasad. Po pierwsze, dokumentujemy decyzje, a nie tylko działania, bo organ ocenia sposób rozumowania administratora. Po drugie, zaczynamy od pytania „co się stanie, jeśli ten dostawca padnie", a nie od listy zabezpieczeń. Po trzecie, przekazujemy klientowi wiedzę, żeby przy następnym incydencie mógł działać bez nas, choć zwykle woli, żebyśmy byli blisko.

Efektem naszej pracy jest komplet dokumentów, które można położyć na stole przed organem: ocena ryzyka naruszenia, zgłoszenie do UODO, wzór zawiadomienia osób, wpis do rejestru naruszeń, rejestr dostawców chmurowych z oceną krytyczności oraz aneksy do umów powierzenia z konkretnymi terminami i prawem audytu. Całość da się zamknąć w kilku dniach roboczych, a nie w kwartale.

Co zrobić w ten poniedziałek

Jeśli czytasz ten tekst w tygodniu po wycieku, zaplanuj jedno spotkanie na godzinę, z udziałem prezesa lub burmistrza, osoby odpowiedzialnej za księgowość, informatyka i inspektora ochrony danych. Na spotkaniu odpowiedzcie na siedem pytań. Czy mamy konto w Fakturowni lub u innego dostawcy z podobnym wyciekiem? Jakie dane kontrahentów i osób fizycznych tam są? Kiedy dostaliśmy komunikat i od kogo? Czy zgłoszenie do UODO zostało złożone, a jeśli nie, kto je złoży do końca dnia? Czy klucze API i sesje zostały unieważnione? Czy kontrahenci zostali ostrzeżeni przed oszustwem na zmianę rachunku? Czy nasza umowa powierzenia pozwala nam zażądać raportu poincydentowego?

Do końca tygodnia zamknijcie rejestr dostawców chmurowych: lista usług, rodzaj danych, osoba odpowiedzialna po stronie firmy, data ostatniego przeglądu umowy. Jeśli takiej listy nie macie, to jest pierwszy wniosek z tego incydentu, a nie dopiero drugiego.

Zapraszamy do kontaktu: l.grabowski@fibcode.com | fibcode.com/pl/kontakt. Bezpośrednio powiązane materiały: incydent MyDr i zegar na 72 godziny, wyciek w Qbusoft i SQL injection oraz rejestr wycieków bezpiecznedane.gov.pl — trzy przypadki jednego schematu, w którym dostawca traci dane, a administrator odpowiada za ich skutki.