NIS2 i KSC
Sześciu na ośmiu operatorów ignorowało alerty bezpieczeństwa. Czy Twoja firma by je zauważyła?
Najwyższa Izba Kontroli opublikowała 27 sierpnia 2026 r. raport ze sprawdzenia ośmiu operatorów usług kluczowych z sektora energetyki, wody i transportu. W sześciu z nich systemy bezpieczeństwa generowały alerty, których nikt nie sprawdzał. Znowelizowana ustawa o krajowym systemie cyberbezpieczeństwa (UKSC) odpowiada na ten problem wprost: kierownik podmiotu kluczowego lub ważnego ponosi odpowiedzialność za wykonywanie obowiązków w zakresie cyberbezpieczeństwa, a także podejmuje decyzje i sprawuje nadzór nad systemem zarządzania bezpieczeństwem informacji. Co ważne: dziś tej odpowiedzialności lepiej nie sprowadzać wyłącznie do podpisania polityki bezpieczeństwa, bo kary są zbyt dotkliwe.
Co dokładnie wykazała kontrola NIK
Kontrola objęła ośmiu operatorów usług kluczowych działających w energetyce, dostawach wody pitnej oraz transporcie kolejowym i wodnym. NIK ustaliła, że żaden z nich w okresie 1 stycznia 2021 – 16 lutego 2026 nie zapewnił monitorowania w systemach służących do świadczenia usługi kluczowej oraz wskazała brak odporności na działania naruszające poufność, integralność, dostępność i autentyczność przetwarzanych danych. Sześciu operatorów systematycznie pomijało krytyczne alerty generowane przez własne systemy monitorujące, a w skrajnych przypadkach nie prowadziło monitoringu wcale. NIK ustaliła też, że nadzorujący te sektory ministrowie wiedzieli o brakach, ale nie podjęli odpowiednich działań kontrolnych.
Źródło danych: Najwyższa Izba Kontroli, wyniki kontroli "Cyberbezpieczeństwo usług kluczowych", sierpień 2026.
Skala problemu w liczbach
W 2025 r. krajowe CSIRT obsłużyły 272 941 incydentów - o 144,4% więcej niż rok wcześniej. Średnio oznaczało to jeden obsłużony incydent mniej więcej co dwie minuty.
Alert bezpieczeństwa to jeszcze nie incydent. Ale brak reakcji może stworzyć incydent.
Dlaczego sam system monitorujący nie wystarczy?
System monitorujący, którego alerty nikt nie analizuje, daje złudne poczucie bezpieczeństwa. Sześciu skontrolowanych operatorów taki system miało i mimo to nie wiedziało, co dzieje się w ich systemach IT. To pokazuje tylko jedno: nawet najbardziej zaawansowane narzędzie bez jasno określonej procedury reagowania jest jedynie kosztem, a nie realnym zabezpieczeniem minimalizującym ryzyka. Brak reakcji na alerty zwiększa ryzyko, że rzeczywiste zagrożenie nie zostanie wykryte lub obsłużone na czas. W zależności od charakteru naruszenia może to oznaczać m.in. wyższe prawdopodobieństwo przerwy w dostawach energii/wody, ale także konsekwencje regulacyjne, straty wizerunkowe, a w określonych sytuacjach również ryzyko odpowiedzialności odszkodowawczej.
Co z tego wynika na gruncie UKSC dla kierownika podmiotu
NIK wskazała gdzie brakuje procedur reagowania. Ustawa określa obecnie jasno, kto ponosi za to odpowiedzialność. Zgodnie z art. 8d UKSC kierownik podmiotu podejmuje decyzje dotyczące przygotowania, wdrażania, stosowania, przeglądu i nadzoru nad systemem zarządzania bezpieczeństwem informacji oraz przydziela zadania z zakresu cyberbezpieczeństwa i nadzoruje ich wykonanie. Art. 8c doprecyzowuje, że powierzenie zadań działowi IT lub zewnętrznej firmie nie zwalnia go z tej odpowiedzialności.
Warto podkreślić, że nie chodzi o to, żeby teraz członek zarządu wziął na siebie rolę administratora bezpieczeństwa. Natomiast byłoby wskazane, żeby przykładowo potrafił ocenić, czy organizacja ma wdrożone mechanizmy pozwalające wykrywać, obsługiwać i zgłaszać incydenty. Zarząd powinien umieć odpowiedzieć na pięć pytań:
- Kto odpowiada za monitoring?
- Jakie zdarzenia są uznawane za krytyczne?
- Kto otrzymuje krytyczny alert?
- W jakim czasie musi nastąpić reakcja?
- Skąd zarząd wie, że procedura faktycznie działa?
Jeśli w organizacji nikt nie ma jasno przypisanej odpowiedzialności za monitoring, problem nie znika. Przeciwnie - trudniej wykazać, kto ma zareagować, w jakim czasie i kto nadzoruje wykonanie tego zadania. Sam fakt, że system technicznie działa i generuje alerty, nie oznacza więc, że organizacja realizuje skuteczny proces monitorowania i reagowania.
Moja wskazówka
Ustawa nie wymaga od prezesa całodobowego monitorowania infrastruktury IT. Wymaga nadzoru i udokumentowania. Trzy zadania na dobry początek:
- Umów spotkanie z IT w temacie monitorowania alertów bezpieczeństwa - poproś o raport za ostatni kwartał i omówienie sposobów postępowania z incydentami na konkretnych przykładach. Zapytaj jakie zmiany w obszarze IT wymusiły wykryte incydenty. Nie pytaj jedynie ile alertów wykryto. Zapytaj raczej ile z nich zostało przeanalizowanych, ile eskalowano i ile zakończyło się udokumentowaną reakcją.
- Zaplanuj czas na szkolenie w tematyce cyberbezpieczeństwa - to nie tylko pomoże Ci zadawać trafniejsze pytania i rozumieć pełniej tę skomplikowaną materię, ale dodatkowo będzie realizacją ustawowego obowiązku nałożonego na kierownika podmiotu w zakresie corocznego uczestniczenia w szkoleniu z cyberbezpieczeństwa.
- Zweryfikuj czy procedura wykrywania, reagowania i zgłaszania incydentów naprawdę działa, kto odpowiada za klasyfikację incydentów i według jakich kryteriów, kto jest powiadamiany, jak są obsługiwane i w jakim czasie. Zapytaj o kluczowe systemy IT i w jakim trybie są monitorowane i przez kogo.
Więcej na ten temat
Więcej o obowiązkach kierownika podmiotu na gruncie UKSC, wraz z praktyczną listą kroków do wykonania przed 3 października 2026, przeczytasz w moim artykule dla magazynu Rynek Inwestycji:
"Ignorowanie cyberbezpieczeństwa się nie opłaca. Co NIS2 oznacza dla kierownika jednostki?"Najczęstsze pytania
O autorce
Renata Cybula-Szwajkowska — radczyni prawna specjalizująca się m.in. w cyberbezpieczeństwie i ciągłości działania. Wspiera zarządy we wdrożeniu wymagań NIS2/KSC, RODO i AI Act. Odpowiadała operacyjnie za obszar zarządzania bezpieczeństwem i ciągłością działania w spółce o znaczeniu strategicznym dla polskiej gospodarki.
więcej o mnie →