Wyciek danych z Fakturowni: kto ponosi odpowiedzialność i co powinny zrobić firmy
Pod koniec września 2026 roku nieznana osoba uzyskała dostęp do systemów polskiego serwisu Fakturownia i skopiowała znaczną część jego bazy danych. Incydent dotknął wszystkich kont, jednak zakres informacji dostępnych dla sprawcy różni się w zależności od okresu ich dodania oraz wykorzystywanych funkcji.
Dla firm główna trudność polega na tym, że włamano się do systemów dostawcy usługi, ale obowiązki wynikające z GDPR mogą powstać również po stronie jego klientów. Jeśli firma lub indywidualny przedsiębiorca przechowywali w Fakturowni dane swoich zleceniodawców, nabywców, wykonawców lub pracowników kontrahentów, to właśnie użytkownik serwisu pozostaje administratorem tych danych.
Jednocześnie najbardziej prawdopodobne straty wiążą się nie tylko z karami lub roszczeniami o odszkodowanie. Informacje o fakturach, płatnościach, kontrahentach i danych bankowych pozwalają tworzyć wiarygodne wiadomości z prośbą o przelanie pieniędzy na nowy rachunek.
Wyjaśniamy, jakie dane zostały objęte incydentem, czy należy powiadomić polski organ nadzorczy UODO oraz jak firmy powinny postępować po wycieku.
Co wydarzyło się w Fakturowni
Według oficjalnych informacji Fakturowni nieuprawniony dostęp trwał od 27 września około godziny 03:20 do 28 września 2026 roku około godziny 17:45.
Sprawca uzyskał dostęp do systemu i skopiował dane na własne serwery. Incydent zakwalifikowano jako naruszenie poufności: informacje nie zostały jedynie przejrzane, lecz wyeksportowane z infrastruktury serwisu.
Po wykryciu ataku Fakturownia zablokowała dostęp, wymieniła klucze systemowe i hasła, przeniosła ruch na nowe serwery oraz dezaktywowała skompromitowane klucze. 29 września serwis zgłosił incydent do UODO, CERT Polska i policji, a 1 października rozpoczął wysyłanie indywidualnych powiadomień do właścicieli i użytkowników kont.
Jednak zgłoszenie dokonane przez samą Fakturownię nie zawsze zwalnia jej klientów z obowiązku przeprowadzenia własnej oceny incydentu. Na potrzeby stosowania GDPR konieczne jest ustalenie, czyje dokładnie dane były przechowywane na konkretnym koncie i jaką rolę pełniła każda ze stron.
Jakie dane zostały skopiowane
Według informacji serwisu w wyeksportowanej bazie mogły znajdować się:
- nazwy firm, numery NIP, adresy i dane rachunków bankowych
- imiona, nazwiska, adresy e-mail i numery telefonów użytkowników
- hashe haseł, identyfikatory sesji, tokeny API i klucze integracyjne
- informacje o kontrahentach, w tym imiona i nazwiska, adresy, numery NIP, telefony, adresy e-mail i numery rachunków
- kwoty faktur, informacje o płatnościach i zadłużeniu
- pełna treść części starszych faktur
- nazwy towarów i usług z poszczególnych dokumentów
- informacje o płatnościach, towarach, cennikach i operacjach magazynowych
- dane z przeprowadzonych importów i eksportów
Dla różnych kategorii ustalono różne granice czasowe. Na przykład pełna treść została skopiowana wyłącznie w przypadku faktur wystawionych przed 22 marca 2021 roku, a pozycje faktur — w przypadku dokumentów sprzed 6 czerwca 2019 roku. Jednocześnie kwoty, niektóre pola opisowe i dane dodatkowych stron faktury mogły znaleźć się w wyeksportowanych danych również za późniejsze okresy.
Zgodnie z oficjalnym komunikatem certyfikaty KSeF, dane logowania do bankowości internetowej i dane kart płatniczych nie zostały objęte incydentem. Fakturownia nie przechowuje loginów bankowych ani danych kart. Konkretny zakres informacji należy sprawdzić w panelu incydentu na koncie. Ogólny komunikat serwisu nie wystarcza do indywidualnej oceny ryzyka.
Dlaczego za jeden incydent odpowiadają różne strony
Fakturownia pełni różne role w zależności od kategorii informacji. W odniesieniu do danych właścicieli kont i użytkowników serwisu Fakturownia samodzielnie określa cele i sposoby przetwarzania. W przypadku tych danych występuje jako administrator.
Inna sytuacja dotyczy informacji, które klient wprowadził do systemu o własnych zleceniodawcach, nabywcach, wykonawcach lub innych osobach. Tutaj administratorem pozostaje klient, a Fakturownia występuje jako podmiot przetwarzający, który przechowuje informacje na jego zlecenie.
Dlatego firma korzystająca z serwisu do wystawiania faktur powinna samodzielnie ustalić:
- czy informacje objęte incydentem stanowią dane osobowe
- jakich osób fizycznych dotknął incydent
- jakie konsekwencje mogą dla nich wystąpić
- czy należy powiadomić UODO
- czy konieczne jest poinformowanie o wycieku samych osób
Fakturownia może przekazać zakres danych, chronologię i techniczny opis incydentu. Serwis nie zna jednak kontekstu relacji między klientem a osobami wskazanymi na fakturach, dlatego nie może przeprowadzić ostatecznej oceny ryzyka zamiast użytkownika.
Jakie informacje są uznawane za dane osobowe
Dane osoby prawnej same w sobie zazwyczaj nie stanowią danych osobowych. Nazwa sp. z o.o., jej NIP, adres siedziby lub ogólny adres e-mail, taki jak biuro@company.pl, co do zasady nie pozwalają zidentyfikować konkretnej osoby.
Jednak na fakturach i w kartotekach kontrahentów mogą znajdować się imiona i nazwiska pracowników, indywidualne adresy e-mail, numery telefonów i osobiste rachunki bankowe. Takie informacje dotyczą osób fizycznych i podlegają GDPR.
Informacje o indywidualnym przedsiębiorcy prowadzącym jednoosobową działalność gospodarczą (JDG) również stanowią dane osobowe, nawet jeśli część z nich została opublikowana w CEIDG. Publiczna dostępność informacji nie zmienia ich charakteru prawnego.
Jednocześnie UODO wskazuje, że wyciek wyłącznie publicznie dostępnych informacji z CEIDG, na przykład imienia i nazwiska, nazwy firmy, NIP i oficjalnego adresu, zazwyczaj wiąże się z niewielkim ryzykiem. Ocena może się zmienić, jeśli wraz z nimi ujawniono numery rachunków, historię płatności, informacje o zakupach, dane kontaktowe lub inne informacje przydatne do oszustw i socjotechniki.
Kiedy należy powiadomić UODO
Artykuł 33 GDPR wymaga powiadomienia organu nadzorczego, jeśli naruszenie może powodować ryzyko naruszenia praw lub wolności osób fizycznych. UODO należy powiadomić nie ze względu na samą skalę ataku, lecz na podstawie oceny konkretnych danych. W przypadku dwóch użytkowników Fakturowni konsekwencje tego samego incydentu mogą być różne.
Na przykład firma, która wystawiała faktury wyłącznie osobom prawnym i przechowywała publicznie dostępne dane firmowe, może dojść do wniosku, że ryzyko dla osób fizycznych jest mało prawdopodobne.
Innej oceny będzie wymagać klinika, psycholog, sklep internetowy, serwis B2C lub specjalista pracujący z osobami fizycznymi. Szczególne znaczenie mają numery PESEL, osobiste rachunki bankowe, informacje o rodzaju zakupionych usług, dane dotyczące zdrowia i inne informacje umożliwiające popełnienie oszustwa lub poznanie poufnych informacji o danej osobie.
Nawet jeśli powiadomienie UODO nie jest wymagane, firma powinna udokumentować incydent w wewnętrznym rejestrze naruszeń. W dokumentacji należy wskazać, co się wydarzyło, jakie dane zostały objęte incydentem, jakie ryzyka rozpatrywano i dlaczego podjęto decyzję o niewysyłaniu zgłoszenia.
Od jakiego momentu liczy się 72 godziny
Zgłoszenia dokonuje się bez zbędnej zwłoki i, w miarę możliwości, nie później niż w ciągu 72 godzin od momentu, w którym administrator uzyskał wystarczającą pewność co do wystąpienia naruszenia.
Gdy incydent występuje u podmiotu przetwarzającego, takim momentem zazwyczaj jest otrzymanie od niego informacji. Dla wielu właścicieli kont Fakturowni jest to wiadomość wysłana 1 października 2026 roku. Moment ten może jednak przypadać wcześniej, jeśli firma otrzymała już wystarczająco konkretne informacje z oficjalnego komunikatu Fakturowni z 29 września lub z innego wiarygodnego źródła.
Dlatego w dokumentacji należy odnotować nie tylko datę otrzymania wiadomości, ale również moment, w którym firma faktycznie uzyskała wystarczające informacje o możliwym objęciu incydentem danych z jej konta. Jeśli upłynęły już 72 godziny, nie znosi to obowiązku dokonania zgłoszenia. GDPR pozwala zrobić to później, podając przyczyny opóźnienia. W przypadku braku wystarczających informacji można przesłać wstępne zgłoszenie, a następnie uzupełniać je w miarę uzyskiwania wyników analizy.
Spóźnione zgłoszenie wraz z uzasadnieniem jest zazwyczaj lepszym rozwiązaniem niż całkowita bezczynność, jeśli ocena wykazała istnienie ryzyka.
Czy należy informować kontrahentów
Zgłoszenie do UODO i powiadomienie osób, których dotyczy naruszenie, to dwa odrębne obowiązki. Poinformowanie osoby na podstawie art. 34 GDPR jest konieczne, gdy naruszenie może powodować wysokie ryzyko naruszenia jej praw lub wolności. W przypadku zwykłego ryzyka wystarczy powiadomienie organu nadzorczego. Przy niskim ryzyku żadne z zewnętrznych powiadomień może nie być wymagane, jednak prowadzenie dokumentacji wewnętrznej pozostaje obowiązkowe.
Wysokie ryzyko może wystąpić, jeśli wyciek obejmuje numery PESEL, informacje o zdrowiu, osobiste dane finansowe lub szczegółowe informacje pozwalające wiarygodnie podszyć się pod firmę, bank lub kontrahenta.
Powiadomienie powinno być napisane zrozumiałym językiem i wyjaśniać:
- co się wydarzyło
- jakie kategorie danych zostały objęte incydentem
- jakie konsekwencje mogą wystąpić
- jakie działania firma już podjęła
- jakie działania zaleca się podjąć danej osobie
- gdzie można uzyskać dodatkowe informacje
GDPR nie wymaga w każdym przypadku wysyłania papierowego pisma do każdego kontrahenta. Jeśli indywidualne powiadomienie wymagałoby niewspółmiernie dużego wysiłku, można zastąpić je komunikatem publicznym lub porównywalnym środkiem, który równie skutecznie poinformuje osoby dotknięte incydentem.
Jednak opublikowanie ogłoszenia na stronie internetowej nie stanowi automatycznego zamiennika indywidualnej wysyłki powiadomień. Firma musi uzasadnić, dlaczego bezpośredni kontakt z osobami jest niemożliwy lub niewspółmiernie trudny oraz dlaczego wybrany sposób pozwoli im rzeczywiście dowiedzieć się o incydencie.
Główne ryzyko praktyczne — podmiana danych rachunku bankowego
W ręce sprawcy mogły trafić rzeczywiste kwoty, daty płatności, nazwy towarów i usług, informacje o zadłużeniu oraz numery rachunków bankowych.
Dane te pozwalają stworzyć wiadomość, która wygląda jak kontynuacja prawdziwej korespondencji. Odbiorca może zobaczyć prawidłową nazwę firmy, numer starej faktury, znaną kwotę i znajomy opis projektu. Różnić się będzie jedynie nowy rachunek bankowy. Aby zastosować taki schemat, sprawca nie musi uzyskiwać dostępu do firmowej poczty. Wystarczy wysłać do księgowości wiarygodną wiadomość w imieniu dostawcy z prośbą o korzystanie ze zaktualizowanych danych bankowych.
Po incydencie firma powinna wprowadzić odrębną zasadę: każda zmiana rachunku bankowego musi zostać potwierdzona niezależnym kanałem. Należy dzwonić pod numer znany przed otrzymaniem wiadomości, a nie korzystać z danych kontaktowych zawartych w wiadomości z nowymi danymi bankowymi.
Rachunek polskiego podatnika VAT należy dodatkowo sprawdzić na białej liście podatników VAT. Taka weryfikacja nie zastępuje jednak potwierdzenia bezpośrednio u kontrahenta, szczególnie w przypadku współpracy z zagranicznymi firmami, osobami fizycznymi i dostawcami niezarejestrowanymi jako podatnicy VAT.
W przypadku przelewów na znaczne kwoty warto wprowadzić podwójną akceptację: jeden pracownik sprawdza dokument i kontrahenta, a drugi niezależnie zatwierdza płatność.
Co powinni zrobić użytkownicy Fakturowni
Firmy i przedsiębiorcy korzystający z serwisu powinni kolejno wykonać następujące działania:
- Zachować wiadomość od Fakturowni i odnotować datę oraz godzinę jej otrzymania.
- Otworzyć panel incydentu i ustalić kategorie, okresy oraz liczbę rekordów objętych incydentem.
- Zmienić hasło, sprawdzić użytkowników konta i włączyć uwierzytelnianie dwuskładnikowe.
- Zaktualizować klucze API i sprawdzić wszystkie podłączone integracje.
- Upewnić się, że w szablonach faktur zachowano prawidłowe dane rachunków bankowych.
- Ustalić, czy konto zawierało dane osób fizycznych, JDG, pracowników kontrahentów lub konsumentów.
- Osobno wyszukać numery PESEL, osobiste rachunki bankowe, informacje o zdrowiu i inne poufne informacje.
- Przeprowadzić i udokumentować ocenę ryzyka.
- Powiadomić UODO, jeśli naruszenie może powodować ryzyko dla osób fizycznych.
- W przypadku wysokiego ryzyka poinformować osoby dotknięte incydentem.
- Ostrzec księgowość i kontrahentów przed możliwą podmianą danych do płatności.
- Zweryfikować okresy przechowywania starych danych i usunąć informacje, które nie są już potrzebne i nie podlegają obowiązkowi przechowywania.
Nie można automatycznie usuwać starych faktur wyłącznie na podstawie daty dokumentu. Należy uwzględnić terminy podatkowe, niezakończone kontrole, spory, terminy przedawnienia roszczeń i inne zgodne z prawem podstawy przechowywania. Jednak przechowywanie informacji bez określonego celu i ustalonego okresu również narusza zasadę ograniczenia przechowywania.
Kto odpowiada za wyrządzoną szkodę
Artykuł 82 GDPR pozwala osobie fizycznej dochodzić od administratora lub podmiotu przetwarzającego odszkodowania za szkodę majątkową lub niemajątkową.
Administrator odpowiada za naruszenia związane z przetwarzaniem danych pozostających pod jego kontrolą. Podmiot przetwarzający odpowiada, jeśli naruszył obowiązki, które GDPR nakłada bezpośrednio na podmioty przetwarzające, albo wykroczył poza zgodne z prawem instrukcje administratora.
Jeśli kilka stron uczestniczyło w tym samym przetwarzaniu i ponosi odpowiedzialność za wyrządzoną szkodę, poszkodowany może żądać pełnego odszkodowania od każdej z nich. Po wypłacie odszkodowania strony mogą rozliczyć koszty między sobą w ramach roszczeń regresowych, z uwzględnieniem zakresu swojej odpowiedzialności.
Nie oznacza to, że klient Fakturowni automatycznie odpowiada za wszystkie konsekwencje włamania ani że cała odpowiedzialność bezwarunkowo spoczywa na serwisie. Należy ustalić, jakich naruszeń dopuściła się każda ze stron, czy środki bezpieczeństwa były wystarczające i w jaki sposób konkretne naruszenie wiąże się ze szkodą.
Trybunał Sprawiedliwości UE w sprawie C-340/21 wyjaśnił, że sam fakt skutecznego cyberataku nie dowodzi jeszcze niewystarczalności środków ochrony. Administrator musi jednak umieć wykazać, że stosował odpowiednie środki techniczne i organizacyjne.
Trybunał uznał również, że uzasadniona obawa przed możliwym bezprawnym wykorzystaniem danych może stanowić szkodę niemajątkową. Jednocześnie poszkodowany musi wykazać istnienie rzeczywistej szkody i jej związek z naruszeniem. Sam fakt nieprzestrzegania GDPR nie wystarcza do przyznania odszkodowania.
Ograniczenie odpowiedzialności w regulaminie serwisu
Regulamin Fakturowni ogranicza odpowiedzialność serwisu wobec klientów niebędących konsumentami do wysokości bieżącego abonamentu i rzeczywistej szkody. Ponadto odpowiednie postanowienie wiąże odpowiedzialność kontraktową z zawinionym i umyślnym działaniem dostawcy.
Jednak istnienie takiego postanowienia nie oznacza, że wszelkie roszczenia są z góry wykluczone. Możliwość jego zastosowania zależy od statusu klienta, okoliczności naruszenia, bezwzględnie obowiązujących przepisów prawa polskiego oraz podstawy konkretnego roszczenia.
Ograniczenie umowne nie pozbawia również poszkodowanych osób fizycznych praw wynikających z art. 82 GDPR ani nie ogranicza uprawnień UODO. Dlatego firmy nie powinny zakładać, że wszystkie koszty dochodzenia, powiadomień, pomocy prawnej lub oszukańczego przelewu uda się automatycznie odzyskać od dostawcy serwisu.
Czego ten incydent uczy firmy SaaS
Historia Fakturowni jest istotna nie tylko dla użytkowników serwisów księgowych. Pokazuje ryzyka związane z każdym produktem SaaS, w którym klienci przechowują dane swoich zleceniodawców.
Po wykryciu incydentu podmiot przetwarzający powinien bez zbędnej zwłoki poinformować o nim administratorów i przekazać informacje niezbędne do oceny ryzyka. Bez tego klienci nie będą mogli wykonać własnych obowiązków w ciągu 72 godzin.
W DPA warto określić kanał kontaktu awaryjnego, osoby odpowiedzialne, zakres pierwszego powiadomienia i procedurę przekazywania kolejnych aktualizacji. Warto ustalić konkretny wewnętrzny termin zgłoszenia, który będzie krótszy niż regulacyjne 72 godziny.
Dostawca SaaS powinien również wcześniej przygotować plan reagowania: izolację infrastruktury, wymianę kluczy, gromadzenie logów, współpracę z zewnętrznymi specjalistami, informowanie klientów i zabezpieczanie dowodów.
Osobną kwestią są okresy przechowywania. Istnienie obowiązku podatkowego przechowywania części dokumentów nie oznacza, że wszystkie informacje muszą bezterminowo znajdować się w głównej roboczej bazie danych. Serwis może przewidywać usuwanie niepotrzebnych danych, archiwizację, odrębne szyfrowanie starszych okresów i zrozumiałe ustawienia okresów przechowywania.
Co należy sprawdzić w umowach z dostawcami SaaS
Incydent pokazuje, że standardowa wzmianka o GDPR w regulaminie użytkownika nie wystarcza. Firma powinna sprawdzić:
- czy zawarto DPA
- jakie kategorie danych są przekazywane serwisowi
- gdzie fizycznie przechowywane są dane
- czy angażowani są dalsi podwykonawcy przetwarzania
- w jakim terminie dostawca informuje o incydencie
- jakie informacje ma obowiązek przekazać
- czy można wyeksportować i usunąć dane
- jak zorganizowane jest tworzenie kopii zapasowych
- czy przewidziano audyt i potwierdzenie stosowania środków bezpieczeństwa
- jak rozdzielona jest odpowiedzialność kontraktowa
Wolja Digital pomaga firmom ocenić konieczność powiadomienia UODO, przygotować dokumentację incydentu oraz komunikaty dla osób dotkniętych naruszeniem. Dla projektów SaaS opracowujemy DPA, politykę reagowania na wycieki danych i mechanizmy umowne, które pozwalają działać według gotowego planu, zamiast tworzyć go dopiero po wykryciu ataku.
Wyciek u dostawcy nie zawsze oznacza, że jego klient naruszył GDPR. Jednak po otrzymaniu powiadomienia nie można już pozostawać bezczynnym: należy ustalić zakres danych, ocenić ryzyko i udokumentować podjętą decyzję.