Zarządzanie incydentami
Incydent bezpieczeństwa to każde zdarzenie mogące zagrozić poufności, integralności lub dostępności systemów informacyjnych. W rzeczywistości biznesowej incydenty są niechybne - pytanie nie brzmi „czy nas to spotka", tylko „kiedy" i „czy będziemy przygotowani". Organizacja bez procedury zarządzania incydentami wchodzi w kryzys z chaosem, paniką i nieskoordynowanymi działaniami, które potrafią znacznie pogorszyć sytuację.
Artykuł 33 RODO wymaga powiadomienia PUODO o naruszeniu danych osobowych w ciągu siedemdziesięciu dwóch godzin od odkrycia naruszenia, a artykuł 34 wymaga zawiadomienia osób, których dane dotyczą, jeżeli ryzyko jest wysokie. NIS2 nakłada jeszcze bardziej restrykcyjne wymogi raportowania dla operatorów usług krytycznych. ISO 27001 w załącznikach A.5.24 do A.5.28 określa procedury dla detekcji, analizy i reagowania na incydenty bezpieczeństwa.
Skala zjawiska w Polsce
Dla kontekstu warto zestawić procedury z danymi. W 2025 r. CERT Polska przyjął 658 320 zgłoszeń i zarejestrował 260 783 incydenty - wzrost o 152 procent rok do roku. Odnotowano 179 przypadków ransomware wobec 163 rok wcześniej. CSIRT NASK obsłużył 27 incydentów poważnych w rozumieniu ustawy o KSC.
Wśród zdarzeń opisanych w raporcie za 2025 r. jest atak na stację uzdatniania wody, w którym zmieniono nastawy pomp - skutkiem była około sześciogodzinna przerwa w dostawie wody dla blisko 2 500 mieszkańców. To dobry przykład na to, że incydent w systemie sterowania nie kończy się na danych.
Po stronie ochrony danych obraz jest podobny: w 2025 r. do UODO wpłynęło 22 435 zgłoszeń naruszeń, a organ nałożył 32 kary na łączną kwotę około 64,4 mln zł.
Dwa wnioski praktyczne. Po pierwsze, prawdopodobieństwo, że organizacja obsłuży incydent w ciągu roku, jest wysokie - procedura nie jest inwestycją w mało prawdopodobny scenariusz. Po drugie, dominują zdarzenia zaczynające się od człowieka i poświadczeń, więc detekcja oparta wyłącznie na sygnaturach malware wychwyci mniejszość przypadków.
Fazy zarządzania
Proces zarządzania incydentami zwyczajowo dzieli się na sześć faz: przygotowanie, detekcja i analiza, zawieranie, eradykacja, odzyskiwanie, i lekcje wyciągnięte. Każda faza ma jasno określone cele, osoby odpowiedzialne i procedury.
Artykuł 33 RODO wymaga zawiadomienia PUODO w ciągu 72 godzin.
Faza przygotowania jest najważniejsza i często najzaniedbywana. To w czasie pokoju musimy zbudować infrastrukturę, procedury i zespoły, które będą działać pod presją w przypadku incydentu. Przygotowanie obejmuje wiele elementów. Pierwszy to wdrożenie systemu detekcji zagrożeń - może to być rozwiązanie SIEM (Security Information and Event Management) takie jak Splunk czy IBM QRadar, które agreguje logi z całej infrastruktury i identyfikuje podejrzane aktywności. Drugie to ustanowienie zespołu reagowania na incydenty (Incident Response Team, IRT) obejmującego pracowników z IT, bezpieczeństwa, zarządzania, prawników i PR.
Trzecie to opracowanie dokumentu procedury zarządzania incydentami opisującego etapy, role i komunikację. Czwarte to wdrożenie systemów kopii zapasowych i disaster recovery - bez sprawnej kopii zapasowej, organizacja całkowicie bezbronna w obliczu ransomware. Piąte to regularne szkolenia zespołu IRT, aby wszyscy znali swoje role i procedury. Ćwiczenia dla zespołu i szkolenia dla całej organizacji to dwie różne rzeczy - procedura, której nikt nie przećwiczył, w kryzysie nie działa.
Detekcja i analiza
Faza detekcji i analizy zaczyna się, gdy system lub pracownik zauważy coś podejrzanego. To może być alarm z systemu SIEM, pracownik zauważający dziwny proces na komputerze, lub znalezienie śladu ataku w logach. W tym momencie ktoś z zespołu bezpieczeństwa lub IT powinien uruchomić procedurę incydentową. Pierwszy krok to potwierdzenie, że rzeczywiście dochodzi do incydentu - czasami alarmy są fałszywe.
Jeśli potwierdzono incydent, zespół zaczyna zbierać informacje: co dokładnie się stało, które systemy są zainfekowane, kiedy to się zaczęło, jak wiele danych mogło być zagrożone. Ta analiza powinna być przeprowadzona pod nadzorem osób technicznych, ale jednocześnie musi mieć świadomość wymogów prawnych - jeśli incydent obejmuje dane osobowe, to kwalifikuje się jako naruszenie danych (data breach) w rozumieniu RODO i musi być raportowane.
Zawieranie incydentu
Faza zawierania ma na celu ograniczenie szkód i zapobiegnięcie rozprzestrzenianiu się incydentu. Jeśli atakujący ma dostęp do systemu, zawieranie oznacza, że natychmiast ograniczamy jego możliwości. Konkretnie, może to oznaczać odłączenie zainfekowanego serwera od sieci, resetowanie haseł dla użytkowników, których konta mogły być skompromitowane, blokowanie podejrzanych adresów IP na firewallu, lub czasowe wyłączenie dostępu VPN. W przypadku ransomware, zawieranie jest krytyczne - im szybciej odłączymy zainfekowane systemy od sieci, tym mniejsza szansa, że ransomware rozprzestrzeni się na inne maszyny.
Eradykacja i odzyskiwanie
Faza eradykacji polega na usunięciu atakującego z infrastruktury. To nie jest tak proste, jak założenie może wskazywać. Jeśli atakujący zainstalował backdoor (ukryte wejście do systemu), zainstalowanie poprawki bezpieczeństwa nie wystarczy - musimy znaleźć i usunąć backdoor. W przypadku ransomware, eradykacja oznacza identyfikację i usunięcie malware z wszystkich zainfekowanych systemów. Ta faza powinna być przeprowadzona bardzo ostrożnie, ponieważ jeśli nie usuniemy w pełni zagrożenia, atakujący może powrócić i wznowić atak. Wiele organizacji błędnie zakłada, że po wdrożeniu poprawki bezpieczeństwa problem jest rozwiązany, a następnie jest zaskoczone, kiedy atakujący powraca kilka dni lub tygodni później.
Faza odzyskiwania polega na przywróceniu systemów do normalnego funkcjonowania. W przypadku zainfekowanych serwerów, może to oznaczać przeprowadzenie czystej instalacji systemu operacyjnego i przywrócenie danych z czystej kopii zapasowej. W przypadku ransomware, jeśli organizacja ma dostęp do kopii zapasowych, może przywrócić pliki bez płacenia okupu (co jest również zalecane, ponieważ płacenie chaotycznym bywa nieskuteczne, a wspiera przestępczość). Jednak ta faza musi być przeprowadzona ostrożnie - jeśli przywrócimy pliki z kopii zapasowej, która już była zainfekowana, to znowu zainfekujemy systemy.
Terminy zgłoszeń - trzy zegary biegnące równolegle
Najkosztowniejsze błędy w zarządzaniu incydentem nie są techniczne, tylko proceduralne. Zespół gasi pożar, a w tle biegną terminy, o których nikt nie pamięta.
RODO - 72 godziny. Naruszenie ochrony danych osobowych zgłasza się Prezesowi UODO w ciągu 72 godzin od jego stwierdzenia (art. 33). Jeżeli naruszenie może powodować wysokie ryzyko dla praw i wolności osób - dodatkowo zawiadamia się te osoby bez zbędnej zwłoki (art. 34). Zgłoszenie po terminie jest dopuszczalne, ale wymaga wyjaśnienia opóźnienia, a UODO realnie karze za jego brak: w kwietniu 2026 r. wspólnota mieszkaniowa zapłaciła 5 000 zł właśnie za niedopełnienie tego obowiązku.
Ustawa o KSC - 24 godziny, 72 godziny, miesiąc. Podmioty kluczowe i ważne przekazują wczesne ostrzeżenie w ciągu 24 godzin od wykrycia incydentu poważnego, pełne zgłoszenie w ciągu 72 godzin, a raport końcowy w ciągu miesiąca. Wczesne ostrzeżenie nie wymaga pełnej analizy - wymaga sygnału.
Audyt i raportowanie wewnętrzne. Podmiot kluczowy, który otrzymał raport z audytu bezpieczeństwa, przekazuje jego kopię organowi właściwemu w ciągu 3 dni roboczych.
Te zegary nie zastępują się nawzajem. Incydent, w wyniku którego wyciekły dane osobowe u podmiotu objętego ustawą o KSC, uruchamia oba tory naraz - wobec dwóch różnych organów, w dwóch różnych formatach, z różnymi momentami rozpoczęcia biegu terminu.
Dlatego pierwszym krokiem w procedurze reagowania nie powinno być działanie techniczne, tylko klasyfikacja: czy to zdarzenie, incydent, incydent poważny, naruszenie ochrony danych - czy kilka z tych rzeczy naraz. Od tej decyzji zależy, które zegary ruszają.
Role i decyzje - kto właściwie prowadzi incydent
W małych organizacjach incydentem zajmuje się ten, kto pierwszy go zauważył. To działa do momentu, w którym trzeba podjąć decyzję kosztowną - odłączyć system produkcyjny, zawiadomić klientów, zapłacić lub nie zapłacić okupu.
Minimalny podział ról, który warto ustalić przed incydentem:
Koordynator incydentu - jedna osoba, która prowadzi zdarzenie, utrzymuje oś czasu i pilnuje terminów. Nie musi być najlepszym technikiem w zespole; musi mieć mandat do wydawania poleceń.
Osoba decyzyjna po stronie biznesu - ktoś, kto może zgodzić się na przestój. W praktyce oznacza to członka zarządu z zastępcą, bo incydenty nie czekają na powrót z urlopu.
Osoba odpowiedzialna za zgodność - inspektor ochrony danych lub pełnomocnik ds. bezpieczeństwa, który ocenia obowiązki zgłoszeniowe i przygotowuje treść zgłoszeń.
Osoba odpowiedzialna za komunikację - jeden głos na zewnątrz, wobec klientów, mediów i kontrahentów. Rozproszona komunikacja w trakcie incydentu robi więcej szkody niż sam incydent.
Kontakt zewnętrzny - dostawca wsparcia technicznego, kancelaria, ubezpieczyciel. Numery telefonów zapisane poza systemami firmy, bo w razie ataku poczta i intranet mogą być niedostępne.
Czego nie robić w pierwszych godzinach
Nie wyłączać zainfekowanych maszyn bez zabezpieczenia dowodów. Wyłączenie zasilania kasuje pamięć operacyjną, w której często znajdują się klucze, procesy i połączenia sieciowe niezbędne do ustalenia przebiegu ataku. Izolacja sieciowa jest zwykle lepsza niż wyłączenie.
Nie kasować logów „żeby zrobić miejsce". To brzmi absurdalnie, dopóki nie zdarzy się na serwerze, na którym kończy się przestrzeń dyskowa w trakcie incydentu.
Nie komunikować się kanałami, które mogły zostać przejęte. Jeżeli podejrzewamy kompromitację poczty firmowej, koordynacja zespołu przez tę samą pocztę informuje atakującego o każdym ruchu obrońcy.
Nie ogłaszać, że „wszystko jest pod kontrolą", zanim to wiadomo. Wycofanie się z takiego komunikatu kosztuje więcej niż ostrożna informacja o trwającej analizie.
Nie negocjować okupu bez decyzji zarządu i konsultacji prawnej. Płatność może rodzić konsekwencje wykraczające poza sam incydent, a według danych Verizon za 2025 r. 64 procent zaatakowanych organizacji okupu nie zapłaciło.
Postmortem i wnioski
Ostatnia faza - wyciąganie wniosków (lessons learned) - jest tą, którą organizacje zaniedbują najczęściej. Po incydencie należy przeprowadzić postmortem - spotkanie zespołu IRT, gdzie analizuje się, co poszło dobrze, co źle, i co można ulepszyć. Postmortem powinien być prowadzony bez presji i skupiony na procesach, a nie na szukaniu winnych - celem jest nauka, nie karanie. Jego efektem powinna być lista rekomendacji z przypisanymi osobami i terminami, wdrożona po to, żeby podobny incydent się nie powtórzył.
Zawieranie incydentu jest kluczowe dla ograniczenia szkód.
Aby zobrazować ten proces, rozważmy praktyczny scenariusz: poniedziałek, godz. 15:30, administrator sieciowy zauważa alarm z systemu monitoring serwera File Server - nienormalnie wysoka aktywność dysku, a pracownicy zgłaszają, że mają problemy z dostępem do plików. Administrator otwiera procedurę zarządzania incydentami i powiadamia kierownika bezpieczeństwa. Po krótkiej analizie, kierownik bezpieczeństwa stwierdza, że to wygląda na atak ransomware - na ekranach użytkowników pojawia się wiadomość z żądaniem zapłaty i informacją, że wszystkie pliki zostały zaszyfrowane.
Procedura incydentowa jest uruchomiona, i w ciągu pięciu minut zespół IRT zbiera się na spotkaniu kryzysowym. Decyzja: natychmiast odłączamy File Server od sieci, informujemy wszystkich użytkowników, aby wyłączyli komputery, aby uniknąć rozprzestrzenia się malware. Jeśli możliwe, wyłączamy VPN firmy, aby zapobiec dostępowi zdalnym. Jednocześnie, trzeba przygotować komunikację dla kierownictwa i, w ostateczności, dla klientów i mediów.
W tym scenariuszu, godz. 16:00, zespół stwierdza, że atakujący ma dostęp do sieciowych dysków. Godzina 16:30, analiza wskazuje, że atak nastąpił przez słabą konfigurację serwera RDP (Remote Desktop Protocol), co pozwoliło atakującemu na brutalny atak siłowy na hasło administratora. Godzina 17:00, wszystkie systemy są odłączone od sieci. Godzina 17:30, kierownik bezpieczeństwa musi zadecydować: czy raportować do PUODO teraz, czy czekać, aż będą bardziej dokładne informacje?
RODO nie pozwala czekać zbyt długo - naruszenie musi być raportowane w ciągu siedemdziesięciu dwóch godzin. W tym scenariuszu, postanawia się raportować do PUODO we wtorek rano, po zebraniu więcej informacji. Jednocześnie, zespół rozpoczyna pracę nad identyfikacją, które dane zostały skompromitowane - RODO wymaga powiadomienia osób, których dane dotyczy, jeśli jest wysokie ryzyko dla ich praw i wolności.
Wtorek, godz. 9:00, zespół potwierdza, że zainfekowana jest cała infrastruktura plików, obejmująca dane wszystkich klientów firmy. Trzeba zawiadomić Prezesa UODO. Powstaje zgłoszenie naruszenia - opis tego, co się stało, kiedy, jakiego zakresu danych dotyczy, jaki jest potencjalny wpływ na osoby, których dane dotyczą, i jakie działania podjęto - i zostaje przesłane do organu drogą elektroniczną.
Równolegle, zespół zaczyna pracę nad eradykacją - analiza wskazuje, że atakujący był w systemie co najmniej cztery dni, zanim zaszyfrował pliki. Jeśli jest taka możliwość, przeprowadzana jest kryminalistyka cybernetyczna (forensics) - analiza logów i dysku w poszukiwaniu pozostawionego backdoora. Czwartek, po trzech dniach pracy, zespół potwierdza, że atakujący został wyeliminowany z systemu, i rozpoczyna się odzyskiwanie - przywrócenie plików z kopii zapasowej, która wiadomo, że nie była zainfekowana.
Równolegle z fazami technicznymi, zespół musi zarządzać komunikacją. Pracownicy muszą wiedzieć, co się stało i co powinni robić. Kierownictwo musi być na bieżąco o postępach. Klienci muszą być powiadomieni o tym, że ich dane mogły być zagrożone - to powinno być komunikat uczciwą i przejrzysty. PR musi być przygotowany do udzielenia odpowiedzi mediom.
Dokumentacja jest krytyczna. Każde działanie w trakcie incydentu powinno być zalogowane - kto co robił, kiedy, jakie decyzje zostały podjęte. Ta dokumentacja nie tylko pomaga w zrozumieniu, co się stało, ale będzie również ważna w przypadku postępowania regulacyjnego czy pozwu sądowego.
Po incydencie, postmortem powinno zaproponować działania naprawcze. W scenariuszu z RDP, takie działania mogłyby obejmować: aktywowanie uwierzytelniania wieloskładnikowego na wszystkie konta administratora, zmianę domyślnego portu RDP (choć to nie jest „bezpieczeństwo przez niejasność", bardzo zmniejsza skanowanie automatyczne), wdrożenie bardziej restrykcyjnego firewall policy, która ogranicza dostęp do usług administracyjnych tylko z autoryzowanych IP, czy wdrożenie segmentacji sieci, która ogranicza rozprzestrzenianie się malware w przypadku przyszłego ataku.
Zarządzanie incydentami nie kończy się na kwestiach technicznych - musi być wpisane w organizację. Procedura musi być znana wszystkim pracownikom, a zespół IRT musi być regularnie szkolony i testowany - tam, gdzie własnych zasobów brakuje, jego rolę może przejąć wsparcie zewnętrznego zespołu reagowania na incydenty. Działania naprawcze z postmortem muszą być rzeczywiście wdrożone, nie tylko zalecane. Organizacje, które to robią, skracają czas odzyskiwania i ograniczają straty w razie ataku, a przy okazji chronią reputację i wynik finansowy.
Jak taki cykl wygląda w realnym zdarzeniu, pokazujemy na przykładach ataku ransomware na Nową Rudę i wycieku danych na Uniwersytecie Warszawskim.
