Dwadzieścia cztery godziny. Tyle daje NIS2 na wysłanie wstępnego zgłoszenia do właściwego CSIRT od momentu wykrycia poważnego incydentu. To nie dużo — szczególnie jeśli incydent wykryjesz w piątek wieczorem, a w Twojej firmie nie ma kogoś, kto wie, co w tej sytuacji zrobić.
Zarządzanie incydentami kojarzy się z dużymi firmami i dedykowanymi zespołami SOC. W rzeczywistości małe organizacje potrzebują prostszej wersji tego samego — i całkowicie da się to zbudować bez dużych nakładów.
Co NIS2 wymaga w zakresie incydentów?
Trzy terminy, które musisz zapamiętać:
- 24 godziny — wczesne ostrzeżenie do CSIRT po wykryciu poważnego incydentu
- 72 godziny — pełne powiadomienie z oceną wpływu i pierwszymi działaniami
- 30 dni — raport końcowy z analizą przyczyn i podjętymi środkami
Poważny incydent to taki, który powoduje lub może powodować poważne zakłócenia w świadczeniu usług lub straty finansowe. W praktyce: ransomware, wyciek danych klientów, długotrwała niedostępność usługi, przejęcie konta uprzywilejowanego.
Gdzie zgłaszać incydenty?
W Polsce zgłoszenia trafiają do jednego z trzech CSIRT-ów krajowych, zależnie od sektora:
- CSIRT NASK — dla większości podmiotów komercyjnych i JST: incydent.cert.pl
- CSIRT GOV — dla administracji rządowej i infrastruktury krytycznej
- CSIRT MON — dla sektora obronnego
Formularz na incydent.cert.pl działa 24/7. Warto go przejrzeć jeszcze przed wystąpieniem incydentu — żebyś wiedział, jakich informacji będziesz potrzebował i nie szukał ich w środku nocy pod presją czasu.
Jak zbudować procedurę zarządzania incydentami
Dobra procedura incydentowa to dokument, który można przekazać każdemu pracownikowi i który jasno mówi: co robisz w pierwszej godzinie, kogo dzwonisz, co zapisujesz.
Minimum, które musi znaleźć się w procedurze:
1. Klasyfikacja — co jest incydentem?
Określ, co kwalifikuje się jako incydent wymagający działania. Prosta matryca: zdarzenie → kategoria (niski/średni/wysoki/krytyczny) → działanie. Ransomware to zawsze „krytyczny”. Niedostępność strony przez 5 minut — zależy od sektora.
2. Pierwsza godzina — krok po kroku
Kto co robi. Kto jest osobą zgłaszającą, kto decyduje o eskalacji, kto kontaktuje się z klientami. W małej firmie to może być jedna osoba, ale musi być zapisane — i musi być zastępstwo.
3. Co dokumentować na bieżąco
Każde działanie podjęte podczas incydentu z godziną. To jest podstawa raportu do CSIRT i ochrona prawna organizacji. Wystarczy plik tekstowy lub arkusz — ważne, żeby był prowadzony w czasie rzeczywistym.
4. Kiedy i jak zgłaszać do CSIRT
Bezpośredni link, login, dane kontaktowe — gotowe. Nie szukane w panice.
5. Komunikacja zewnętrzna
Kto i kiedy informuje klientów lub media. Zbyt wczesna lub zbyt późna komunikacja może być równie kosztowna co sam incydent.
Narzędzia, które pomagają — bezpłatne
Do zarządzania incydentami nie potrzebujesz dedykowanego systemu. Na start wystarczą:
- Uptime Kuma / Zabbix — wykrywanie incydentu zanim zadzwoni klient (opisane w poprzednich artykułach)
- Arkusz Google lub Notion — log incydentu z timestampami, dostępny dla całego zespołu
- Gotowy szablon raportu — wypełniasz w trakcie, wysyłasz do CSIRT po 72 h
- Kanał na Slacku/Teams „incydenty” — centralne miejsce komunikacji podczas zdarzenia
Jeden błąd, który powtarza się wszędzie
Większość małych firm pisze procedury incydentowe i nigdy ich nie testuje. Ćwiczenie nie musi być skomplikowane — wystarczy raz w roku usiąść na godzinę i przejść scenariusz: „padł główny serwer, co robimy?”. Często okazuje się, że połowa kontaktów w procedurze jest nieaktualna, nikt nie zna hasła do formularza CSIRT i nie wiadomo, kto ma decydować o komunikacji do klientów.
Lepiej odkryć to na ćwiczeniu niż w środku realnego incydentu.
Potrzebujesz gotowych procedur?
Pisanie procedur incydentowych od zera jest żmudne, a zrobione na kolanie — bezużyteczne. W Zjawa.IT przygotowujemy kompletną dokumentację zarządzania incydentami dostosowaną do specyfiki Twojej organizacji — razem z szablonem raportu do CSIRT i scenariuszem ćwiczenia. Jeden dokument, który faktycznie działa.