Czy podmiot kluczowy lub ważny potrzebuje SOC-u? Informatyk, własny zespół czy usługa i ile to kosztuje

Ustawa o KSC wymaga monitorowania w trybie ciągłym, ale nie wymaga SOC-u. Kiedy wystarczy informatyk z Wazuhem, kiedy usługa zewnętrzna i co da AI.

Autor: Paweł Rosół
Data: 30.10.2026
Czytanie: 13 min
Kategoria: Zarządzanie ryzykiem

Stan prawny sprawdzony: 24.10.2026

Spis treści

Czym jest SOC?
Co mówi ustawa o KSC?
Po co SOC, skoro ustawa go nie wymaga?
Czy wystarczy jeden informatyk?
Darmowe narzędzia na początek: Zabbix i Wazuh
Kiedy warto rozważyć usługę zewnętrzną?
Ile to kosztuje?
Co zmienia AI?
Własne narzędzia zamiast gotowego produktu
Od czego zacząć?

Nie, ustawa o KSCUstawa o KSC Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa. Po nowelizacji z 2026 r. wdraża dyrektywę NIS2 i określa obowiązki podmiotów kluczowych i ważnych. nie wymaga SOC-uCentrum operacji bezpieczeństwa Zespół lub usługa, która całą dobę monitoruje systemy firmy, wykrywa podejrzane zdarzenia i uruchamia reakcję na incydent.. Wymaga, żeby system informacyjny, od którego zależy usługa, był objęty monitorowaniem w trybie ciągłym, a sposób zostawia podmiotowi. Ministerstwo Cyfryzacji odpowiada na pytanie „Czy muszę mieć Security Operations Center (SOC)?” wprost: nie ma narzuconych rozwiązań technicznych ani organizacyjnych. Kierownik podmiotuKierownik podmiotu Osoba albo organ kierujący podmiotem kluczowym lub ważnym, na przykład zarząd spółki. Odpowiada za cyberbezpieczeństwo podmiotu także wtedy, gdy zadania powierzył innej osobie. musi więc sam zdecydować, czy wystarczy mu informatyk z dobrze ustawionymi narzędziami, czy potrzebuje zespołu albo usługi zewnętrznej. Ten tekst ma mu w tej decyzji pomóc i pokazać, ile każda z dróg kosztuje.

Czym jest SOC?

SOC (security operations center, po polsku centrum operacji bezpieczeństwa) to zespół ludzi z narzędziami, który na bieżąco obserwuje systemy firmy, wychwytuje nietypowe zdarzenia i uruchamia reakcję, zanim drobny sygnał zamieni się w incydent. Brytyjskie NCSC opisuje jego zadanie tak: ograniczać szkody, wykrywając ataki, które przeszły przez zabezpieczenia zapobiegawcze, i reagując na nie. Dodaje, że SOC może też zajmować się oceną podatnościPodatność Słabość produktu lub usługi ICT, którą można wykorzystać do ataku. Znane podatności dostają identyfikatory CVE, a te wykorzystywane w atakach trafiają do katalogu KEV., zgodnością i konfiguracją systemów.

W praktyce na SOC składają się trzy rzeczy. Pierwsza to źródła danych: logi serwerów, stacji roboczych, zapór, poczty, systemów chmurowych i aplikacji, od których zależy usługa. Druga to narzędzie, które je zbiera i koreluje, najczęściej system SIEMSystem SIEM Security Information and Event Management: system, który zbiera w jednym miejscu logi z wielu systemów i urządzeń, żeby można je było analizować i wykrywać w nich ślady incydentów., często z agentami EDRSystem EDR Endpoint Detection and Response: oprogramowanie na serwerach i komputerach, które stale obserwuje, co się na nich dzieje, wykrywa podejrzane działania i pozwala na nie zareagować, na przykład odciąć komputer od sieci. na komputerach. Trzecia, najdroższa, to ludzie, którzy patrzą na alarmy, odsiewają fałszywe, badają prawdziwe i wiedzą, kogo obudzić.

Do tego dochodzi praca, której nie widać na pulpicie z alarmami: śledzenie biuletynów producentów sprzętu i oprogramowania, którego firma używa, komunikatów CSIRTCSIRT Zespół reagowania na incydenty bezpieczeństwa komputerowego. Na poziomie krajowym działają trzy: CSIRT GOV (Szef ABW), CSIRT MON (Minister Obrony Narodowej) i CSIRT NASK (NASK-PIB). i nowych podatności, a potem pilnowanie, żeby poprawka trafiła tam, gdzie trzeba. W wielu firmach to robi dział IT, a SOC tylko podsyła ostrzeżenia, i taki podział jest w porządku, jeśli wiadomo, kto ostatecznie instaluje poprawkę.

Co mówi ustawa o KSC?

Art. 8 ust. 1 ustawy z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (ustawy o KSC) wymienia wśród środków, które ma zapewnić system zarządzania bezpieczeństwem informacjiSystem zarządzania bezpieczeństwem informacji Uporządkowany sposób, w jaki podmiot kluczowy lub ważny zarządza bezpieczeństwem systemu używanego do świadczenia usługi, od szacowania ryzyka po obsługę incydentów. (SZBI) podmiotu kluczowego lub ważnego, pod pkt 2 lit. g „objęcie systemu informacyjnego wykorzystywanego do świadczenia usługi systemem monitorowania w trybie ciągłym”. Obok są obowiązki, które w praktyce wykonuje ten sam zespół:

zbieranie informacji o cyberzagrożeniach i podatnościach systemu informacyjnego (pkt 3);
zarządzanie incydentami (pkt 4);
regularne aktualizacje oprogramowania stosownie do zaleceń producenta (pkt 5 lit. b);
niezwłoczne działanie po dostrzeżeniu podatności lub cyberzagrożeń (pkt 5 lit. d).

Ministerstwo Cyfryzacji w odpowiedzi 3.3 tłumaczy, że monitorowanie w trybie ciągłym należy rozumieć tak, że podmiot „powinien monitorować wszelkie zdarzenia, które zaistniały w systemie informacyjnym”, a celem jest rozliczalność i możliwość odtworzenia, co się w systemie stało.

Ministerstwo opisuje monitorowanie w trybie ciągłym jako zbieranie i przechowywanie zdarzeń, a nie jako dyżur przy monitorach.

Na pytanie o SOC ministerstwo odpowiada w pkt 3.16: to podmiot decyduje, jakie rozwiązanie jest adekwatne do jego sytuacji, i może wybrać usługi zewnętrzne albo budować własne kompetencje, często w grupie kapitałowej. W pkt 3.42 dodaje, że ustawa „pozostaje neutralna technologicznie” i nie wskazuje obowiązkowych klas systemów, wymieniając w pytaniu właśnie SIEM i SOC. Dobór środków ma wynikać z szacowania ryzyka.

Najbliżej konkretu jest rekomendacja Pełnomocnika Rządu do Spraw Cyberbezpieczeństwa nr 2026-67a-9 z 15 października 2026 r. W pkt 6.1 zaleca m.in. centralizację logów, ich analizę pod kątem anomalii i prób nieuprawnionego dostępu, narzędzia klasy SIEM „lub rozwiązania równoważne” oraz zabezpieczenie logów przed usunięciem. Ostatni punkt brzmi:

„zapewnienie monitorowania aktywów o wysokiej krytyczności adekwatnie do poziomu ryzyka, w tym w uzasadnionych przypadkach w modelu 24/7”.

Rekomendacja nie jest przepisem, ale dobrze pokazuje kierunek: 24/7 tam, gdzie uzasadnia to ryzyko, a nie wszędzie. Pełne omówienie tej rekomendacji jest w tekście o rekomendacji 2026-67a-9 punkt po punkcie.

Podmioty publiczne będące podmiotami ważnymi stosują zamiast art. 8 ust. 1 wymagania z załącznika nr 4 do ustawy. Monitorowanie dostępu do informacji i stanu działania systemów jest tam w części II, czyli wśród środków, które SZBI „może dodatkowo obejmować”, z wyraźnie wskazaną alternatywą: własne oprogramowanie obsługiwane przez pracowników albo usługa dostawcy usług zarządzanych w zakresie cyberbezpieczeństwa.

Po co SOC, skoro ustawa go nie wymaga?

Bo bez kogoś, kto patrzy, terminy z art. 11 liczą się od chwili, w której podmiot dowie się o incydencie przypadkiem. Wczesne ostrzeżenie o incydencie poważnym podmiot zgłasza do CSIRT sektorowego niezwłocznie, nie później niż w ciągu 24 godzin od wykrycia (art. 11 ust. 1 pkt 4), a samo zgłoszenie w ciągu 72 godzin (pkt 4a). Ktoś musi to wykrycie zrobić i ocenić incydent, także w nocy z piątku na sobotę. Jak to wygląda od strony decyzji, opisałem w tekście o incydencie poważnym w praktyce.

Druga sprawa to dowody. Ministerstwo pisze o odtworzeniu, co się stało, a przy incydencie poważnym podmiot współdziała z CSIRT i przekazuje mu niezbędne dane (art. 11 ust. 1 pkt 5). Po ataku ransomware te dane zaczynają się od tego, kiedy napastnik wszedł i co robił. Jeśli logi leżały tylko na zaszyfrowanym serwerze, odpowiedź brzmi „nie wiemy”.

Czy wystarczy jeden informatyk?

To zależy od tego, czego od niego oczekujesz. Jeden informatyk może zbudować i utrzymywać monitorowanie w trybie ciągłym: wdrożyć narzędzia, które zbierają zdarzenia, ustawić alarmy, przeglądać je każdego dnia i reagować w godzinach pracy. W wielu podmiotach ważnych, zwłaszcza mniejszych, to rozsądny początek i nie widzę powodu, żeby go lekceważyć.

Jeden informatyk nie zapewni natomiast reakcji przez całą dobę. Tydzień ma 168 godzin, a etat około 40, więc jedno stanowisko obsadzone bez przerwy to, licząc z urlopami i chorobami, około pięciu etatów. Tę samą liczbę podaje materiał EUROSOC opublikowany przez Portal Samorządowy.

Informatyk, który ma telefon przy łóżku, nie pełni dyżuru, tylko liczy na to, że alarm sam go obudzi.

Jest też konflikt, o którym trzeba powiedzieć zarządowi. NCSC zwraca uwagę, że SOC prowadzi zwykle inny zespół niż ludzie, którzy utrzymują systemy, właśnie po to, żeby rozdzielić obowiązki. Informatyk, który sam administruje serwerami i sam przegląda ich logi, ocenia własną pracę i ma dostęp, żeby usunąć ślady własnego błędu. Nie zakładam złej woli, ale przy incydencie ktoś zapyta, kto to sprawdził.

Moim zdaniem jeden informatyk wystarcza, gdy szacowanie ryzyka pokazuje, że kilka godzin nocnego opóźnienia w reakcji jest akceptowalne, logi trafiają w miejsce, którego on sam nie może wyczyścić, a kierownik podmiotu przyjął to na piśmie. Gdy któryś z tych warunków nie jest spełniony, trzeba dołożyć ludzi albo usługę.

Darmowe narzędzia na początek: Zabbix i Wazuh

Zanim podmiot zapłaci za SIEM i licencje, sporo da się zrobić na oprogramowaniu otwartym. Dwa popularne narzędzia dobrze się tu uzupełniają.

Zabbix to system monitorowania dostępności i wydajności: serwerów, sieci, usług, urządzeń. Producent opisuje go jako „100% free and open-source”, na licencji AGPLv3, z wykrywaniem anomalii na podstawie danych historycznych. Zabbix powie, że serwer ERP przestał odpowiadać albo że ruch na łączu wzrósł nagle kilkukrotnie. Nie jest SIEM-em i nie powie, że ktoś zalogował się na konto administratora z nietypowego kraju, ale dla ciągłości działania to często pierwsza wiadomość o kłopocie.

Wazuh to platforma bezpieczeństwa, którą producent opisuje jako darmową i otwartą, łączącą funkcje SIEM i XDR. Agent na serwerach i komputerach zbiera zdarzenia, a moduł wykrywania podatności porównuje spis zainstalowanego oprogramowania z bazą znanych podatności. To odpowiada wprost na pkt 3 i pkt 5 lit. b art. 8 ust. 1: wiadomo, gdzie stoi podatna wersja i co trzeba zaktualizować.

„Darmowy” dotyczy licencji, a nie pracy. Ktoś musi wdrożyć agenty, ustawić reguły pod własne systemy, wyciszyć fałszywe alarmy, pilnować miejsca na dysku i aktualizować samą platformę. Liczyłbym na to kilka dni wdrożenia i stałą część etatu informatyka. Do tego bezpłatnie dostępne usługi państwowe: na moje.cert.pl CERT Polska udostępnia skanowanie domen skanerem Artemis i powiadomienia o wyciekach haseł z kont w domenie firmy. Rekomendacja 2026-67a-9 wymienia Artemis w pkt 3.2 jako narzędzie do regularnego skanowania podatności.

Kiedy warto rozważyć usługę zewnętrzną?

Art. 14 ustawy o KSC daje dwie drogi do realizacji zadań z art. 8 oraz art. 9 do 13: podmiot powołuje wewnętrzne struktury odpowiedzialne za cyberbezpieczeństwo albo zawiera umowę z dostawcą usług zarządzanych w zakresie cyberbezpieczeństwa. Zewnętrzny SOC jest taką usługą.

Usługę rozważyłbym, gdy szacowanie ryzyka pokazuje, że podmiot potrzebuje reakcji w nocy i w święta, gdy nie ma szans zatrudnić i utrzymać kilku analityków, albo gdy usługa zależy od systemów, których przestój liczy się w godzinach. Jest też model mieszany: informatyk prowadzi Zabbiksa i Wazuha w dzień, a zewnętrzny zespół przejmuje alarmy poza godzinami pracy.

Słabą stronę usługi NCSC też nazywa wprost: zewnętrzni analitycy mogą nie znać architektury systemów i nie reagować tak szybko jak zespół wewnętrzny. Dostawca widzi alarm, ale nie wie, że serwer, który właśnie wysyła dużo danych, robi to co noc, bo tak działa kopia zapasowa. Pierwsze miesiące współpracy to strojenie reguł i wymaga to czasu waszego informatyka.

Co sprawdzić w umowie z dostawcą?

Odpowiedzialność nie przechodzi na dostawcę. Art. 8c ust. 3 stanowi, że kierownik podmiotu odpowiada także wtedy, gdy obowiązki zostały powierzone innej osobie, a ministerstwo w odpowiedzi 3.44 zaleca, żeby w umowie z dostawcą ująć wymogi cyberbezpieczeństwa i kwestie odpowiedzialności. W poprzednim brzmieniu art. 14 ust. 2 sam stawiał wewnętrznym strukturom i firmom świadczącym usługi z zakresu cyberbezpieczeństwa warunki, m.in. zabezpieczone pomieszczenia do reagowania na incydenty. Obecny art. 14 ich nie powtarza, więc wymagania trzeba wpisać do umowy samemu. Ja sprawdzałbym co najmniej to:

Które źródła logów dostawca obejmuje i które systemy z SZBI zostają poza zakresem.
Godziny pracy (24/7 czy godziny biznesowe) i czas reakcji na alarm wysokiej wagi.
Co dostawca może zrobić sam, na przykład odciąć komputer od sieci, a co wymaga zgody osoby z podmiotu.
Kto przygotowuje i kto wysyła zgłoszenia do CSIRT. Obowiązek z art. 11 ciąży na podmiocie, dostawca może je przygotować.
Gdzie leżą logi, jak długo, czyje są i jak je dostać po rozwiązaniu umowy.
Co jest w cenie: licencje SIEM i EDR, przechowywanie logów, wdrożenie, raporty.

Warto też wiedzieć, z kim się podpisuje umowę. Dostawca usług zarządzanych w zakresie cyberbezpieczeństwa, który jest co najmniej małym przedsiębiorcą, jest z mocy art. 5 ust. 1 pkt 3 sam podmiotem kluczowym i ma własne obowiązki z ustawy. Ministerstwo w odpowiedzi 3.48 wyjaśnia, że weryfikacja niekaralności z art. 8f nie obejmuje personelu wykonawców, więc wymagania wobec ludzi dostawcy także trzeba zapisać w umowie. Szerzej o tym piszę w tekście o łańcuchu dostaw w ustawie o KSC. Informację o umowie z takim dostawcą na zadania z art. 8 i art. 11 wpisuje się do wykazu podmiotów kluczowych i ważnych (art. 7 ust. 2 pkt 16). Ministerstwo w odpowiedzi 2.51 dodaje, że gdy podmiot robi to własnymi siłami, pole zostaje puste.

Ile to kosztuje?

Rzetelnych, niezależnych danych o cenach SOC w Polsce nie znalazłem. Mam cenniki i szacunki dostawców, którzy na tej usłudze zarabiają, więc traktuję je jako rząd wielkości, a nie jako wycenę:

Model	Co podaje źródło	Źródło
Usługa, pakiet wejściowy	od 1 499 zł netto miesięcznie za monitoring 24/7, alerty i raportowanie	SecIQ
Usługa, typowa wycena	od kilku do kilkudziesięciu tysięcy złotych miesięcznie, zależnie od liczby źródeł, trybu pracy i usług dodatkowych	Trecom
Wdrożenie usługi	jednorazowo od 10 tys. do 100 tys. zł za konfigurację i podłączenie źródeł logów	SecIQ
Własny SOC 24/7	zespół 10 do 15 osób, około 120 tys. zł miesięcznie na same pensje, rocznie ponad 2 mln zł	EUROSOC (Portal Samorządowy)
Własny SOC 24/7	od sześciu do ośmiu analityków, licencje SIEM i XDR od 300 tys. do 800 tys. zł rocznie, razem od 2 mln do 5 mln zł rocznie	SecIQ
Informatyk z Wazuhem i Zabbiksem	licencje 0 zł; koszt to część etatu, serwer i czas wdrożenia	moje szacowanie

Najtańszy pakiet i własny zespół według tych samych szacunków dzieli ponad stukrotna różnica, więc pod słowem „SOC” sprzedaje się bardzo różne rzeczy. Za 1 499 zł miesięcznie nikt nie utrzyma pięciu etatów analityków dla jednego klienta. Usługa jest tańsza, bo dostawca dzieli ludzi i narzędzia między wielu klientów, a pakiet wejściowy nie musi obejmować wszystkich systemów, od których zależy usługa. Przed porównaniem ofert trzeba więc zapytać o zakres z listy wyżej.

W jednej z ofert przeczytałem, że monitoring w godzinach pracy „nie spełnia wymogu ustawy”. Ustawa tego nie mówi, a ministerstwo w odpowiedziach 3.16 i 3.42 mówi coś przeciwnego: rozwiązanie ma wynikać z ryzyka. Jeśli ryzyko uzasadnia 24/7, to dlatego, że tak wyszło z szacowania, a nie dlatego, że tak napisał sprzedawca.

Co zmienia AI?

Dużo, choć mniej, niż obiecują materiały marketingowe. Duże platformy SIEM mają już asystentów opartych na modelach językowych, którzy streszczają alarm, podpowiadają, co sprawdzić, i piszą zapytania do logów. Jedyne poważniejsze badanie na danych z działających SOC-ów, jakie znalazłem, przygotowali badacze Microsoftu: wdrożenie narzędzia generatywnej AI wiązało się ze spadkiem średniego czasu obsługi incydentu o 30,13 %. Autorzy sami zastrzegają, że to związek, a nie dowód przyczyny, a narzędzie było ich firmy.

Ciekawsze dla mniejszego podmiotu jest to, że AI da się podłączyć do darmowych narzędzi. Wazuh opublikował w 2025 r. opis, jak uruchomić lokalny model językowy na własnym serwerze (Llama 3 przez Ollamę, minimum 16 GB RAM) i zadawać mu pytania o logi zwykłym językiem, a w czerwcu 2026 r. opis agenta, który sam przeszukuje alarmy przez API. W tym drugim autorzy dają agentowi tylko uprawnienia do odczytu, zgodnie z zasadą najmniejszych uprawnień, i tak bym to zostawił.

Agent, który może tylko czytać, w najgorszym razie się pomyli, a agent z prawem do blokowania kont może w nocy zatrzymać firmę.

Model działający lokalnie ma tu jeszcze jedną zaletę: logi firmy nie trafiają do publicznego czatu. Logi zawierają adresy, nazwy kont, czasem dane osobowe, a wklejanie ich do ogólnodostępnej usługi to klasyczny przykład shadow AI, który trzeba ująć w SZBI. Które modele pobrać i do czego, opisałem w tekście o lokalnych modelach językowych.

Własne narzędzia zamiast gotowego produktu

AI zmieniła też to, kto może napisać własne narzędzie. Kilka lat temu skrypt, który co rano zbiera biuletyny producentów używanego sprzętu, porównuje je ze spisem urządzeń i wysyła informatykowi listę „to dotyczy nas”, był projektem dla programisty. Dziś informatyk z asystentem AI napisze go w kilka dni, dopasowany do własnego spisu sprzętu i własnych priorytetów. Najlepiej sprawdza się tam, gdzie gotowe produkty są za drogie albo za ogólne: monitorowanie komunikatów konkretnych producentów, raport tygodniowy dla zarządu, porządkowanie alarmów z Wazuha.

Sam tak pracuję. Ta strona ma automat, który cztery razy dziennie czyta kilkadziesiąt źródeł, m.in. komunikaty CERT Polska i CSIRT, katalog KEV amerykańskiej CISA i biuletyny producentów takich jak Fortinet, Cisco czy Siemens. Model językowy porządkuje tematy i przygotowuje szkic wiadomości, ale szkic trafia do mnie i nic nie ukazuje się bez mojej zgody. Automat oszczędza mi czytania, a decyzja, co jest ważne, zostaje przy mnie.

Ta sama zasada dotyczy narzędzi do SOC-u. Skrypt napisany z pomocą AI jest oprogramowaniem jak każde inne: trzeba go przetestować, opisać, przechowywać w repozytorium i wiedzieć, kto go poprawi, gdy autor odejdzie. Jeśli ma dostęp do logów albo do API systemów, należy do SZBI i do szacowania ryzyka tak samo jak kupiony SIEM.

Od czego zacząć?

Od listy systemów, od których zależy usługa, i jednego pytania przy każdym: po ilu godzinach od włamania albo awarii dowiedzielibyśmy się o niej dzisiaj. Jeśli odpowiedź brzmi „w poniedziałek rano, gdy ktoś zadzwoni, że nie działa”, to jest pierwsza luka do zamknięcia, niezależnie od tego, czy zamknie ją informatyk z Wazuhem, czy umowa z dostawcą.

Potem przy każdym systemie zapisujecie, jaka zwłoka w reakcji jest do przyjęcia, i z tego wychodzi, czy potrzebujecie 24/7, czy godzin pracy z dyżurem telefonicznym. Kierownik podmiotu podpisuje tę decyzję razem z budżetem, bo art. 8d pkt 2 wymaga od niego planowania adekwatnych środków finansowych. Dopiero z taką kartką warto prosić dostawców o oferty, bo wtedy porównuje się te same rzeczy.

Pojęcia w tym tekście (25)

Ustawa o KSC: Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa. Po nowelizacji z 2026 r. wdraża dyrektywę NIS2 i określa obowiązki podmiotów kluczowych i ważnych.
Centrum operacji bezpieczeństwa: Zespół lub usługa, która całą dobę monitoruje systemy firmy, wykrywa podejrzane zdarzenia i uruchamia reakcję na incydent.
Kierownik podmiotu: Osoba albo organ kierujący podmiotem kluczowym lub ważnym, na przykład zarząd spółki. Odpowiada za cyberbezpieczeństwo podmiotu także wtedy, gdy zadania powierzył innej osobie.
Incydent: Zdarzenie, które szkodzi albo może zaszkodzić bezpieczeństwu systemów informacyjnych. Zgłaszać trzeba nie każdy incydent, tylko incydent poważny.
Podatność: Słabość produktu lub usługi ICT, którą można wykorzystać do ataku. Znane podatności dostają identyfikatory CVE, a te wykorzystywane w atakach trafiają do katalogu KEV.
System SIEM: Security Information and Event Management: system, który zbiera w jednym miejscu logi z wielu systemów i urządzeń, żeby można je było analizować i wykrywać w nich ślady incydentów.
System EDR: Endpoint Detection and Response: oprogramowanie na serwerach i komputerach, które stale obserwuje, co się na nich dzieje, wykrywa podejrzane działania i pozwala na nie zareagować, na przykład odciąć komputer od sieci.
CSIRT: Zespół reagowania na incydenty bezpieczeństwa komputerowego. Na poziomie krajowym działają trzy: CSIRT GOV (Szef ABW), CSIRT MON (Minister Obrony Narodowej) i CSIRT NASK (NASK-PIB).
System zarządzania bezpieczeństwem informacji: Uporządkowany sposób, w jaki podmiot kluczowy lub ważny zarządza bezpieczeństwem systemu używanego do świadczenia usługi, od szacowania ryzyka po obsługę incydentów.
Podmiot kluczowy: Podmiot z sektorów ustawy o KSC, który ze względu na wielkość albo rodzaj działalności ma najszersze obowiązki, w tym audyt bezpieczeństwa co najmniej raz na trzy lata.
Szacowanie ryzyka: Proces, w którym podmiot ustala, co może zagrozić jego systemom, jak bardzo jest to prawdopodobne i jakie byłyby skutki. W praktyce mówi się też „analiza ryzyka”.
Rekomendacja Pełnomocnika: Dokument Pełnomocnika Rządu do Spraw Cyberbezpieczeństwa o środkach ochrony albo o stosowaniu konkretnego produktu lub usługi ICT. Publikowany w BIP; rekomendacje o środkach ochrony są dobrowolne.
Podmiot publiczny: Podmiot z sektora „podmioty publiczne” w załączniku nr 1 lub 2 do ustawy o KSC. Podmiot publiczny, który jest podmiotem ważnym, wdraża SZBI według załącznika nr 4 do ustawy.
Podmiot ważny: Podmiot z sektorów ustawy o KSC, który spełnia jej kryteria, ale nie jest podmiotem kluczowym. Wdraża SZBI i zgłasza incydenty poważne tak jak podmiot kluczowy.
Dostawca usług zarządzanych w zakresie cyberbezpieczeństwa: Firma, która na podstawie umowy prowadzi dla podmiotu działania z zakresu zarządzania ryzykiem, na przykład obsługę incydentów, testy lub audyty. Umowa z nią zastępuje własny zespół.
Wczesne ostrzeżenie: Pierwsze zgłoszenie incydentu poważnego do CSIRT sektorowego, niezwłocznie i najpóźniej w ciągu 24 godzin od wykrycia. Pełne zgłoszenie idzie w ciągu 72 godzin.
Incydent poważny: Incydent, który poważnie zakłóca usługę, przynosi podmiotowi straty finansowe albo wyrządza poważną szkodę innym. Podmiot kluczowy lub ważny zgłasza go do CSIRT sektorowego.
CSIRT sektorowy: Zespół reagowania na incydenty dla jednego sektora lub podsektora, ustanowiony przez organ właściwy. To do niego podmiot kluczowy lub ważny zgłasza incydent poważny.
Ransomware: Złośliwe oprogramowanie, które szyfruje dane i żąda okupu za ich odszyfrowanie. Coraz częściej sprawcy także wykradają dane i grożą ich upublicznieniem.
Ciągłość działania: Zdolność podmiotu do świadczenia usługi mimo awarii albo ataku. Ustawa wymaga planów ciągłości działania, które są dokumentowane, testowane i utrzymywane.
System XDR: Extended Detection and Response: rozwinięcie EDR, które łączy zdarzenia z komputerów, sieci i chmury, żeby wykrywać ataki przechodzące przez kilka systemów i reagować na nie w jednym miejscu.
CERT Polska: Zespół reagowania na incydenty prowadzony przez NASK, źródło ostrzeżeń i analiz, które cytuję w aktualnościach. Ustawa tej nazwy nie zna; ustawowym zespołem jest CSIRT NASK.
Wykaz podmiotów kluczowych i ważnych: Rejestr podmiotów kluczowych i ważnych prowadzony w systemie S46. Służy ich identyfikacji, wymianie informacji o incydentach i nadzorowi.
Katalog KEV: Known Exploited Vulnerabilities: prowadzona przez CISA lista podatności, o których wiadomo, że są wykorzystywane w atakach. Wpis do katalogu to sygnał, żeby łatać w pierwszej kolejności.
CISA: Cybersecurity and Infrastructure Security Agency, amerykańska agencja ds. cyberbezpieczeństwa i infrastruktury. Prowadzi katalog KEV; nie jest organem w rozumieniu ustawy o KSC.

Najczęściej zadawane pytania

Czy ustawa o KSC wymaga, żeby podmiot kluczowy albo ważny miał SOC?

Nie. Art. 8 ust. 1 pkt 2 lit. g ustawy o KSC wymaga objęcia systemu informacyjnego wykorzystywanego do świadczenia usługi systemem monitorowania w trybie ciągłym, ale nie określa, jak to zrobić. Ministerstwo Cyfryzacji w odpowiedzi 3.16 pisze, że nie ma narzuconych rozwiązań technicznych ani organizacyjnych, a w odpowiedzi 3.42, że ustawa jest neutralna technologicznie i nie wskazuje obowiązkowych klas systemów, także SIEM i SOC.

Czy monitorowanie w trybie ciągłym oznacza dyżur analityków 24 godziny na dobę?

Ustawa tego nie przesądza. Ministerstwo Cyfryzacji (odpowiedź 3.3) rozumie ten wymóg tak, że podmiot monitoruje wszelkie zdarzenia w systemie informacyjnym, żeby zapewnić rozliczalność i móc odtworzyć, co się w nim stało. Rekomendacja Pełnomocnika Rządu nr 2026-67a-9 zaleca monitorowanie aktywów o wysokiej krytyczności adekwatnie do poziomu ryzyka, „w tym w uzasadnionych przypadkach w modelu 24/7”. O tym, czy taki przypadek zachodzi, rozstrzyga szacowanie ryzyka z art. 8 ust. 1 pkt 1.

Czy po podpisaniu umowy z zewnętrznym SOC-iem odpowiedzialność przechodzi na dostawcę?

Nie. Art. 14 ustawy o KSC pozwala zawrzeć umowę z dostawcą usług zarządzanych w zakresie cyberbezpieczeństwa zamiast powoływać wewnętrzne struktury, ale art. 8c ust. 3 stanowi, że kierownik podmiotu odpowiada także wtedy, gdy obowiązki powierzył innej osobie. Ministerstwo Cyfryzacji w odpowiedzi 3.44 zaleca ująć w umowie z dostawcą wymogi cyberbezpieczeństwa i kwestie odpowiedzialności.

Czy pracownicy zewnętrznego SOC-u muszą przedstawić informację z Krajowego Rejestru Karnego?

Według odpowiedzi 3.48 Ministerstwa Cyfryzacji obowiązek z art. 8f ustawy o KSC obejmuje pracowników podmiotu i osoby, które mają z nim umowy cywilnoprawne bezpośrednio, a nie personel wykonawców i podwykonawców. Bezpieczeństwo personelu dostawcy zapewnia się w ramach zarządzania ryzykiem łańcucha dostaw i w postanowieniach umowy.

Źródła

Stan prawny sprawdzony: 24.10.2026. Wpis jest informacją ogólną, nie poradą prawną (zasady publikacji).