Co zrobić po wykryciu incydentu?

Michał Rutkowski • dla zespołów bezpieczeństwa i IT oraz IOD • opublikowano 18 sierpnia 2026 • aktualizacja 18 sierpnia 2026 • 9 min czytania

Stan prawny

Sierpień 2026. Art. 33 i 34 RODO w brzmieniu niezmienionym. Ustawa o KSC w brzmieniu nadanym nowelizacją z 23 stycznia 2026 r. (Dz.U. 2026 poz. 252), obowiązującą od 3 kwietnia 2026 r. — wraz z przepisami przejściowymi o adresacie zgłoszeń.

Ostatnia istotna aktualizacja: 18 sierpnia 2026.

Krótka odpowiedź

Najpierw potwierdzić zdarzenie i zabezpieczyć ślady, potem ograniczyć skutki, a dopiero na tej podstawie kwalifikować sprawę prawnie. Wykrycie uruchamia kilka niezależnych zegarów naraz — obowiązek wobec CSIRT biegnie od wykrycia incydentu poważnego, obowiązek wobec Prezesa UODO od stwierdzenia naruszenia ochrony danych, a terminy umowne od momentu wskazanego w umowie. Kolejność działań jest przy tym ważniejsza od tempa: czynność wykonana za wcześnie — na przykład odtworzenie systemu z kopii przed zabraniem materiału dowodowego — zamyka drogę do ustaleń, których nie da się później powtórzyć.

Dlaczego to pytanie w ogóle powstaje

Większość organizacji ma procedurę reagowania na incydenty i większość tych procedur opisuje ścieżkę techniczną: kto przyjmuje zgłoszenie, jak je klasyfikować, kiedy eskalować. Pytanie „co dalej” pojawia się w innym momencie — wtedy, gdy zdarzenie jest już potwierdzone, część systemów nie działa, a kilka osób jednocześnie czeka na decyzję. Procedura mówi wtedy, kto ma coś zrobić, ale rzadko mówi, w jakiej kolejności i czego nie robić.

Drugie źródło wątpliwości jest regulacyjne. To samo zdarzenie potrafi uruchomić obowiązki w dwóch albo trzech reżimach naraz, a każdy z nich liczy czas od czego innego. Podmiot kluczowy lub ważny w rozumieniu ustawy o krajowym systemie cyberbezpieczeństwa (KSC) reaguje na incydent poważny od chwili jego wykrycia. Administrator danych w rozumieniu RODO reaguje na naruszenie ochrony danych od chwili jego stwierdzenia, czyli od momentu, w którym uzyskał wystarczającą pewność, że doszło do zdarzenia dotyczącego danych osobowych. Te dwa momenty rzadko wypadają w tej samej godzinie, a przy zdarzeniach rozłożonych w czasie potrafią dzielić je dni.

Trzecie źródło jest najbardziej praktyczne. Pierwsze godziny rozstrzygają o tym, czym organizacja będzie dysponowała później. Ślady w systemach mają ograniczoną trwałość: logi się rotują, pamięć ulotna znika po restarcie, migawki maszyn wirtualnych są nadpisywane. Zespół, który w pierwszym odruchu przywraca działanie usługi, postępuje racjonalnie z perspektywy ciągłości — i jednocześnie usuwa materiał, na którym miała się oprzeć ocena zasięgu zdarzenia, treść zgłoszenia do organu i rozmowa z ubezpieczycielem.

Co trzeba ustalić przed decyzją

Czy zdarzenie jest potwierdzone i co dokładnie objęło

Sygnał to jeszcze nie incydent. Zanim organizacja uruchomi pełną reakcję, ktoś musi potwierdzić, że zdarzenie rzeczywiście zaszło, i wstępnie określić jego zasięg: które systemy, które dane, jaki okres, czy dostęp nadal trwa. Weryfikacja ma być krótka i udokumentowana co do godziny, bo od niej liczy się dalsza chronologia.

Zasięg ustala się w trzech wymiarach naraz: co przestało działać, co zostało zmienione i co mogło zostać ujawnione. Trzeci wymiar bywa badany na końcu, choć to on przesądza o obowiązkach wobec organu ochrony danych. Jeżeli po pierwszej analizie nie da się wykluczyć dostępu do danych osobowych, przyjmij roboczo, że dostęp mógł nastąpić, i prowadź obie ścieżki równolegle — zawężenie ustaleń jest łatwiejsze niż nadrobienie straconego czasu.

Kto prowadzi sprawę i kto podejmuje które decyzje

W sprawnej reakcji rozdzielone są trzy role. Ktoś prowadzi sprawę i pilnuje chronologii. Ktoś decyduje o działaniach technicznych — odcięciu segmentu sieci, wyłączeniu konta, wstrzymaniu odtwarzania. Ktoś rozstrzyga o kwalifikacji prawnej i zgłoszeniach: inspektor ochrony danych po stronie RODO, osoba odpowiedzialna za obowiązki z ustawy o KSC po stronie cyberbezpieczeństwa.

Role te mogą być łączone w mniejszej organizacji, ale muszą być nazwane przed zdarzeniem. W ustawie o KSC odpowiedzialność za wykonywanie obowiązków dotyczących obsługi i zgłaszania incydentów spoczywa na kierowniku podmiotu i nie znika przez powierzenie zadań innej osobie — ustawa przewiduje dla kierownika odrębną karę pieniężną między innymi za niewykonanie obowiązków dotyczących zgłaszania incydentów i sprawozdawczości. Wynika z tego prosty wniosek organizacyjny: kierownictwo musi dowiedzieć się o incydencie poważnym na tyle wcześnie, żeby decyzje o zgłoszeniu zapadały w terminie, a nie po jego upływie.

Które zegary już biegną

Terminy podaje się jako fakt, nie jako presję — ale trzeba je znać zawczasu, bo w trakcie zdarzenia nie ma czasu na ich ustalanie.

  • Ustawa o KSC — podmioty kluczowe i ważne. Wczesne ostrzeżenie o incydencie poważnym: niezwłocznie, nie później niż w ciągu 24 godzin od momentu wykrycia. Zgłoszenie incydentu poważnego: niezwłocznie, nie później niż w ciągu 72 godzin — również od momentu wykrycia, a nie od wczesnego ostrzeżenia. To najczęstsze przekłamanie w opracowaniach i najkosztowniejsze w praktyce, bo daje złudzenie trzech dodatkowych dni.
  • Ustawa o KSC — sprawozdawczość po zgłoszeniu. Sprawozdanie okresowe przekazuje się wyłącznie na wniosek właściwego CSIRT. Sprawozdanie końcowe — nie później niż w ciągu miesiąca od dnia zgłoszenia. Jeżeli w tym czasie obsługa incydentu jeszcze się nie zakończyła, podmiot przekazuje sprawozdanie z postępu obsługi, a sprawozdanie końcowe składa w ciągu miesiąca od jej zakończenia. Kanałem jest centralny system teleinformatyczny S46.
  • RODO — administrator danych. Zgłoszenie naruszenia Prezesowi UODO następuje bez zbędnej zwłoki, a w miarę możliwości nie później niż w terminie 72 godzin od stwierdzenia naruszenia — chyba że jest mało prawdopodobne, by naruszenie skutkowało ryzykiem naruszenia praw lub wolności osób. Standardem jest „bez zbędnej zwłoki”; 72 godziny to granica, a nie termin do wykorzystania. Do zgłoszenia po jej upływie dołącza się wyjaśnienie przyczyn opóźnienia. Jeżeli nie da się zebrać kompletu informacji, przepisy dopuszczają przekazywanie ich sukcesywnie.
  • RODO — podmiot przetwarzający. Procesor, który stwierdził naruszenie, zgłasza je administratorowi bez zbędnej zwłoki. Ustawa nie określa, od kiedy w tym układzie biegnie termin administratora — w praktyce przyjmuje się, że od chwili otrzymania informacji od procesora, dlatego umowa powierzenia powinna wyznaczać konkretny czas i kanał powiadomienia.
  • Zobowiązania sektorowe i umowne. Podmioty finansowe mają odrębne terminy wynikające z rozporządzenia DORA i standardów technicznych do niego, a wiele umów z klientami zawiera własne zobowiązania informacyjne, zwykle krótsze niż ustawowe. Te terminy nie zastępują się nawzajem — biegną równolegle.

Dwa zastrzeżenia przejściowe, bez których powyższa lista wprowadza w błąd.

Do kogo faktycznie idzie zgłoszenie. Ustawa kieruje zgłoszenia do właściwego CSIRT sektorowego, ale przepisy przejściowe stanowią, że do czasu ogłoszenia komunikatu o osiągnięciu przez ten CSIRT zdolności operacyjnej zgłasza się do właściwego CSIRT MON, CSIRT NASK albo CSIRT GOV. Organy właściwe mają na ustanowienie CSIRT-ów sektorowych osiemnaście miesięcy od wejścia nowelizacji w życie. W sierpniu 2026 r. dla większości sektorów adresatem jest zatem CSIRT poziomu krajowego — sprawdź w swojej procedurze, czy nie wpisano tam docelowego stanu.

Od kiedy nowe zasady wiążą dotychczasowych operatorów usług kluczowych. Podmioty, które przed 3 kwietnia 2026 r. miały ten status, zgłaszają incydenty poważne według nowych przepisów po upływie sześciu miesięcy od wejścia nowelizacji w życie. Dla nich zmiana reguł wypada więc na początku października 2026 r.

Osobne reguły dotyczą dwóch grup. Dostawca usług zaufania zgłasza incydent poważny w ciągu 24 godzin od wykrycia. Podmiot ważny będący podmiotem publicznym jest zwolniony z przekazywania wczesnego ostrzeżenia oraz sprawozdań — okresowego, z postępu obsługi i końcowego.

To, które z tych zegarów w ogóle dotyczą organizacji, wynika z jej kwalifikacji, a nie z charakteru zdarzenia. Organizacje, które nie mają tego rozstrzygniętego na piśmie, zwykle zaczynają od ustalenia zakresu obowiązków w NIS2 i KSC, zanim połączą ścieżki zgłoszeniowe w jedną procedurę.

Kiedy zdarzenie jest incydentem poważnym

Klasyfikacja nie jest oceną intuicyjną. Progi uznania incydentu za poważny — według rodzaju zdarzenia w poszczególnych sektorach i podsektorach — określa Rada Ministrów w rozporządzeniu, biorąc pod uwagę liczbę użytkowników dotkniętych zakłóceniem, czas oddziaływania incydentu na usługę, zasięg geograficzny oraz inne czynniki charakterystyczne dla sektora. Z tej delegacji wyłączone są podmioty, dla których progi ustaliła Komisja Europejska w rozporządzeniu wykonawczym — dotyczy to części podmiotów sektora infrastruktury cyfrowej i usług cyfrowych, które stosują kryteria unijne bezpośrednio.

Praktyczny wniosek jest taki, że progi trzeba mieć wypisane w procedurze przed zdarzeniem, z podaniem, które źródło obowiązuje daną organizację. Ustalanie tego w trakcie pierwszej doby zjada czas, którego w niej nie ma.

Co zabezpieczyć, zanim zacznie się przywracanie

Ograniczanie skutków i zbieranie dowodów nie wykluczają się, ale wymagają kolejności. Przed odtworzeniem środowiska warto zabezpieczyć obrazy zajętych systemów i pamięć ulotną, wyeksportować logi z systemów o krótkiej retencji oraz zapisać konfigurację w stanie sprzed zmian. Izolacja segmentu sieci jest przy tym bezpieczniejsza od wyłączenia maszyny, ponieważ zatrzymuje działanie napastnika, nie kasując stanu systemu.

Równolegle prowadzi się jedną chronologię zdarzenia. Zapis, kto, kiedy i co ustalił lub zmienił, jest później podstawą zgłoszenia, rozliczenia z ubezpieczycielem i odpowiedzi na pytania organu. Odtwarzanie tej osi czasu tydzień po zdarzeniu, z pamięci kilku osób, daje wynik, którego nie da się obronić.

Kto jeszcze musi się dowiedzieć

Poza organami krąg informowanych wyznaczają przepisy, relacje umowne i faktyczny wpływ zdarzenia — w tej kolejności, bo pierwszy element bywa pomijany.

Ustawa o KSC nakłada na podmioty kluczowe i ważne dwa obowiązki informacyjne wobec użytkowników usług. Przy poważnym cyberzagrożeniu podmiot informuje użytkowników, na których zagrożenie może mieć wpływ, o możliwych do podjęcia środkach zapobiegawczych; o samym zagrożeniu informuje wtedy, gdy nie zwiększy to poziomu ryzyka dla bezpieczeństwa systemów. Przy incydencie poważnym mającym niekorzystny wpływ na świadczenie usług — informuje użytkowników o incydencie. To są obowiązki, a nie decyzje komunikacyjne; pytanie brzmi „jak i kiedy”, a nie „czy”.

Dalej wchodzą relacje umowne. Jeżeli organizacja jest podmiotem przetwarzającym, jej pierwszym adresatem są administratorzy, dla których przetwarza dane — i to oni, nie ona, podejmują decyzję o zgłoszeniu do organu. Osobną decyzją jest zawiadomienie osób, których dane dotyczą: powstaje dopiero przy wysokim ryzyku naruszenia ich praw lub wolności i rządzi się własnymi zasadami, opisanymi w materiale Czy każde naruszenie ochrony danych trzeba zgłosić?.

Komunikacja wewnętrzna wymaga tej samej dyscypliny co zewnętrzna. Jedno źródło informacji, jeden zatwierdzony komunikat i wyraźne wskazanie, czego jeszcze nie wiadomo, ograniczają liczbę wersji krążących po organizacji — a to one najczęściej trafiają potem na zewnątrz w postaci, której nikt nie zatwierdził.

Pierwsza doba — lista kontrolna

Godziny 0–4

  • Potwierdzić zdarzenie oraz zapisać datę i godzinę potwierdzenia.
  • Wyznaczyć osobę prowadzącą sprawę i uruchomić jedną, wspólną chronologię.
  • Zabezpieczyć logi, obrazy systemów i pamięć ulotną przed jakimkolwiek przywracaniem.
  • Zatrzymać rozprzestrzenianie: izolacja segmentu, odebranie dostępów, wymuszenie zmiany poświadczeń.
  • Ustalić wstępny zasięg: systemy, kategorie danych, okres, szacunkowa liczba osób, których dane mogły zostać objęte.
  • Sprawdzić, które reżimy dotyczą organizacji, i wpisać do chronologii godziny, o których upływają terminy — obie liczone od wykrycia, nie jedna od drugiej.
  • Powiadomić kierownictwo w zakresie potrzebnym do podjęcia decyzji o zgłoszeniach.

Doba pierwsza

  • Powiadomić dostawców oraz administratorów, wobec których organizacja ma obowiązki umowne lub ustawowe.
  • Przygotować i wysłać wczesne ostrzeżenie, jeżeli zdarzenie przekracza progi incydentu poważnego — do CSIRT właściwego na dziś, nie docelowo.
  • Rozstrzygnąć, czy powstał obowiązek poinformowania użytkowników usług, i przygotować treść komunikatu.
  • Przeprowadzić ocenę ryzyka dla osób i podjąć decyzję o zgłoszeniu do Prezesa UODO albo o jej braku — wraz z uzasadnieniem.
  • Zapisać naruszenie w dokumentacji naruszeń niezależnie od tego, czy zostało zgłoszone.

Lista porządkuje sekwencję, ale nie zastępuje procedury dostosowanej do organizacji. Jej wartość ujawnia się dopiero wtedy, gdy przed zdarzeniem przypisano do każdego punktu konkretną rolę, a nie dział.

Najczęstsze błędy

  • Przywrócenie usługi przed zabezpieczeniem śladów. Najczęstszy i najtrudniejszy do naprawienia. Po odtworzeniu z kopii zwykle nie da się już ustalić, jak długo trwał dostęp ani co zostało pobrane.
  • Doliczanie 72 godzin do wczesnego ostrzeżenia. Oba terminy z ustawy o KSC biegną od wykrycia incydentu. Procedura, w której zgłoszenie ma nastąpić „w ciągu 72 godzin od wczesnego ostrzeżenia”, planuje przekroczenie terminu.
  • Wspólna rubryka na datę wykrycia incydentu i stwierdzenia naruszenia. To dwa odrębne ustalenia: jedno o wpływie na usługę, drugie o narażeniu danych. Mogą wypaść w tej samej chwili — ale przy jednym polu w dokumentacji nie da się wykazać, kiedy i na jakiej podstawie stwierdzono naruszenie.
  • Wpisanie do procedury docelowego adresata zgłoszeń. CSIRT sektorowe dopiero powstają; do czasu komunikatu o ich zdolności operacyjnej zgłoszenia trafiają do CSIRT MON, NASK albo GOV.
  • Uznanie, że zgłoszenie do CSIRT wyczerpuje obowiązki. Zgłoszenia w różnych reżimach mają różnych adresatów, różny zakres i różne terminy. Żadne z nich nie zastępuje pozostałych. Nie zastępują też obowiązku poinformowania użytkowników usług.
  • Traktowanie utraty dostępności jako sprawy wyłącznie technicznej. Brak dostępu do danych jest naruszeniem ochrony danych tak samo jak ich ujawnienie, nawet jeżeli kopia zapasowa zadziałała.
  • Komunikacja rozproszona. Równoległe wiadomości od działu IT, obsługi klienta i zarządu, różniące się treścią, tworzą później problem większy niż samo zdarzenie.
  • Zamknięcie sprawy na przywróceniu działania. Bez sprawozdania końcowego, wniosków i zmian w zabezpieczeniach organizacja wraca dokładnie do stanu, w którym incydent był możliwy.

Wnioski i dalsze kroki

Po wykryciu incydentu organizacja podejmuje nie jedną decyzję, lecz sekwencję decyzji o różnych właścicielach i różnych terminach. Tempo pomaga tylko wtedy, gdy kolejność jest właściwa: potwierdzenie, zabezpieczenie śladów, ograniczenie skutków, kwalifikacja, zgłoszenia, informacja dla użytkowników, przywrócenie działania, wnioski.

Przed kolejnym zdarzeniem warto przesądzić pięć rzeczy. Kto ma prawo uznać, że incydent został potwierdzony, i gdzie ten moment jest zapisywany. Jak wygląda minimalny zestaw dowodów zabezpieczanych zawsze, niezależnie od rodzaju zdarzenia. Które progi klasyfikacji obowiązują organizację i skąd pochodzą. Które reżimy jej dotyczą, kto w każdym z nich przygotowuje zgłoszenie i do kogo je kieruje. Kto zatwierdza komunikaty wychodzące na zewnątrz.

Organizacja, która ma te elementy ustalone, spędza pierwsze godziny na pracy merytorycznej. Organizacja, która ich nie ma, spędza je na ustalaniu kompetencji — i to zwykle, a nie skala samego zdarzenia, decyduje o tym, jak sprawa wygląda później w dokumentach.

Materiały powiązane

Źródła

  • Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO), art. 33 i art. 34, tekst skonsolidowany — EUR-Lex: eur-lex.europa.eu (dostęp: 18.08.2026)
  • Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa, art. 11–12c, tekst ujednolicony — Kancelaria Sejmu, ISAP: isap.sejm.gov.pl (dostęp: 18.08.2026)
  • Ustawa z dnia 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustaw (Dz.U. 2026 poz. 252) — przepisy przejściowe dotyczące zgłaszania incydentów, Dziennik Ustaw: dziennikustaw.gov.pl (dostęp: 18.08.2026)
  • Zgłoszenie naruszenia ochrony danych — Urząd Ochrony Danych Osobowych: uodo.gov.pl (dostęp: 18.08.2026)
  • W jakim terminie należy zgłosić naruszenie Prezesowi UODO? — Urząd Ochrony Danych Osobowych: uodo.gov.pl (dostęp: 18.08.2026)
  • Pytania i odpowiedzi dotyczące nowelizacji ustawy o krajowym systemie cyberbezpieczeństwa — Ministerstwo Cyfryzacji: cyber.gov.pl (dostęp: 18.08.2026)

Autor

Michał Rutkowski — LabLogic. Łączy perspektywę prawną, organizacyjną i technologiczną w pracy z zarządami średnich i dużych organizacji: wsparcie i pełnienie funkcji IOD/DPO, przygotowanie do NIS2 i KSC, reakcja na incydenty, audyty i szkolenia. Kontakt: M.Rutkowski@LabLogic.pl

Ustal kolejność działań, zanim będzie potrzebna

Jeżeli reakcja na incydent opiera się dziś w Twojej organizacji na doświadczeniu kilku osób i ustaleniach podejmowanych w trakcie zdarzenia, warto uporządkować ten proces na spokojnie. Wsparcie przy incydentach i naruszeniach obejmuje ocenę sytuacji, decyzje o zgłoszeniach, komunikację i działania naprawcze.

Materiał ma charakter ogólny i edukacyjny. Nie stanowi indywidualnej opinii prawnej ani rekomendacji dla konkretnej organizacji. Zakres obowiązków należy ocenić z uwzględnieniem jej sytuacji.

Stan prawny: sierpień 2026.

Przewijanie do góry