Czy KSC wymaga własnego SOC i systemu SIEM w firmie

NIS2 i KSC - Wdrożenie: dokumentacja, audyt i zabezpieczenia

Czy KSC wymaga własnego SOC i systemu SIEM w firmie

W skrócie

Zarząd pyta, czy KSC wymaga SOC, gdy oferty integratorów zaczynają się od zakupu systemu SIEM i całodobowego centrum monitorowania. Wyjaśniamy, czego ustawa o KSC wymaga, czego nie wymaga i jak podjąć decyzję o monitorowaniu, która obroni się w nadzorze.

Jak to wygląda w praktyce

Średnia spółka z sektora gospodarowania odpadami, podmiot ważny, ma dwuosobowy dział IT, który pracuje w dni robocze w godzinach 7-15. Na biurko zarządu trafiają trzy oferty: zakup systemu SIEM z wdrożeniem, usługa całodobowego centrum operacji bezpieczeństwa (SOC) od zewnętrznego dostawcy i rozbudowa działu IT o dyżury. Każdy oferent powołuje się na NIS2 i KSC, a koszty roczne wariantów różnią się kilkukrotnie. Prezes pyta, który wariant jest obowiązkowy, a dyrektor finansowy, czy da się obronić najtańszy.

Co mówią przepisy

Ustawa nie nakazuje konkretnego narzędzia ani konkretnej struktury. Ministerstwo Cyfryzacji (MC) na pytanie o SOC odpowiada, że „nie ma narzuconych rozwiązań technicznych czy organizacyjnych”, a podmiot może korzystać z zewnętrznych usług albo budować własne kompetencje, często w ramach grupy kapitałowej (odpowiedź 3.16). Na pytanie o systemy klasy SIEM i SOC dodaje, że ustawa „pozostaje neutralna technologicznie”, a dobór środków zależy od zadań, systemów, skali działalności i wyników szacowania ryzyka (odpowiedź 3.42). Nazw SOC i SIEM nie ma ani w ustawie o KSC, ani w rozporządzeniu wykonawczym Komisji (UE) 2024/2690. W dyrektywie NIS2 centra monitorowania bezpieczeństwa pojawiają się tylko wśród zadań sieci CSIRT, czyli krajowych zespołów reagowania na incydenty bezpieczeństwa komputerowego (art. 15 dyrektywy).

Neutralność nie oznacza braku obowiązków. Ustawa wymaga:

• objęcia systemu informacyjnego wykorzystywanego do świadczenia usługi systemem monitorowania w trybie ciągłym jako elementu systemu zarządzania bezpieczeństwem informacji (SZBI, art. 8 ust. 1 pkt 2 lit. g ustawy o KSC),
• zbierania informacji o cyberzagrożeniach i podatnościach oraz zarządzania incydentami (art. 8 ust. 1 pkt 3 i 4),
• obsługi incydentu, czyli m.in. jego wykrywania, rejestrowania, analizowania i klasyfikowania (art. 2 pkt 10, art. 11 ust. 1 pkt 1), przy której wolno analizować aktywność, w tym ruch sieciowy (art. 3a, odpowiedź MC 6.4),
• wczesnego ostrzeżenia o incydencie poważnym w ciągu 24 godzin i zgłoszenia w ciągu 72 godzin od wykrycia (art. 11 ust. 1 pkt 4 i 4a).

Podmiot ważny będący podmiotem publicznym stosuje zamiast art. 8 ust. 1 wymogi z załącznika nr 4 do ustawy, w którym monitorowanie jest elementem fakultatywnym (art. 8 ust. 3). MC wyjaśnia, że monitorowanie ma zapewnić rozliczalność i możliwość odtworzenia zdarzeń, a „niekoniecznie trzeba w tym celu zatrudniać dodatkową osobę”, bo można użyć narzędzi open source typu SIEM z adekwatnymi regułami (odpowiedź 3.3). W tej samej odpowiedzi podaje przykład braku proporcji: rozbudowany dział z SIEM nie będzie efektywny, gdy zaniedbane jest szkolenie personelu z cyberhigieny. Zadania z art. 8 i 9-13 wykonują wewnętrzne struktury lub dostawca usług zarządzanych w zakresie cyberbezpieczeństwa (MSSP) na podstawie umowy (art. 14). MC dopuszcza zlecenie tylko części zadań, ale przestrzega przed powierzaniem ich np. przeciążonemu działowi pomocy technicznej (odpowiedź 3.19). Umowa z dostawcą, który tylko administruje systemami (art. 2 pkt 4i), nie jest umową z art. 14, bo ten przepis mówi o dostawcy usług zarządzanych w zakresie cyberbezpieczeństwa (art. 2 pkt 4j). Dostawcy usług chmurowych, centrów danych, usług zarządzanych i kilku innych usług cyfrowych stosują dodatkowo szczegółowe wymogi monitorowania i rejestrowania z rozporządzenia 2024/2690 (art. 8b ust. 1 ustawy, pkt 3.2 załącznika do rozporządzenia).

Co zrobić krok po kroku

1. Zakres monitorowania z szacowania ryzyka. Osoba odpowiedzialna za SZBI wskazuje systemy wykorzystywane do świadczenia usługi i zdarzenia do rejestrowania: dostęp do systemów, konta uprzywilejowane, ruch z i do sieci, kopie zapasowe, dzienniki narzędzi ochrony (przykłady z odpowiedzi MC 3.3). Dokument: lista źródeł zdarzeń uzasadniona szacowaniem ryzyka (art. 8 ust. 1 pkt 1).
2. Wymagany czas reakcji. Zarząd ustala, kto przyjmuje alarmy poza godzinami pracy i w weekendy oraz w jakim czasie ocenia, czy incydent jest poważny. Punktem odniesienia są 24 godziny na wczesne ostrzeżenie, liczone od wykrycia (art. 11 ust. 1 pkt 4). Dokument: harmonogram dyżurów i ścieżka eskalacji, spójna z decyzjami zarządu w pierwszych godzinach incydentu.
3. Wybór modelu w uchwale. Kierownik wybiera model: własne narzędzia i zespół, usługa MSSP albo podział zadań, np. monitorowanie u dostawcy, a ocena i zgłoszenia w firmie (art. 14, odpowiedź MC 3.19). Uchwała zapisuje kryteria wyboru, czyli ryzyko, godziny pracy, czas reakcji i koszt, oraz przydziela budżet (art. 8d pkt 1-3).
4. Sprawdzenie dostawcy. Jeśli zadania przejmuje dostawca, koordynator sprawdza, czy świadczy on usługi zarządzane w zakresie cyberbezpieczeństwa (art. 2 pkt 4j), a nie tylko administrowanie, i czy jako podmiot kluczowy publikuje na stronie informacje o obsłudze incydentów (art. 8g, odpowiedź MC 3.13). Dokument: notatka z oceny dostawcy oparta na pytaniach do firmy IT, hostingu i dostawcy chmury.
5. Umowa i Wykaz KSC. Prawnik z koordynatorem wpisują do umowy z MSSP zadania z art. 8 i 11, czas zawiadomienia o incydencie, dane potrzebne do zgłoszeń z art. 12, dostęp firmy do rejestru incydentów i logów oraz plan wyjścia. Informację o umowie i dane dostawcy zgłasza się do Wykazu podmiotów kluczowych i podmiotów ważnych w ciągu 14 dni (art. 7 ust. 2 pkt 16, art. 7c ust. 3).
6. Test i ocena skuteczności. Przed końcem okresu dostosowawczego firma przeprowadza próbę: zdarzenie testowe wykryte w nocy lub w weekend przechodzi przez alarm, ocenę i przygotowanie wczesnego ostrzeżenia. Wyniki i wskaźniki, np. czas od alarmu do decyzji, trafiają do protokołu oceny skuteczności środków (art. 8 ust. 1 pkt 2 lit. h).

Jak sprawdzić, że sprawa jest załatwiona

Decyzja jest gotowa, gdy zarząd potrafi pokazać, dlaczego wybrany wariant jest odpowiedni do ryzyka, a nie tylko, że coś kupiono. Na kontrolę zachowaj uchwałę z wyborem modelu i budżetem, listę monitorowanych systemów i źródeł zdarzeń powiązaną z szacowaniem ryzyka, harmonogram dyżurów, umowę z dostawcą z zakresem zadań i czasem zawiadomienia, potwierdzenie zmiany wpisu w Wykazie KSC, rejestr incydentów oraz protokół z testu. Jeśli monitorowanie prowadzi dostawca, sprawdź, czy umowa pozwala firmie zdążyć ze zgłoszeniem, bo art. 11 ust. 1 nakłada ten obowiązek na podmiot kluczowy lub ważny, a nie na dostawcę. Jak podzielić się zadaniami przy incydencie po stronie dostawcy, opisujemy w poście incydent u dostawcy IT albo w chmurze: kto zgłasza.

Podstawa prawna i źródła

• art. 2 pkt 4i, 4j i 10, art. 3a, art. 8 ust. 1 pkt 2 lit. g, pkt 3 i 4 oraz art. 14 ustawy z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (tekst ujednolicony, stan na 8 października 2026 r.) (źródło)
• art. 7 ust. 2 pkt 16, art. 7c ust. 3, art. 8c ust. 3, art. 8d, art. 8g i art. 11 ust. 1 ustawy o KSC
• art. 8 ust. 3 i załącznik nr 4 pkt II ppkt 5 ustawy o KSC (podmiot ważny będący podmiotem publicznym)
• art. 8b ust. 1 ustawy o KSC oraz pkt 3.2 załącznika do rozporządzenia wykonawczego Komisji (UE) 2024/2690
• Ministerstwo Cyfryzacji, pytania i odpowiedzi do ustawy o KSC, październik 2026, pytania 3.3, 3.13, 3.16, 3.19, 3.42, 6.4 i 11.6 (źródło)

Stan prawny na 13 października 2026 r. Wyjaśnienia Ministerstwa Cyfryzacji nie są źródłem prawa, ale pokazują, jak resort odczytuje przepisy. W sprawach spornych decyzję warto oprzeć na opinii prawnika albo na stanowisku organu właściwego do spraw cyberbezpieczeństwa.

Wróć do listy: 30 najczęstszych pytań i problemów związanych z NIS2 i KSC