Gdy cyberatak trafia do bilansu. Co ująć, co oszacować, co ujawnić

Cyberatak rzadko kończy się w chwili przywrócenia serwerów i odzyskania dostępu do systemów. Jego konsekwencje mogą jeszcze przez wiele miesięcy wpływać na przychody, należności, środki pieniężne, wartość aktywów, rezerwy, płynność oraz relacje z klientami i regulatorami. Problem polega na tym, że sprawozdanie finansowe nie zawiera jednej pozycji nazwanej „skutki cyberincydentu”. Zarząd musi więc rozłożyć zdarzenie na konkretne skutki ekonomiczne i prawne, ustalić moment ich powstania oraz zdecydować, które z nich wymagają ujęcia, wyceny lub dodatkowego ujawnienia. 

Koszt naprawy systemów, sama wysokość ewentualnego okupu, czy fakt zgłoszenia incydentu organowi nadzoru nie przesądzają jeszcze o jego znaczeniu dla sprawozdania. Niekiedy największym problemem nie będzie bezpośrednia strata finansowa, lecz brak pewności czy dane księgowe są kompletne, transakcje ujęto we właściwym okresie, a oczekiwane odszkodowanie rzeczywiście zostanie wypłacone. Cyberincydent staje się wówczas nie tylko kryzysem technologicznym, ale także testem jakości rachunkowości, kontroli wewnętrznej i decyzji podejmowanych przez zarząd.

Cyberincydent nie jest wyłącznie zdarzeniem technicznym

Atak ransomware, przejęcie konta administratora, zmiana danych dostawcy, utrata kopii zapasowych czy długotrwała niedostępność systemu ERP zwykle pojawiają się najpierw w raportach zespołu bezpieczeństwa. Z punktu widzenia rachunkowości ich techniczna nazwa ma jednak znaczenie drugorzędne. Istotne jest to, jakie prawa, obowiązki, aktywa, przepływy pieniężne i procesy gospodarcze zostały dotknięte zdarzeniem. 

Dlatego właściwszym pojęciem jest często „cyberincydent”, a nie wyłącznie „cyberatak”. Ustawa o krajowym systemie cyberbezpieczeństwa definiuje incydent szeroko – jako zdarzenie, które ma lub może mieć niekorzystny wpływ na bezpieczeństwo systemów informacyjnych. Incydent poważny może natomiast prowadzić między innymi do poważnego obniżenia jakości lub przerwania ciągłości usługi, strat finansowych albo szkody po stronie innych podmiotów. Kwalifikacja prawna nie jest więc ograniczona do celowego działania sprawcy ani do przypadku, w którym doszło do kradzieży danych.

Z perspektywy ustawy o rachunkowości punktem wyjścia pozostaje obowiązek rzetelnego i jasnego przedstawienia sytuacji majątkowej, finansowej oraz wyniku finansowego jednostki. Zdarzenia należy ujmować zgodnie z ich treścią ekonomiczną, a księgi powinny być prowadzone na podstawie dowodów księgowych. Odpowiedzialność za wykonanie obowiązków rachunkowych, w tym za nadzór nad nimi, ponosi kierownik jednostki również wówczas, gdy prowadzenie ksiąg, utrzymanie systemu lub inne czynności powierzono podmiotowi zewnętrznemu. 

Zarząd nie może więc poprzestać na informacji, że system został odtworzony. Powinien ustalić, czy dane finansowe są kompletne i nie zostały zmienione; wszystkie operacje zostały ujęte w prawidłowym okresie; istnieją wystarczające dowody potwierdzające salda i transakcje; incydent spowodował utratę wartości aktywów; powstały zobowiązania wobec klientów, pracowników, kontrahentów albo organów; konieczne są dodatkowe ujawnienia; zdarzenie wpływa na płynność lub zdolność do kontynuowania działalności.

Jeden incydent, kilka niezależnych ocen

Cyberincydent może podlegać jednocześnie ocenie rachunkowej, regulacyjnej, dotyczącej ochrony danych osobowych oraz – u emitenta – obowiązkom informacyjnym na rynku kapitałowym. Są to jednak odrębne testy oparte na innych kryteriach.

Zakwalifikowanie zdarzenia jako poważnego incydentu w rozumieniu przepisów o cyberbezpieczeństwie nie oznacza automatycznie, że należy utworzyć rezerwę albo dokonać korekty określonej pozycji sprawozdania. Z drugiej strony zdarzenie, które nie osiąga progu raportowania regulacyjnego, może mieć istotny wpływ na sprawozdanie finansowe – na przykład dlatego, że podważyło kompletność danych dotyczących przychodów lub płatności. Nie każdy cyberincydent jest też naruszeniem ochrony danych osobowych. Istotność ocenia się nie tylko według kwoty, lecz także charakteru zdarzenia. Nawet niewielki incydent może być jakościowo istotny, jeżeli dotyczył systemu finansowo-księgowego, umożliwił obejście kontroli albo utrudnił zamknięcie ksiąg.

Najpierw fakty i chronologia

Prawidłowa analiza powinna rozpocząć się od ustalenia faktów. Kluczowe jest sporządzenie jednej, uzgodnionej chronologii, z której korzystają finanse, dział prawny, bezpieczeństwo, zarząd oraz – w odpowiednim zakresie – biegły rewident. Powinna ona obejmować: prawdopodobny początek nieautoryzowanego dostępu, datę wykrycia, czas niedostępności systemów, datę ostatniej wiarygodnej kopii, zakres odtwarzanych danych, okres procedur ręcznych, wykonane zgłoszenia oraz stan roszczeń i postępowań.

Data wykrycia incydentu nie musi być datą powstania jego skutków ekonomicznych. Jeżeli spółka 10 stycznia wykryła, że osoba nieuprawniona od połowy grudnia zmieniała dane kontrahentów, późniejsze wykrycie dostarcza informacji o stanie istniejącym już przed dniem bilansowym. Inaczej będzie, gdy zarówno włamanie, jak i wszystkie jego skutki wystąpiły dopiero po zakończeniu roku.

Co więcej, różne konsekwencje tego samego incydentu mogą powstawać w różnych momentach. Nieautoryzowana zmiana danych mogła nastąpić przed dniem bilansowym, roszczenie klienta zostać zgłoszone później, a decyzja o budowie nowego systemu bezpieczeństwa może być dopiero przyszłym działaniem zarządu. Każdy z tych elementów wymaga osobnej kwalifikacji.

Mapa potencjalnych skutków finansowych

Poniższe zestawienie nie przesądza o właściwym ujęciu, a pokazuje obszary, które zwykle należy przeanalizować:

Zdarzenia po dniu bilansowym

Cyberincydenty są szczególnie wymagające, gdy zostają wykryte pomiędzy dniem bilansowym a zatwierdzeniem sprawozdania finansowego. Kluczowe znaczenie ma wtedy nie sama data wykrycia, lecz odpowiedź na pytanie, czy nowe informacje dotyczą warunków istniejących już na dzień bilansowy.

Przykładowo, jeżeli w styczniu wykryto, że nieautoryzowany dostęp rozpoczął się w grudniu i przed końcem roku doprowadził do zmiany danych dostawców, informacja uzyskana po dniu bilansowym może potwierdzać stan istniejący wcześniej. Konieczna może być korekta sald, utworzenie rezerwy, ujęcie straty albo rozszerzenie ujawnień.

Jeżeli natomiast do ataku doszło dopiero w lutym i nie ma dowodów na wcześniejsze naruszenie, zdarzenie co do zasady nie koryguje kwot odnoszących się do poprzedniego roku. Jeżeli jest jednak istotne, jego charakter i możliwe skutki finansowe powinny zostać odpowiednio ujawnione. Wyjątkiem jest między innymi sytuacja, w której późniejszy incydent powoduje, że założenie kontynuacji działalności nie jest już uzasadnione.

Takie rozróżnienie wynika zarówno z art. 54 ustawy o rachunkowości, jak i z Międzynarodowego Standardu Rachunkowości (MSR) 10. Ustawa wymaga zmiany sprawozdania przed jego zatwierdzeniem, gdy uzyskane informacje mają na nie istotny wpływ lub podważają kontynuację działalności. Jeżeli zdarzenia po dniu bilansowym nie zmieniają stanu istniejącego na ten dzień, odpowiednie informacje zamieszcza się w informacji dodatkowej. MSR 10 analogicznie odróżnia zdarzenia korygujące, dostarczające dowodów o warunkach istniejących na koniec okresu, od zdarzeń niekorygujących, wskazujących na warunki powstałe później.

Kontynuacja działalności i ujawnienia

Znaczenie incydentu nie zależy wyłącznie od jego bezpośredniego kosztu. Brak fakturowania, utrata kluczowych klientów, wstrzymanie działalności regulowanej, naruszenie warunków finansowania lub brak możliwości bezpiecznego wznowienia operacji mogą zagrozić płynności. Zarząd powinien zaktualizować prognozy przepływów i ocenić wykonalność działań naprawczych.

Nie każdy incydent wymaga odrębnej noty. Sprawozdanie musi jednak zawierać istotne informacje potrzebne do zrozumienia jego skutków. Ujawnienie może obejmować charakter zdarzenia, dotknięte obszary, ujęte koszty i odpisy, rezerwy, niepewności, stan roszczeń ubezpieczeniowych oraz wpływ na działalność po dniu bilansowym. Nie należy przy tym ujawniać technicznych szczegółów zwiększających ryzyko kolejnego ataku.

KSC, NIS2 i DORA: raport regulacyjny nie zastępuje analizy rachunkowej

Nowelizacja ustawy o Krajowym Systemie Cyberbezpieczeństwa wdrażająca NIS2 weszła w życie 3 kwietnia 2026 r. Obecne przepisy przypisują kierownikowi podmiotu kluczowego lub ważnego odpowiedzialność za wykonywanie obowiązków z zakresu cyberbezpieczeństwa także wtedy, gdy zostały one powierzone innej osobie. Kierownik podejmuje decyzje dotyczące systemu zarządzania bezpieczeństwem informacji, planuje środki finansowe i nadzoruje wykonanie zadań. Ustawa przewiduje dla poważnych incydentów sekwencję obejmującą wczesne ostrzeżenie nie później niż w ciągu 24 godzin od wykrycia, zgłoszenie nie później niż w ciągu 72 godzin oraz sprawozdanie końcowe zasadniczo w ciągu miesiąca od zgłoszenia 72-godzinnego. Przy stosowaniu tych terminów należy jednak uwzględnić zakres podmiotowy ustawy i przepisy przejściowe. 

Nowe wymogi wzmacniają także potrzebę ujęcia reagowania na incydenty jako procesu zarządczego, a nie wyłącznie technicznego. Procedury powinny zapewniać nie tylko wykrycie, ograniczenie i usunięcie skutków incydentu przez zespoły cyberbezpieczeństwa i IT, lecz również kompleksową ocenę każdego zdarzenia z perspektywy działalności biznesowej i ryzyka operacyjnego. Działania zespołów cyberbezpieczeństwa i IT są w takim modelu pierwszym krokiem; dalsza analiza powinna objąć między innymi wpływ na ciągłość procesów, klientów i kontrahentów, zobowiązania prawne i regulacyjne, płynność oraz – w odpowiednich przypadkach – sprawozdawczość finansową.

Takie podejście może być zarazem traktowane jako wzorzec dobrych praktyk w obszarze IT & security governance. Również organizacje, które nie są bezpośrednio objęte KSC/NIS2, mogą – proporcjonalnie do skali działalności, jej złożoności i profilu ryzyka – przyjmować model, w którym odpowiedzialność za ocenę i zarządzanie incydentem jest współdzielona przez funkcje technologiczne, biznesowe, zarządzania ryzykiem, prawne i finansowe.

Aktualnie (wrzesień 2026 r.) trwa okres samorejestracji części podmiotów kluczowych i ważnych, który kończy się 3 października 2026 r. Dla podmiotów spełniających kryteria w dniu wejścia w życie nowelizacji 3 kwietnia 2027 r. to koniec okresu na rozpoczęcie korzystania z systemu S46 oraz wdrożenie obowiązków objętych okresem dostosowawczym. Status konkretnej jednostki i moment rozpoczęcia poszczególnych obowiązków należy zatem ustalać indywidualnie. 

Od 17 stycznia 2025 r. stosowane jest rozporządzenie w sprawie operacyjnej odporności cyfrowej DORA. Obejmuje ono między innymi zarządzanie ryzykiem ICT, raportowanie poważnych incydentów, testowanie odporności cyfrowej oraz zarządzanie ryzykiem dostawców zewnętrznych. Dla podmiotów finansowych objętych jego zakresem DORA stanowi sektorowy akt prawa Unii w relacji do NIS2, dlatego obowiązków obu reżimów nie należy mechanicznie dublować. 

Raport przekazany do Zespołu Reagowania na Incydenty Bezpieczeństwa Komputerowego CSIRT, organowi nadzoru finansowego lub organowi ochrony danych ma jednak inny cel niż sprawozdanie finansowe. Nie zastępuje wyceny aktywów i zobowiązań, analizy zdarzeń po dniu bilansowym ani oceny istotności.

Dokument, który powinien powstać po incydencie

Dobrą praktyką jest przygotowanie wspólnego memorandum dotyczącego wpływu cyberincydentu na sprawozdawczość finansową. Nie powinien to być wyłącznie raport techniczny ani sama opinia prawna.

Dokument powinien łączyć chronologię incydentu z opisem dotkniętych systemów, danych i procesów, wskazywać okres potencjalnego oddziaływania, sposób odtworzenia informacji, wykonane uzgodnienia, zastosowane procedury ręczne oraz stwierdzone luki w kontroli. Powinien również obejmować zestawienie poniesionych i przewidywanych kosztów, analizę utraty wartości, rezerw i zobowiązań warunkowych, status roszczeń wobec ubezpieczyciela i dostawców, ocenę zdarzeń po dniu bilansowym, płynności i kontynuacji działalności, a także proponowane ujęcie i ujawnienia.

Wnioski powinny być oparte na konkretnych dowodach: raportach z analizy technicznej, logach, wyciągach bankowych, uzgodnieniach danych, umowach, korespondencji z regulatorami, stanowiskach ubezpieczyciela i opiniach prawnych. Dla każdego istotnego osądu warto wskazać osobę odpowiedzialną, datę dokonania oceny oraz okoliczności, które mogą wymagać jej aktualizacji.

Memorandum powinno być dokumentem dynamicznym. Ocena dokonana kilka dni po wykryciu zdarzenia może ulec zmianie po odzyskaniu logów, zgłoszeniu roszczeń przez klientów albo otrzymaniu stanowiska regulatora. Zarząd powinien zapewnić, że najnowsze informacje są uwzględniane aż do dnia sporządzenia, a w odpowiednich przypadkach również do dnia zatwierdzenia sprawozdania finansowego.

Cyberatak kończy się później niż wskazuje raport IT

Dla zespołu technicznego incydent może zostać zamknięty w chwili przywrócenia usług, zmiany haseł i usunięcia podatności. Dla sprawozdawczości finansowej kończy się dopiero wtedy, gdy jednostka potrafi wyjaśnić, co wydarzyło się z jej aktywami, zobowiązaniami, przychodami, kosztami i przepływami pieniężnymi oraz wykazać, że dane stanowiące podstawę sprawozdania są kompletne i wiarygodne.

O sposobie ujęcia nie przesądza wysokość okupu, liczba godzin przestoju ani sam fakt zgłoszenia zdarzenia regulatorowi. Rozstrzygające są ekonomiczna treść skutków, moment ich powstania, dostępne dowody i zasady rachunkowości stosowane przez jednostkę.

Dlatego cyberincydent nie jest wyłącznie sprawą dyrektora IT lub zespołu bezpieczeństwa. Jest zdarzeniem wymagającym współpracy zarządu, finansów, prawników, specjalistów technicznych i biegłego rewidenta. Dopiero połączenie tych perspektyw pozwala ocenić nie tylko, czy przedsiębiorstwo odzyskało systemy, lecz także czy jego sprawozdanie finansowe nadal przedstawia rzetelny obraz rzeczywistości.

Artykuł ma charakter ogólny. Ujęcie konkretnego cyberincydentu zależy od jego okoliczności, podstawy prawnej odpowiedzialności oraz zasad rachunkowości stosowanych przez daną jednostkę.