Raportowanie incydentów NIS2 — procedura 24h/72h/30 dni

24 godziny od wykrycia. Nie od poniedziałkowego spotkania.

Ten jeden termin zmienia wszystko.

KSC 2.0 (polska implementacja dyrektywy NIS2, Dz. U. 2026 poz. 252) wymaga od podmiotów kluczowych i ważnych zgłoszenia incydentu poważnego w 24 godzinach od momentu wykrycia. Nie od momentu, gdy ktoś przeczyta alert. Nie od rana, gdy IT wróci do biura. Od wykrycia.

I tu zaczyna się problem większości firm. Atak ransomware w piątek o 23:00. Nikt go nie widzi do poniedziałku rano. Termin 24h przekroczony, zanim ktokolwiek się dowiedział. Brak zgłoszenia to osobne naruszenie ustawy — nawet jeśli firma skutecznie opanuje sam atak.

Obowiązek raportowania obowiązuje natychmiast od wejścia ustawy w życie. Nie ma okresu przejściowego. Nie ma moratorium. Od 3 kwietnia 2026 musisz być gotowy.

Co to jest „incydent poważny"

Nie każde zdarzenie wymaga zgłoszenia do CSIRT. Udany phishing zablokowany przez filtr? Skan portów z nieznanego IP? Dokumentujesz wewnętrznie, ale nie zgłaszasz.

Obowiązkowi raportowania podlega incydent poważny — taki, który spełnia co najmniej jedno kryterium:

Znaczące zakłócenie usług — usługa niedostępna lub poważnie ograniczona przez dłuższy czas. Linia produkcyjna stoi. System ERP nie działa. Klienci nie mogą złożyć zamówienia.

Straty finansowe — incydent powoduje lub może spowodować istotne straty. „Istotne" nie ma sztywnego progu — zależy od skali organizacji. Dla firmy z obrotem 10 mln PLN strata 200 000 PLN jest istotna.

Znaczna szkoda dla osób — wyciek danych osobowych, zagrożenie zdrowia, szkoda dla osób fizycznych lub prawnych.

W praktyce: jeśli nie jesteś pewien, czy incydent jest poważny — zgłoś. CSIRT nie karze za nadmiarowe zgłoszenia. Brak zgłoszenia incydentu, który okazał się poważny — to naruszenie.

Warto opracować wewnętrzne kryteria klasyfikacji. Ile użytkowników dotkniętych? Jak długo trwa zakłócenie? Czy są dane osobowe? Czy dotyczy łańcucha dostaw? Te pytania zadajesz sobie w pierwszych minutach po wykryciu — lepiej mieć je gotowe wcześniej niż wymyślać pod presją.

Trzy etapy — co, kiedy, jak

24 godziny — wczesne ostrzeżenie

Cel: powiadomić CSIRT, że coś się dzieje. Szybkość, nie kompletność.

Wymagane dane:

• Nazwa organizacji, NIP, sektor
• Data i godzina wykrycia
• Krótki opis — co zaobserwowano
• Wstępna klasyfikacja — ransomware, DDoS, wyciek, nieznane
• Podejrzenie złośliwego działania — tak/nie
• Potencjalny wpływ transgraniczny — tak/nie/nieznany
• Dane kontaktowe osoby odpowiedzialnej

Nie musisz jeszcze znać szczegółów. Wystarczy fakt: wykryliśmy incydent, wstępnie wygląda na ransomware, nie wiemy jeszcze o wpływie transgranicznym. Punkt kontaktowy: tel. XXX.

72 godziny — pełne powiadomienie

Teraz CSIRT oczekuje szczegółów technicznych. Zespół reagowania powinien mieć wstępne wyniki analizy.

Wymagane dane (oprócz tego, co było w 24h):

• Szczegółowa ocena dotkliwości i zasięgu
• Lista dotkniętych systemów i usług
• Wskaźniki kompromitacji (IoC) — adresy IP, domeny, hashe SHA256, sygnatury
• Wektor ataku — jak doszło do naruszenia (jeśli ustalono)
• Chronologia zdarzeń — timeline
• Podjęte działania zaradcze — izolacja, blokady, patching
• Szacowane straty — finansowe, operacyjne

30 dni — raport końcowy

Dokument strategiczny. Pokazuje, że organizacja nie tylko opanowała incydent, ale wyciągnęła wnioski.

Wymagane dane:

• Pełna analiza przyczyny źródłowej (root cause analysis)
• Kompletna chronologia od pierwszego wektora do pełnego odzyskania
• Opis działań naprawczych i ich skuteczności
• Plan zapobiegania — co zmienisz, żeby to się nie powtórzyło
• Wnioski (lessons learned) — co zadziałało, co nie
• Ostateczna ocena wpływu i strat

Dobrze przygotowany raport końcowy może pozytywnie wpłynąć na ocenę organizacji przez organ nadzorczy. To nie formalność — to dowód dojrzałości.

Do kogo zgłaszasz

Dla większości firm właściwy jest CSIRT NASK. Portal incydent.cert.pl ma formularz online z polami odpowiadającymi wymaganiom ustawy.

Nie wiesz, do którego CSIRT? Zgłoś do CSIRT NASK. Zespoły współpracują i w razie potrzeby przekierują.

Przykład: ransomware w firmie produkcyjnej

Żeby nie było abstrakcyjnie — scenariusz krok po kroku.

Firma: podmiot ważny, sektor produkcyjny, 180 pracowników.

Godzina 0: Wykrycie

System SIEM wykrywa anomalię — masowe szyfrowanie plików na serwerze plików. Zespół SOC potwierdza: ransomware LockBit 4.0 zaszyfrował 3 serwery produkcyjne. Linia produkcyjna zatrzymana.

Do godziny 24: Wczesne ostrzeżenie

Zespół IR składa ostrzeżenie do CSIRT NASK przez incydent.cert.pl:

„Wykryto atak ransomware LockBit 4.0. Zaszyfrowano 3 serwery produkcyjne. Linia produkcyjna wstrzymana. Podejrzewane złośliwe działanie — TAK. Wpływ transgraniczny — nieznany (weryfikujemy łańcuch dostaw). Osoba kontaktowa: Jan Kowalski, CISO, tel. XXX."

Do godziny 72: Pełne powiadomienie

Po wstępnej analizie forensycznej:

• Wektor ataku: phishing z załącznikiem .xlsm → makro → Cobalt Strike → lateral movement → ransomware
• IoC: 3 adresy IP serwerów C2, 2 domeny, hash SHA256 payloadu
• Dotknięte systemy: 3 serwery plików, 12 stacji roboczych, ERP offline
• Wpływ: produkcja wstrzymana na 18h, szacowana strata 450 tys. PLN
• Działania: izolacja segmentu sieci, blokada IoC na firewallu, przywracanie z backupu

Do dnia 30: Raport końcowy

• Root cause: pracownik otworzył złośliwy załącznik. Brak MFA na VPN umożliwił lateral movement po przejęciu credentiali.
• Remediacja: wdrożono MFA (Microsoft Entra ID), wymuszono politykę blokowania makr, zaktualizowano reguły EDR
• Lessons learned: szkolenia phishingowe, segmentacja sieci, rozszerzenie monitoringu o SOC 24/7

Ten scenariusz pokazuje jedną rzecz: bez monitoringu 24/7 wykrycie w piątek wieczorem nie nastąpiłoby do poniedziałku. Termin 24h byłby przekroczony o 40 godzin.

Najczęstsze błędy przy raportowaniu — czego unikać

Widzimy je powtarzalnie u firm, które raportują incydent po raz pierwszy.

Czekanie na pełny obraz przed zgłoszeniem. To naturalny instynkt — „zgłosimy jak będziemy wiedzieć więcej". Ale ustawa mówi 24h od wykrycia, nie 24h od zakończenia analizy. Wczesne ostrzeżenie ma być szybkie, nie kompletne. Lepiej wysłać krótki formularz z trzema faktami niż szczegółowy raport po 48 godzinach.

Brak wyznaczonej osoby odpowiedzialnej. Formalnie za raportowanie odpowiada zarząd. Operacyjnie — musi to być wyznaczony Incident Manager lub zespół SOC. Jeśli w momencie incydentu trzech ludzi jednocześnie dyskutuje „kto to powinien zgłosić" — tracisz godziny. Wyznacz osobę i zapasową osobę. Zapisz to w procedurze. Daj im dane logowania do portalu incydent.cert.pl.

Raportowanie jako afterthought. Firma skupia się na powstrzymaniu ataku — słusznie. Ale raportowanie biegnie równolegle, nie po. Wyznacz kogoś, kto dokumentuje chronologię od pierwszej minuty, zbiera IoC i przygotowuje formularz, podczas gdy reszta zespołu gasi pożar.

Nieprzechowywanie dowodów. Widzieliśmy to wielokrotnie: firma reinstaluje zainfekowane systemy przed zebraniem forensycznych danych. Szybciej wracają do pracy — ale nie mają materiału na raport końcowy. Zabezpiecz obraz dysku zanim wycierasz. Logi w chmurze rozwiązują ten problem — ale lokalne artefakty też mają wartość.

Brak przetestowanej procedury. Procedura IR w szufladzie to procedura niczyja. Jeśli zespół widzi ją po raz pierwszy w momencie ataku — jest bezużyteczna. Roczne ćwiczenia tabletop to minimum. Najlepsze firmy testują kwartalnie.

Kto powinien wiedzieć o incydencie — i kiedy

Raportowanie do CSIRT to obowiązek prawny. Ale komunikacja wewnętrzna jest równie ważna — i trudniejsza.

Zarząd — musi wiedzieć natychmiast. KSC 2.0 nakłada osobistą odpowiedzialność, więc informowanie zarządu „po wszystkim" to ryzyko prawne. Zarząd nie musi znać technicznego detalu — potrzebuje: co się stało, jaki jest wpływ biznesowy, co robimy, czego potrzebujemy.

Dział prawny — od pierwszych godzin. Jeśli incydent dotyczy danych osobowych, dochodzi obowiązek RODO (72h do UODO). Dwa zgłoszenia, dwa terminy, dwa organy. Prawnik musi to koordynować.

Komunikacja / PR — jeśli incydent jest widoczny zewnętrznie (przestój usługi, wyciek danych). Gorsza od ataku jest tylko sytuacja, w której klienci dowiadują się o nim z mediów.

Klienci i partnerzy — jeśli incydent dotyczy łańcucha dostaw. KSC 2.0 wymaga nadzoru nad dostawcami. Jeśli Twoi klienci są podmiotami regulowanymi, mogą mieć obowiązek raportowania incydentu u swojego dostawcy (czyli u Ciebie).

Procedura eskalacji — kto, kiedy, jak — powinna być częścią planu IR. Nie wymyślasz jej pod presją o 3 w nocy.

Procedura wewnętrzna — co musisz mieć przygotowane

Żeby raportowanie działało, potrzebujesz udokumentowanej procedury Incident Response. Sześć faz:

Detekcja — ciągły monitoring (SIEM/XDR), alerty SOC, zgłoszenia użytkowników. Ktoś musi patrzeć na te alerty. Całą dobę.

Triage — ocena dotkliwości. Czy to incydent poważny? Czy wymaga zgłoszenia do CSIRT? Decyzja w pierwszych minutach.

Containment — izolacja dotkniętych systemów. Blokada komunikacji z C2. Zabezpieczenie dowodów. Tu liczy się czas — każda minuta opóźnienia to kolejne zaszyfrowane systemy.

Eradykacja — usunięcie malware, zamknięcie luk, reset skompromitowanych kont.

Recovery — przywrócenie systemów z backupu, weryfikacja integralności, stopniowe przywracanie usług.

Lessons learned — analiza post-mortem, aktualizacja procedur, szkolenia. Po każdym incydencie organizacja powinna być bezpieczniejsza niż przed nim.

Każda faza wymaga przypisanych ról i odpowiedzialności, zdefiniowanych eskalacji i szablonów dokumentów. Procedura musi być testowana co najmniej raz w roku — KSC 2.0 tego wymaga.

Czego ten artykuł nie powie — i dlaczego to ważne

Nie powiemy Ci, że to proste. Spełnienie wymogów raportowania własnymi siłami wymaga zespołu dostępnego 24/7, narzędzi SIEM/XDR i doświadczenia w obsłudze incydentów. Dla firmy 100–200 osób to nierealistyczne — budowa własnego SOC kosztuje 1,25–2,4 mln PLN rocznie.

Dlatego istnieje Managed SOC. Dlatego SecIQ oferuje monitoring 24/7/365 z SLA poniżej 15 minut na reakcję, gotowymi szablonami zgłoszeń do CSIRT i zespołem, który przygotuje raport końcowy z root cause analysis.

Ale to jest decyzja, którą podejmujesz po analizie — nie po przeczytaniu artykułu.

Trzy rzeczy, które możesz zrobić teraz:

1. Sprawdź, czy Twoja firma podlega pod KSC 2.0
2. Opracuj wewnętrzne kryteria klasyfikacji incydentów
3. Przetestuj swoją procedurę reagowania — nawet jeśli jest na jednej kartce

Jeśli potrzebujesz wsparcia — umów konsultację. Pokażemy, jak wygląda raportowanie incydentów od detekcji po raport końcowy.

Źródła

• Ustawa z dnia 23 stycznia 2026 r. o zmianie ustawy o KSC (Dz. U. 2026 poz. 252) — pełny tekst nowelizacji
• Dyrektywa NIS2 — pełny tekst (EUR-Lex) — oficjalny tekst dyrektywy (UE) 2022/2555
• CSIRT NASK — portal zgłaszania incydentów — formularz zgłoszeniowy dla sektora cywilnego
• ENISA — NIS2 Directive Implementation Guidance — wytyczne Agencji UE ds. Cyberbezpieczeństwa