Przejdź do treści

Zgłaszanie incydentów NIS2 w 24 i 72 godziny: procedura, odpowiedzialność i ćwiczenie gotowości

11 min czytania Systemy zarządzania

Procedura zgłaszania incydentów w terminach 24 i 72 godzin nie może zaczynać się od formularza ani kończyć na odpowiedzialności działu informatyki. Jej skuteczność zależy od tego, kiedy organizacja uznaje, że uzyskała wiedzę o incydencie, kto kwalifikuje jego wpływ, kto podejmuje decyzję oraz czy zgłoszenie można przygotować i wysłać mimo niepełnych danych, nieobecności kluczowych osób lub awarii podstawowych systemów. Gotowość trzeba zatem zbudować jako proces międzydziałowy, a następnie sprawdzić w ćwiczeniu prowadzonym pod presją czasu.

Dlaczego zegar zaczyna biec wcześniej, niż zakłada zarząd

Biegu terminu nie należy wiązać dopiero z pełnym potwierdzeniem technicznym ani z przekazaniem sprawy osobie upoważnionej do zgłoszenia. Organizacja musi odróżniać zdarzenie, rozumiane jako zaobserwowana anomalia lub ostrzeżenie, od incydentu bezpieczeństwa wpływającego na poufność, integralność, dostępność albo autentyczność zasobów i usług. Kolejny poziom stanowi incydent spełniający kryteria ustawowego zgłoszenia. Nie każdy alarm uruchamia zatem tryb 24- i 72-godzinny, ale każdy sygnał powinien zostać zakwalifikowany według określonych zasad.

Największe ryzyko opóźnienia powstaje wtedy, gdy procedura nie określa momentu uzyskania wiedzy o incydencie. Pierwszą informację może otrzymać serwis, operator linii, administrator, dostawca usług albo dział obsługi klienta. Jeżeli czas jest liczony dopiero od zawiadomienia członka zarządu lub koordynatora bezpieczeństwa, powstaje sztuczna luka między rzeczywistym rozpoznaniem zakłócenia a formalną reakcją. Procedura powinna więc wskazywać źródła zgłoszeń wewnętrznych i zewnętrznych, kryteria eskalacji oraz rolę rozstrzygającą, czy zakłócenie przekroczyło próg zwykłej awarii.

Jeżeli dostawca utrzymujący system produkcyjny informuje serwis o utracie dostępności i podejrzeniu działania zewnętrznego, przyczyna, pełny zakres oraz przewidywany czas przywrócenia pracy mogą pozostawać nieznane. Nie uzasadnia to oczekiwania na końcowy raport techniczny. Do eskalacji wystarczą informacje o czasie ujawnienia sygnału, dotkniętych usługach i lokalizacjach, obserwowanym wpływie, możliwych skutkach oraz podjętych działaniach ograniczających. Na tej podstawie upoważniona osoba dokonuje wstępnej oceny i dokumentuje decyzję o uruchomieniu albo nieuruchomieniu ścieżki zgłoszeniowej.

Etapy 24 i 72 godzin należy traktować jako rozwijanie wiedzy o tym samym incydencie: najpierw przekazuje się wczesne ostrzeżenie na podstawie dostępnych przesłanek, a następnie uzupełnia ocenę o dokładniejsze ustalenia. Nie są to dwa niezależne obowiązki administracyjne. Konkretne terminy, progi kwalifikacji i kanały trzeba każdorazowo potwierdzić w aktualnym prawie krajowym wdrażającym NIS2 oraz wymaganiach właściwego organu, zamiast opierać procedurę wyłącznie na dyrektywie. Skuteczność przyjętych rozwiązań można zweryfikować w ramach Audyt NIS2 w firmie produkcyjnej – jak sprawdzić, czy organizacja jest gotowa na nowe obowiązki.

Gdzie organizacja traci pierwsze godziny

Pierwsze godziny często nie upływają na analizie technicznej, lecz na oczekiwaniu. Zgłoszenie pozostaje w systemie obsługi, poza godzinami pracy nie działa ścieżka kontaktowa, dostawca przygotowuje opinię, działy spierają się o skalę wpływu, a osoba uprawniona do decyzji jest niedostępna. Opóźnienie pogłębia ręczne zbieranie danych z wielu źródeł. Problem powstaje przede wszystkim na styku informatyki, technologii operacyjnej, produkcji, jakości, prawa, komunikacji, ochrony danych, zakupów i zarządu, ponieważ każdy z tych obszarów dysponuje tylko częścią informacji.

Wąskie gardło Skutek Właściciel ryzyka Działanie zapobiegawcze
Zgłoszenie bez automatycznej eskalacji Późne rozpoczęcie kwalifikacji Właściciel procesu obsługi incydentów Progi priorytetu i alarmowanie wskazanych ról
Brak kontaktu poza godzinami pracy Oczekiwanie do kolejnego dnia roboczego Zarząd i kierownictwo operacyjne Dyżury, zastępstwa i okresowe próby łączności
Oczekiwanie na dostawcę Uzależnienie decyzji od raportu zewnętrznego Zakupy i właściciel umowy Umowne czasy powiadomienia, zakres danych i dostępność ekspertów
Spór o wpływ lub brak decydenta Brak formalnego rozstrzygnięcia Upoważniony członek kierownictwa Macierz kwalifikacji, pełnomocnictwa i zastępstwo
Ręczne scalanie informacji Niespójny obraz incydentu Koordynator incydentu Wspólny rejestr czasu, usług, lokalizacji, skutków i działań

W firmie produkcyjnej utrata dostępu do systemu planowania połączona z niestabilnością części urządzeń nie daje od razu pełnego obrazu. Może oznaczać awarię współzależnych systemów, zakłócenie technologii operacyjnej albo incydent o szerszym zasięgu. Organizacja powinna równolegle zabezpieczać operacje i ciągłość produkcji, ustalać dotknięte zasoby i lokalizacje oraz prowadzić eskalację. Ograniczanie skutków technicznych nie może czekać na decyzję formalną, ale również decyzji o zgłoszeniu nie należy odkładać do czasu ustalenia przyczyny lub pełnego usunięcia zakłócenia.

Wąskie gardła najlepiej ujawnia ćwiczenie scenariuszowe obejmujące także wariant nocny i niedostępność kluczowej osoby. Należy mierzyć czas od pierwszego sygnału do eskalacji, kwalifikacji, kontaktu z decydentem i zebrania minimalnego zestawu danych. Trzeba też sprawdzić warunki umów z dostawcami usług teleinformatycznych. Dostawca może wspierać przygotowanie informacji, lecz zgłoszenie w imieniu organizacji wymaga wyraźnej podstawy, właściwego umocowania i zgodności z obowiązującą procedurą. Samo utrzymywanie systemu nie przenosi odpowiedzialności.

Ocena gotowości powinna obejmować całą organizację, nie tylko dział informatyki: role, przepływ informacji, dostawców, technologię operacyjną i zarządzanie kryzysowe. Dowody działania tych mechanizmów powinny być spójne z zakresem opisanym w materiale Dokumentacja NIS2 i KSC przed kontrolą: jakie polityki, rejestry i dowody naprawdę trzeba mieć.

Procedura od sygnału do zgłoszenia

Procedura powinna prowadzić od pierwszego sygnału do udokumentowanej wysyłki bez uzależniania decyzji od zakończenia analizy technicznej. Przepływ obejmuje przyjęcie sygnału, zapis czasu i źródła, wstępną kwalifikację, zabezpieczenie materiału dowodowego oraz ocenę wpływu na usługę. Następnie uruchamia się eskalację, podejmuje decyzję, przygotowuje komunikat, wysyła go właściwym kanałem i zachowuje potwierdzenie. Każdy etap wymaga właściciela, zastępcy, terminu wewnętrznego i określonego zapisu. Terminy wewnętrzne muszą pozostawiać czas na zatwierdzenie oraz obsługę problemów z wysyłką, zamiast pokrywać się z granicą ustawową.

W pierwszym etapie, do 24 godzin, potrzebny jest minimalny pakiet potwierdzonych informacji: identyfikacja podmiotu, czas wykrycia, dotknięta usługa, obserwowane skutki, znany zasięg oraz podjęte działania. Informacje niepewne należy oznaczać jako wstępne, wskazując ich źródło i sposób weryfikacji. Brak wiedzy o przyczynie, pełnym zasięgu albo czasie zakończenia zdarzenia nie powinien prowadzić do tworzenia pozornej kompletności ani automatycznie wstrzymywać komunikatu. Procedura musi określać, kto zatwierdza zgłoszenie, kto działa w zastępstwie oraz jak aktualizuje się przekazane informacje.

Gdy zakład traci dostęp do systemu sterującego realizacją zleceń, koordynator rejestruje alarm, godzinę wykrycia i relacje użytkowników, a zespół techniczny równolegle zabezpiecza dzienniki zdarzeń i ogranicza skutki. Właściciel usługi ocenia wpływ na produkcję, logistykę i odbiorców, natomiast decydent kwalifikuje obowiązek zgłoszenia na podstawie dostępnych danych. Jeżeli incydent trwa, system rejestracyjny jest niedostępny albo źródłem zdarzenia jest dostawca, należy wykorzystać przygotowany kanał zapasowy, nie czekając na raport końcowy. W grupie obejmującej kilka spółek trzeba odrębnie ustalić dotknięte usługi, właściwość podmiotową i umocowanie do działania w imieniu poszczególnych podmiotów.

Do etapu 72 godzin organizacja uzupełnia ocenę charakteru i dotkliwości incydentu, jego wpływu, dostępnych wskaźników naruszenia bezpieczeństwa oraz działań ograniczających skutki — w zakresie wynikającym z aktualnie obowiązujących przepisów i formularzy. Jeżeli późniejsze ustalenia zmienią skalę, przyczynę lub kwalifikację zdarzenia, wcześniejszą informację należy skorygować w sposób kontrolowany, a nie zastępować bez zachowania śladu. Przed wdrożeniem procedury trzeba więc zweryfikować właściwy dla danej kategorii podmiotu organ lub zespół reagowania, kanał zgłoszeniowy, reguły liczenia terminów oraz wymagania dotyczące aktualizacji i dalszego raportowania. Zakres podmiotowy opisuje szerzej NIS2 dla firm produkcyjnych: kogo obejmuje, jakie obowiązki wprowadza i jak przygotować organizację bez sprowadzania tematu wyłącznie do IT.

Podstawą obiegu informacji powinien być jeden rejestr incydentu zawierający oś czasu, kolejne wersje ustaleń, źródła danych, decyzje wraz z uzasadnieniem, treść komunikatów i potwierdzenia wysyłki. Poczta elektroniczna oraz komunikatory mogą służyć do alarmowania, lecz nie powinny tworzyć równoległych wersji opisu zdarzenia. Gotowość procesu należy mierzyć czasem od sygnału do rejestracji, eskalacji, decyzji i wysyłki, udziałem wpisów z oznaczonym źródłem oraz możliwością odtworzenia, kto i na jakiej podstawie zmienił ocenę incydentu.

Role, zastępstwa i próg decyzji

Proces zgłoszeniowy wymaga rozdzielenia czynności, odpowiedzialności i uprawnień. Osoba wykrywająca zdarzenie rejestruje je i uruchamia eskalację. Koordynator incydentu prowadzi oś czasu i obieg informacji, a ekspert techniczny ocenia charakter zdarzenia oraz zabezpiecza dane. Właściciel usługi lub procesu określa wpływ operacyjny, osoba posiadająca kompetencje prawne ocenia obowiązek informacyjny, zatwierdzający podejmuje decyzję o zgłoszeniu, natomiast upoważniony pracownik dokonuje wysyłki i zachowuje jej dowód. Jedna osoba może łączyć kilka ról, o ile nie zaciera to uprawnienia do decyzji i nie tworzy pojedynczego punktu zależności.

Macierz odpowiedzialności jest użyteczna dopiero wtedy, gdy poza nazwą stanowiska wskazuje zakres zadania, wymagany czas reakcji, uprawnienie decyzyjne, zastępcę i oczekiwany dowód wykonania. Powinna również określać, kto może zdecydować przy niepełnych danych oraz jak rozstrzyga się konflikt między ciągłością produkcji, bezpieczeństwem i obowiązkiem informacyjnym. Kierownictwo zatwierdza model reagowania, progi eskalacji i dostępne zasoby. Nie może przenieść całego ryzyka decyzyjnego na administratora systemów ani pełnomocnika jakości, którzy zwykle nie mają mandatu do rozstrzygania skutków biznesowych i prawnych.

Nie każde zgłoszenie musi zatwierdzać członek zarządu, jeżeli wewnętrzny model kompetencji przewiduje odpowiednie pełnomocnictwo lub upoważnienie, zgodne z wymaganiami właściwymi dla danego podmiotu i kanału zgłoszeniowego. Zastępstwo wymaga imiennego wskazania kolejnej osoby, całodobowych danych kontaktowych oraz reguły przejęcia sprawy po bezskutecznym upływie ustalonego czasu. Zastępca musi mieć rzeczywisty dostęp do rejestru, formularza, skrzynki, wymaganych podpisów elektronicznych i kanału zapasowego. Sam zapis w procedurze, bez nadania uprawnień, nie zapewnia ciągłości działania.

Jeżeli incydent wystąpi w nocy, koordynator nie powinien oczekiwać bezterminowo na osobę zatwierdzającą. Po upływie wewnętrznego limitu kontaktuje się z jej zastępcą, a następnie z osobą uprawnioną do decyzji awaryjnej. Terminy wewnętrzne należy ustalić wyraźnie krócej niż terminy zewnętrzne, pozostawiając rezerwę na sprawdzenie danych, kwalifikację prawną, zatwierdzenie, trudności techniczne i udokumentowanie wysyłki. Czasy od wykrycia do eskalacji, decyzji i przekazania zgłoszenia trzeba mierzyć podczas ćwiczeń.

Model ten wymaga finansowania dyżurów, dostępów, szkoleń i narzędzi, dlatego powinien zostać uwzględniony w planowaniu opisanym w materiale Ile kosztuje wdrożenie NIS2 i uKSC – jak zbudować budżet audytu, dokumentacji, szkoleń i zabezpieczeń bez kosztownych pomyłek. Pozostawienie jednego decydenta lub jednego posiadacza uprawnień jest oszczędnością pozorną: podczas incydentu nieobecność organizacyjna staje się przyczyną formalnego opóźnienia.

Ćwiczenie, które ujawnia prawdziwą gotowość

Gotowości do zgłoszenia incydentu nie potwierdza znajomość procedury, lecz zdolność wykonania jej pod presją czasu i przy niepełnych danych. Scenariusz ćwiczenia powinien opierać się na stopniowym ujawnianiu informacji. Początkowy sygnał może być niejednoznaczny, część systemów i dokumentacji niedostępna, dostawca może odpowiadać z opóźnieniem, a wpływ operacyjny narastać wraz z kolejnymi komunikatami. Taka konstrukcja pokazuje, czy organizacja potrafi rozpocząć eskalację bez oczekiwania na pełną analizę techniczną.

Ćwiczenie należy prowadzić na realistycznej osi czasu, rejestrując moment odebrania i zapisania sygnału, przekazania go koordynatorowi, zwołania zespołu, wstępnej kwalifikacji, przygotowania treści, jej zatwierdzenia oraz próby wysłania. Próba nie powinna skutkować rzeczywistym zgłoszeniem, chyba że wcześniej uzgodniono bezpieczne środowisko testowe i sposób oznaczenia danych. Udział podmiotów zewnętrznych wymaga odrębnej decyzji. Dostawcę warto włączyć, gdy jego informacja, dostęp lub działanie są niezbędne do kwalifikacji incydentu. Zarząd powinien uczestniczyć przynajmniej w wariancie wymagającym decyzji biznesowej, akceptacji ryzyka albo uruchomienia zastępstwa.

Przykładowy przebieg może rozpocząć się od zgłoszenia spowolnienia systemu produkcyjnego. Następnie prowadzący ujawnia brak dostępu do rejestru zdarzeń, niedostępność osoby zatwierdzającej, niespójne dane o liczbie dotkniętych procesów oraz brak odpowiedzi dostawcy. Obserwatorzy nie podpowiadają zespołowi, lecz zapisują rzeczywiste czasy i dowody. Oceniają czas dotarcia sygnału do koordynatora, dostępność zastępców, liczbę niewyjaśnionych odpowiedzialności, kompletność osi czasu, rozbieżności między źródłami oraz możliwość użycia kanału zapasowego. Odnotowują także role bez zastępcy, brakujące uprawnienia i nieaktualne dane kontaktowe.

Ocena nie może ograniczać się do stwierdzenia, czy próbne zgłoszenie przygotowano przed terminem wewnętrznym. Trzeba sprawdzić, czy uczestnicy:

  • oddzielali potwierdzone fakty od założeń,
  • wskazywali źródła informacji,
  • dokumentowali podstawę kwalifikacji,
  • oznaczali dane wymagające późniejszego uzupełnienia,
  • uruchamiali zastępstwa zgodnie z przyjętymi zasadami,
  • potrafili użyć zapasowego kanału zgłoszeniowego.

Istotnym wynikiem jest również sposób działania w warunkach niepewności. Zespół nie powinien ani automatycznie kwalifikować każdego zakłócenia jako incydentu podlegającego zgłoszeniu, ani wstrzymywać eskalacji do czasu zakończenia pełnej analizy technicznej.

Ćwiczenie kończy się planem działań korygujących, nie samym protokołem. Każda luka wymaga właściciela, terminu usunięcia, mierzalnego kryterium skuteczności oraz wskazania elementu podlegającego ponownej próbie. Należy monitorować udział działań zamkniętych i skutecznie zweryfikowanych w terminie przyjętym przez organizację. Częstotliwość kolejnych ćwiczeń oraz zmianę scenariusza ustala się na podstawie ryzyka, wyników poprzedniej próby i zmian organizacyjnych. Dodatkową próbę uzasadniają zwłaszcza nowe role, dostawcy, systemy, kanały zgłoszeniowe lub istotne braki. Ustalenia te powinny być spójne z harmonogramem opisanym jako Wdrożenie NIS2 po wpisie do wykazu KSC – plan działań do 3 kwietnia 2027 roku.

Minimalny standard gotowości zarządczej

Zarząd może uznać proces zgłaszania incydentów za działający dopiero po zatwierdzeniu jego kompletnego układu organizacyjnego. Obejmuje on procedurę, kryteria eskalacji, aktualną listę kontaktową, przypisane role i zastępstwa, dostęp do podstawowego i zapasowego kanału zgłoszeniowego, wzory komunikatów, jeden rejestr incydentu, zasady zabezpieczania i przechowywania dowodów oraz przeprowadzone ćwiczenie. Brak któregokolwiek z tych elementów należy ocenić jako ryzyko operacyjne, a nie redakcyjną lukę w dokumentacji.

Dowodem gotowości nie jest liczba zatwierdzonych dokumentów, lecz spójny ślad postępowania: od wykrycia zdarzenia, przez kwalifikację i decyzję, do przygotowania oraz wysłania zgłoszenia. Powinien on wskazywać czasy, źródła informacji, osoby podejmujące decyzje, podstawę kwalifikacji i treść przekazaną właściwemu podmiotowi. Organizacja musi również wykazać, że potrafi działać podczas nieobecności kluczowych osób, awarii podstawowych systemów i ograniczonego dostępu do danych.

Po ćwiczeniu potrzebny jest przegląd zarządczy, który przekształca ustalenia w decyzje przed audytem lub kontrolą. Właściciel procesu może poprawić instrukcję, rejestr albo listę kontaktową w granicach swoich uprawnień. Zarząd powinien natomiast rozstrzygnąć braki wymagające akceptacji ryzyka resztkowego, finansowania zmian, dodatkowych zasobów lub zmiany odpowiedzialności. Każde działanie wymaga właściciela, terminu i daty ponownej weryfikacji skuteczności.

Zgłaszanie incydentów należy osadzić w szerszym planie wdrożenia, każdorazowo sprawdzając aktualność terminów i wymagań. Przy ocenie dojrzałości warto również uwzględnić zagadnienie NIS2 a ISO 27001: co daje certyfikat, a czego nadal brakuje do zgodności z KSC. Organizacja jest gotowa dopiero wtedy, gdy potrafi podjąć, wykonać i udowodnić właściwą decyzję w ograniczonym czasie oraz przy niepełnej informacji.

Rate this post

Najczęstsze pytania

Od kiedy należy liczyć terminy 24 i 72 godzin na zgłoszenie incydentu?

Terminy należy wiązać z momentem uzyskania przez organizację wiedzy o incydencie, a nie dopiero z pełnym potwierdzeniem technicznym lub poinformowaniem zarządu. Procedura powinna określać, jakie sygnały świadczą o uzyskaniu wiedzy, kto zapisuje czas ich odbioru i kto dokonuje kwalifikacji. Szczegółowe zasady liczenia terminów trzeba potwierdzić w aktualnych przepisach krajowych wdrażających NIS2.

Czy zgłoszenie można wysłać, gdy przyczyna i pełny zasięg incydentu nie są jeszcze znane?

Tak. Wczesne ostrzeżenie powinno opierać się na dostępnych, potwierdzonych informacjach, takich jak czas wykrycia, dotknięte usługi, obserwowane skutki, znany zasięg i podjęte działania ograniczające. Dane niepewne należy oznaczyć jako wstępne, podać ich źródło i później uzupełnić lub skorygować z zachowaniem historii zmian.

Kto odpowiada za kwalifikację i zgłoszenie incydentu NIS2?

Odpowiedzialność powinna być rozdzielona między kilka ról. Osoba wykrywająca rejestruje sygnał, koordynator prowadzi oś czasu, eksperci oceniają techniczny i operacyjny wpływ, funkcja prawna analizuje obowiązek informacyjny, upoważniony decydent zatwierdza zgłoszenie, a wyznaczona osoba je wysyła i zachowuje potwierdzenie. Dla każdej roli trzeba wskazać zastępcę, czas reakcji i wymagane uprawnienia.

Czy dostawca usług IT może zgłosić incydent w imieniu organizacji?

Może to zrobić tylko wtedy, gdy ma wyraźne umocowanie, dostęp do właściwego kanału oraz działa zgodnie z procedurą i wymaganiami właściwego organu. Samo utrzymywanie systemu nie przenosi odpowiedzialności za terminową kwalifikację i zgłoszenie. Umowa powinna określać czas powiadomienia, minimalny zakres przekazywanych danych i dostępność ekspertów.

Jak sprawdzić gotowość organizacji do zgłoszenia incydentu w wymaganym czasie?

Należy przeprowadzić ćwiczenie scenariuszowe z niepełnymi danymi, niedostępnością decydenta, opóźnieniem dostawcy oraz awarią podstawowego kanału. Trzeba mierzyć czas od pierwszego sygnału do rejestracji, eskalacji, decyzji, przygotowania komunikatu i próby wysyłki. Wynikiem powinien być plan działań korygujących z właścicielami, terminami i ponowną weryfikacją skuteczności.

Udostępnij:
Ekspert BBQuality

Masz pytania? Porozmawiajmy.

Bezpłatna konsultacja – bez zobowiązań.

Umów konsultację