Obsługa incydentów NIS2: dlaczego artykuł 21(2)(b) oblewa więcej audytów niż artykuł 23

Analityczka bezpieczeństwa w holenderskim managed service providerze widzi nietypowy ruch wychodzący z serwera plików klienta o 02:14 w sobotę. Zakłada zgłoszenie, oznacza je jako "do sprawdzenia" i wraca do kolejki. Opiekun klienta czyta je w poniedziałek o 09:30, dzwoni do klienta i wreszcie ktoś zadaje pytanie, które ma znaczenie: czy to podlega zgłoszeniu?

W tym momencie 24-godzinne okno na wczesne ostrzeżenie zamknęło się 31 godzin wcześniej.

To nie jest błąd zgłaszania incydentów. To błąd obsługi incydentów według NIS2 — artykuł 21(2)(b) — i jest to środek, który po cichu decyduje, czy jakikolwiek inny termin z dyrektywy jest w ogóle osiągalny.

Artykuł 23 przyciąga uwagę. Artykuł 21(2)(b) decyduje, czy go dotrzymasz

Większość rozmów o zgodności zaczyna się od zegara zgłoszeń: 24 godziny, 72 godziny, miesiąc. Te terminy pochodzą z artykułu 23. Są widoczne, policzalne i łatwo je umieścić na slajdzie.

Artykuł 21(2)(b) to środek leżący pod nimi. Wymaga obsługi incydentów — udokumentowanego i przećwiczonego procesu wykrywania, analizy, ograniczania, reagowania i przywracania.

Zależność działa w jedną stronę. Nie zgłosisz incydentu, którego nie sklasyfikowałeś. Nie sklasyfikujesz incydentu, którego nikt nie eskalował. I nie wyeskalujesz incydentu, który przez cały weekend leży w kolejce zgłoszeń z etykietą "do sprawdzenia".

Gdy organ nadzoru stwierdzi przekroczenie 24-godzinnego terminu, nie zatrzymuje się na terminie. Pyta, w jaki sposób podmiot powziął wiedzę, kto podjął decyzję i według jakich kryteriów. Ta linia pytań trafia wprost w artykuł 21(2)(b) — i zwykle nie znajduje tam niczego na piśmie.

Czego naprawdę wymaga wiążący tekst

Artykuł 21(2)(b) dyrektywy to jedna linijka. Szczegóły są w rozporządzeniu wykonawczym Komisji (UE) 2024/2690, które obowiązuje bezpośrednio we wszystkich 27 państwach członkowskich, bez transpozycji krajowej.

CIR wiąże konkretną listę typów podmiotów: dostawców usług DNS, rejestry nazw domen najwyższego poziomu, dostawców usług chmury obliczeniowej, dostawców usług zarządzanych ICT i zarządzanych usług bezpieczeństwa, internetowe platformy handlowe, wyszukiwarki internetowe, platformy sieci społecznościowych oraz dostawców usług zaufania. Jeśli prowadzisz MSP lub MSSP, jesteś na tej liście — nie jako dostawca, lecz jako podmiot regulowany we własnym prawie. Ten podwójny obowiązek omówiliśmy w NIS2 dla MSP i MSSP.

Dla wszystkich pozostałych — energetyka, ochrona zdrowia, transport, produkcja, administracja publiczna — CIR nie jest formalnie wiążący, ale jest najbardziej autorytatywnym dostępnym opisem tego, co znaczy "odpowiedni i proporcjonalny". Załóż, że twój regulator odczyta go właśnie tak, bo nie ma nic lepszego.

Punkt 3 załącznika do CIR dotyczy obsługi incydentów. Wymaga polityki i procedur wykrywania, analizy, ograniczania, reagowania i przywracania; zdefiniowanych ról i odpowiedzialności; logowania; ścieżek eskalacji i komunikacji; oraz ustrukturyzowanego przeglądu poincydentalnego, który zwraca wnioski do pozostałych środków.

To właśnie ten ostatni element zespoły pomijają. Obsługa incydentów nie jest pętlą, która kończy się w chwili przywrócenia systemu. Jest wejściem do analizy ryzyka, programu szkoleń i oceny skuteczności z artykułu 21(2)(f).

Próg istotności to mechanizm kontrolny, a nie kwestia wyczucia

CIR nie zostawia słowa "istotny" interpretacji. Artykuł 3 określa kryteria: incydent jest istotny, jeżeli powoduje bezpośrednią stratę finansową przekraczającą 500 000 EUR lub 5 % rocznego obrotu, prowadzi do eksfiltracji tajemnic przedsiębiorstwa albo powoduje śmierć lub znaczną szkodę na zdrowiu.

Artykuł 4 dodaje regułę, którą większość procesów całkowicie pomija: powtarzające się incydenty, które pojedynczo nie przekraczają progu, mogą zostać zagregowane i potraktowane jako jeden istotny incydent, jeżeli łącznie spełniają kryteria w okresie sześciu miesięcy. Pięć drobnych zdarzeń credential stuffing w bazie klientów to nie pięć nie-zdarzeń. To może być jeden podlegający zgłoszeniu incydent — i nikt tego nie zauważy, jeśli nikt nie śledzi sumy.

Artykuł 5 zaostrza to jeszcze dla dostawców DNS i rejestrów TLD: dostępność poniżej 99,9 % przez dowolny okres wystarczy sama w sobie.

Praktyczna konsekwencja dla konsultantów: kryteria klasyfikacji u klienta muszą być spisane przed incydentem, odwzorowane na te progi i przypisane do nazwanej roli. Analityczka o 02:14 w sobotę nie powinna wymyślać testu istotności. Powinna go stosować.

Zegar biegnie od powzięcia wiedzy, nie od uzgodnienia

Artykuł 23(3) uruchamia 24-godzinne okno w momencie, gdy podmiot poweźmie wiedzę o istotnym incydencie. Nie wtedy, gdy zarząd zgodzi się, że jest istotny. Nie wtedy, gdy aktywowana zostaje umowa incident response. Nie w poniedziałek.

To rozróżnienie jest źródłem większości przekroczonych terminów. Organizacja miała informację w sobotę, a decyzję w poniedziałek, i traktuje tę lukę jako proces wewnętrzny. Regulator traktuje ją jako 31 godzin opóźnienia.

Zbuduj proces od terminu wstecz. Jeśli wczesne ostrzeżenie jest wymagane w 24 godziny, eskalacja do decydenta musi zająć godziny, co oznacza, że wykrywanie musi generować sklasyfikowany alert, co oznacza, że poza godzinami pracy ktoś musi być osiągalny i mieć uprawnienia do decyzji. Każdy z tych punktów to decyzja projektowa, którą podejmujesz teraz albo odkrywasz w trakcie incydentu.

Pełną sekwencję — wczesne ostrzeżenie po 24 godzinach, zgłoszenie po 72 godzinach, raport końcowy po miesiącu — opisaliśmy w przewodniku po terminach zgłaszania, a oficjalne formularze zgłoszeniowe pokazują dokładnie, jakie pola trzeba wypełnić pod presją czasu.

Pięć miejsc, w których obsługa incydentów pęka w realnym środowisku klienta

Wykrywanie produkuje alerty, a nie incydenty. SIEM generujący 400 alertów dziennie to nie jest wykrywanie incydentów. Wykrywanie w rozumieniu punktu 3 załącznika oznacza triaż alertów w zdefiniowanym modelu istotności, z właścicielem i czasem reakcji.

Eskalacja zależy od jednej osoby. Proces działa, bo Marco wie, co robić. Marco jest na urlopie. Udokumentuj rolę, nie osobę, i wyznacz zastępcę.

Dostępność poza godzinami pracy jest założona, a nie umówiona. Zadaj pytanie wprost: kto między piątkiem 18:00 a poniedziałkiem 08:00 ma uprawnienie do uznania incydentu za istotny? Jeśli odpowiedź wymaga spotkania, odpowiedź brzmi: nikt.

Zależności od stron trzecich są poza procesem. Incydent klienta może zacząć się u jego dostawcy chmury albo u ciebie. Obowiązki z artykułu 21 nie wędrują razem z obciążeniem. Umowne obowiązki notyfikacyjne wobec dostawców należą do planu — zobacz umowy z dostawcami a NIS2.

Przegląd poincydentalny to rozmowa, a nie zapis. Rozmowa nie jest dowodem. CIR oczekuje ustrukturyzowanego przeglądu z ustaleniami, właścicielami i wprowadzonymi zmianami. Nie ma dokumentu, nie ma środka.

Nadzór eskaluje, gdy brakuje obsługi incydentów

Podmioty kluczowe podlegają nadzorowi ex ante — organy mogą prowadzić audyty proaktywnie, bez czekania na incydent. Podmioty ważne podlegają nadzorowi ex post, uruchamianemu przez incydent lub wiarygodne informacje o niezgodności.

Obie drogi kończą się w tym samym miejscu, jeśli obsługa incydentów nie istnieje. Organy mogą wydawać wiążące polecenia, nakazywać konkretne działania naprawcze, żądać powiadomienia dotkniętych klientów, publikować informację o niezgodności i nakładać kary administracyjne. Dla podmiotów kluczowych pułap wynosi 10 mln EUR albo 2 % światowego rocznego obrotu, w zależności od tego, która kwota jest wyższa. Konsekwencje niefinansowe bywają dotkliwsze — omówiliśmy je w 7 sankcjach NIS2 gorszych niż pieniądze.

W 2026 roku przestało to być teorią. Transpozycja w państwach członkowskich jest w dużej mierze zakończona, holenderska Cyberbeveiligingswet weszła w życie 15 sierpnia 2026 r., a w lipcu Komisja skierowała Irlandię, Hiszpanię, Francję i Holandię do Trybunału Sprawiedliwości za niepełną transpozycję. Organy nadzoru prowadzą kontrole w oparciu o prawo krajowe, które już obowiązuje.

Dowody potwierdzające, że proces istnieje

Audytor nie ocenia twoich intencji. Ocenia to, co potrafisz przedstawić. Dla artykułu 21(2)(b) w dokumentacji powinny znaleźć się:

• Polityka obsługi incydentów zatwierdzona przez kierownictwo, z datą przeglądu z ostatnich 12 miesięcy
• Spisane kryteria klasyfikacji odwzorowane na progi z artykułu 3 CIR
• Nazwana ścieżka eskalacji z zastępcami i kontaktem poza godzinami pracy
• Zgłoszenia incydentów z czasem wykrycia, czasem klasyfikacji i czasem decyzji jako oddzielnymi znacznikami czasu
• Co najmniej jedno ćwiczenie lub tabletop z ostatniego roku wraz z wypracowanymi ustaleniami
• Przeglądy poincydentalne z przypisanymi właścicielami i dowodem zamknięcia działań
• Konfiguracja i retencja logów pozwalająca odtworzyć oś czasu po fakcie

Ten ostatni punkt waży więcej, niż się wydaje. Jeśli retencja wynosi 30 dni, a raport końcowy składasz po miesiącu, możesz opisywać zdarzenia, których nie da się już udowodnić.

Zacznij od znaczników czasu. Wyciągnij pięć ostatnich incydentów z dowolnego środowiska klienta i sprawdź, czy wykrycie, klasyfikacja i decyzja są rejestrowane osobno. Jeśli nie, 24-godzinne okno pozostaje nieprzetestowane — a dowiesz się, ile naprawdę trwa, dopiero przy incydencie, który się liczy.

Jeśli chcesz ustrukturyzowany obraz sytuacji klienta we wszystkich dziesięciu środkach z artykułu 21, zanim zobowiążesz się do planu naprawczego, wykonaj bezpłatny quick scan NIS2. Zajmuje kilka minut i daje możliwy do obrony punkt wyjścia do rozmowy.

Obsługa incydentów to środek, który zamienia każdy inny mechanizm kontrolny w reakcję. Ustaw dobrze proces, kryteria i zegar, a artykuł 23 stanie się formalnością administracyjną. Zrób to źle, a żadne narzędzie nie dotrzyma terminu.