Dyrektor IT firmy produkcyjnej podpisuje protokół odbioru wdrożenia SIEM. Kolektory zbierają logi z kontrolerów domeny, firewalli i serwerów aplikacyjnych, reguły korelacji działają, dashboard świeci na zielono. Tydzień później zarząd pyta: „to jesteśmy już zgodni z NIS2?”. Odpowiedź brzmi: częściowo — i nie w tej części, o którą organ nadzoru zapyta najpierw.
Ten tekst nie jest przewodnikiem po wyborze SIEM-a ani listą producentów. Interesuje nas jedna granica: gdzie kończy się to, co narzędzie realizuje samo, a zaczyna to, co realizuje wyłącznie obsadzony proces. Granica nie jest kwestią opinii — przebiega tam, gdzie polska ustawa przechodzi od opisu środka technicznego do wskazania terminu, adresata i osoby z imieniem, nazwiskiem i numerem telefonu służbowego.
Czy sam SIEM wystarczy do spełnienia wymagań NIS2?
Nie wystarczy, i nie jest to kwestia dojrzałości wdrożenia. SIEM zamyka wymogi opisujące stan systemu informacyjnego — zbieranie danych, korelację, ciągłe monitorowanie. Ustawa o krajowym systemie cyberbezpieczeństwa stawia obok nich wymogi opisujące zachowanie organizacji w czasie: co ma się wydarzyć w ciągu 24 godzin od wykrycia, kto ma to zrobić i komu przekazać.
Różnica nie jest akademicka. Firma z dojrzałym SIEM-em i bez procesu obsługi incydentu spełnia jedną grupę przepisów, a łamie drugą — obwarowaną terminami w godzinach i karą nakładaną na kierownika osobiście. Wdrożenie SIEM-a liczy się do zgodności i niżej pokazujemy, który przepis zamyka; zamyka tylko mniej, niż wynika z rozmów sprzedażowych.
Który wymóg ustawy o KSC SIEM rzeczywiście zamyka?
SIEM realizuje wymóg objęcia systemu informacyjnego monitorowaniem w trybie ciągłym. Przepis brzmi dosłownie: podmiot kluczowy lub ważny wdraża środki obejmujące „objęcie systemu informacyjnego wykorzystywanego do świadczenia usługi systemem monitorowania w trybie ciągłym” — art. 8 ust. 1 pkt 2 lit. g ustawy o krajowym systemie cyberbezpieczeństwa w brzmieniu nadanym nowelizacją z 23 stycznia 2026 r. (Dz.U. 2026 poz. 252, obowiązuje od 3 kwietnia 2026 r.).
To nie jedyny punkt zaczepienia. Ten sam artykuł w pkt 3 wymaga „zbierania informacji o cyberzagrożeniach i podatnościach na incydenty systemu informacyjnego wykorzystywanego do świadczenia usługi”, a art. 11 ust. 1 pkt 2 nakazuje zapewnić właściwemu CSIRT dostęp do informacji o rejestrowanych incydentach. Obu tych obowiązków nie wykonasz bez centralnego repozytorium zdarzeń. Dochodzi wymóg mniej oczywisty: art. 8 ust. 1 pkt 2 lit. h każe utrzymywać „polityki i procedury oceny skuteczności środków technicznych i organizacyjnych”, a dane z SIEM-a są tu materiałem dowodowym — bez nich ocena opiera się na deklaracjach.
Kluczowy wniosek: SIEM zamyka trzy wymogi ustawy o KSC — ciągłe monitorowanie, zbieranie informacji o zagrożeniach oraz dostęp CSIRT do rejestrowanych incydentów. Wszystkie trzy dotyczą danych. Żaden nie dotyczy decyzji podejmowanej na tych danych.
Czego SIEM nie zamyka, choć wygląda, jakby zamykał?
SIEM nie zamyka obowiązku zarządzania incydentami. W ustawie zajmuje on jedną linijkę — art. 8 ust. 1 pkt 4 wymienia „zarządzanie incydentami” obok pozostałych elementów systemu zarządzania bezpieczeństwem informacji — ale rozwinięcie tej linijki zajmuje cztery artykuły: art. 11, 12, 12a i 12b.
Sedno problemu opisuje NIST: „Additional analysis is often needed to determine whether adverse cybersecurity events indicate that a cybersecurity incident has occurred” („często potrzebna jest dodatkowa analiza, aby ustalić, czy niekorzystne zdarzenia w zakresie cyberbezpieczeństwa oznaczają, że doszło do incydentu”) — NIST SP 800-61r3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management, kwiecień 2025, rozdział 1.
Tej analizy nie ma w licencji. SIEM produkuje zdarzenia i alerty; ustalenie, czy alert oznacza incydent, czy incydent jest poważny w rozumieniu prawa i czy zaczął biec zegar zgłoszenia, to trzy odrębne decyzje, a każda wymaga człowieka umocowanego do jej podjęcia. Wątek obsady rozwijamy w tekście o tym, dlaczego SOC jest niezbędny dla zgodności z KSC i NIS2.
Dlaczego termin 24 godzin jest wymogiem o obsadzie, a nie o narzędziu?
Bo zegar rusza w momencie wykrycia, a nie wtedy, gdy ktoś zajrzy do konsoli. Art. 11 ust. 1 pkt 4 nakazuje zgłosić wczesne ostrzeżenie o incydencie poważnym „niezwłocznie, niepóźniej niż w ciągu 24 godzin od momentu jego wykrycia, do właściwego CSIRT sektorowego”. Kolejne 48 godzin daje pkt 4a na pełne zgłoszenie — łącznie 72 godziny od wykrycia.
Konsekwencję łatwo przeoczyć. Alert wygenerowany w piątek o 19:00 uruchamia termin upływający w sobotę o 19:00. Jeżeli obsługa konsoli działa w trybie ośmiogodzinnym od poniedziałku do piątku, termin mija, zanim ktokolwiek otworzy zgłoszenie. Narzędzie zadziałało poprawnie, a obowiązek został naruszony.
Dla części podmiotów siatka jest ciaśniejsza: dostawca usług zaufania w ciągu 24 godzin od wykrycia składa nie wczesne ostrzeżenie, tylko pełne zgłoszenie (art. 11 ust. 1a). Sprawozdanie końcowe trafia do CSIRT sektorowego najpóźniej miesiąc od dnia zgłoszenia (art. 11 ust. 1 pkt 4c), a gdy obsługa incydentu do tego czasu się nie zakończy — podmiot przekazuje sprawozdanie z postępu (art. 12b ust. 1).
Gdy własna obsada całodobowa jest poza zasięgiem organizacji, tę część obowiązku da się przenieść na dostawcę — na tym polega usługa SOC w modelu 24/7. Odpowiedzialności z kierownika nie zdejmuje, ale zamyka lukę między wykryciem a decyzją.
Co musi zawierać zgłoszenie, czego SIEM nie wygeneruje?
Zgłoszenie musi zawierać dane, których w logach nie ma. Wczesne ostrzeżenie zgodnie z art. 12 ust. 1 obejmuje między innymi „imię i nazwisko, numer telefonu służbowego oraz adres służbowej poczty elektronicznej osoby dokonującej zgłoszenia” oraz te same dane osoby uprawnionej do składania wyjaśnień. To wymóg o osobie pełniącej dyżur, nie o systemie.
Pełne zgłoszenie idzie dalej. Art. 12 ust. 3 wymaga opisu wpływu incydentu na świadczenie usługi: wskazania konkretnej usługi, liczby użytkowników, na których incydent miał wpływ, zasięgu geograficznego obszaru oraz wpływu na usługi innych podmiotów. SIEM zna adresy IP, konta i nazwy hostów; przełożenie ich na liczbę klientów i obszar wymaga rejestru usług i bazy klientów — danych, których w SIEM-ie nie ma i być nie powinno.
Sprawozdanie końcowe dokłada elementy z art. 12a: szczegółowy opis incydentu wraz ze spowodowanymi zakłóceniami i szkodami, rodzaj zagrożenia lub prawdopodobną przyczynę źródłową, zastosowane środki ograniczające ryzyko oraz skutki transgraniczne. Wszystko idzie przez system teleinformatyczny z art. 46 ust. 1 (art. 11 ust. 2) — kanał, do którego trzeba mieć wcześniej konto i wyznaczone osoby.
Praktyczna fiszka: przed pierwszym incydentem sprawdź trzy rzeczy, które w trakcie zdarzenia zajmą godziny: czy masz konto w systemie z art. 46 ust. 1, który CSIRT sektorowy jest dla Ciebie właściwy i czy potrafisz w 24 godziny podać liczbę użytkowników dotkniętych awarią konkretnej usługi.
Kto ustala próg, od którego incydent jest „poważny”?
Progu nie ustala organizacja ani dostawca SIEM-a. Zgodnie z art. 11 ust. 4 progi uznania incydentu za poważny określa Rada Ministrów w drodze rozporządzenia, według rodzaju zdarzenia w sektorach i podsektorach z załączników nr 1 i 2 do ustawy, odnosząc je do liczby użytkowników dotkniętych zakłóceniem, czasu oddziaływania incydentu, zasięgu geograficznego lub innych czynników charakterystycznych dla sektora.
Od reguły jest wyjątek o dużym zasięgu praktycznym. Przepis wyłącza podmioty, dla których progi określiła już Komisja Europejska w akcie wydanym na podstawie art. 23 ust. 11 dyrektywy 2022/2555 — między innymi dostawców usług chmurowych, centrów przetwarzania danych, sieci dostarczania treści i usług zarządzanych. Dla nich źródłem progów jest rozporządzenie wykonawcze Komisji (UE) 2024/2690, do którego odsyła art. 8b ust. 1 ustawy.
Konsekwencja dla konfiguracji jest bezpośrednia. Pola severity w SIEM-ie — critical, high, medium — pochodzą z modelu ryzyka producenta i nie mają związku z progiem ustawowym. Dopóki nie wpiszesz do procedury wartości z aktu właściwego dla swojego sektora, klasyfikujesz incydenty poprawnie technicznie i bezużytecznie wobec obowiązku zgłoszenia. Ten sam mechanizm opisaliśmy przy innym narzędziu — w tekście o tym, czy ISO 27001 wystarczy do NIS2.
Co mówi NIST o miejscu SIEM-a w obsłudze incydentu?
NIST umieszcza SIEM w wąskim wycinku obsługi incydentu i da się to policzyć. Publikacja SP 800-61r3 z kwietnia 2025 r. ma postać profilu społecznościowego CSF 2.0 i wymienia 106 elementów ram — podkategorii przypisanych do sześciu funkcji: Govern, Identify, Protect, Detect, Respond i Recover. SIEM pada w rekomendacjach do trzech z nich: DE.AE-02, DE.AE-03 i DE.AE-04.
Wszystkie trzy leżą w jednej kategorii — analizie zdarzeń niekorzystnych w funkcji Detect. NIST zaleca tam SIEM lub SOAR do ciągłego monitorowania logów (DE.AE-02), korelacji informacji z wielu źródeł (DE.AE-03) oraz oszacowania wpływu i zasięgu zdarzenia (DE.AE-04). Poza tymi trzema punktami narzędzie klasy SIEM nie pojawia się w profilu ani razu.
Liczby sprawdzisz w pięć minut: pobierz dokument ze strony NIST i policz wystąpienia.
Kluczowy wniosek: SIEM odpowiada w modelu NIST za trzy podkategorie ze stu sześciu, wszystkie w funkcji Detect. Pozostałe sto trzy opisują decyzje, role, procedury i komunikację — a zgodność z NIS2 rozstrzyga się głównie w funkcjach Govern i Respond, gdzie żadne narzędzie klasy SIEM nie jest wymieniane.
Kto odpowiada, gdy zgłoszenie nie wyjdzie na czas?
Odpowiada kierownik podmiotu, osobiście. Art. 8c ust. 1 przypisuje kierownikowi podmiotu kluczowego lub ważnego odpowiedzialność za wykonywanie obowiązków między innymi z art. 8 oraz z art. 9–12b — obejmuje więc i system zarządzania bezpieczeństwem informacji, i cały blok zgłoszeniowy. Ustęp 3 dopowiada, że odpowiedzialność trwa także wtedy, gdy obowiązki powierzono innej osobie za jej zgodą.
Sankcja jest wyodrębniona. Art. 73a ust. 1 pkt 9 przewiduje karę pieniężną dla kierownika, który nie wykonuje co najmniej jednego z obowiązków z art. 11, a pkt 11 osobno karze przekazanie sprawozdania końcowego bez elementów wymaganych przez art. 12a. Kara nie może przekroczyć 300% wynagrodzenia kierownika liczonego według zasad ustalania ekwiwalentu za urlop (art. 73a ust. 4).
Kara dla podmiotu biegnie równolegle: dla podmiotu kluczowego do 10 000 000 euro albo 2% przychodów za poprzedni rok obrotowy, przy czym stosuje się kwotę wyższą i nie mniej niż 20 000 zł (art. 73 ust. 3). Dla podmiotu ważnego — 7 000 000 euro albo 1,4% przychodów, nie mniej niż 15 000 zł (art. 73 ust. 4). Umowa z dostawcą SIEM-a nie przenosi żadnej z nich.
Jak sprawdzić, czy Twój SIEM jest wpięty w obowiązek, czy tylko w sieć?
Sprawdzisz to pięcioma pytaniami, na które odpowiedź zajmuje jedno popołudnie. Każde dotyczy styku między narzędziem a obowiązkiem prawnym — dlatego odpowiedzi nie znajdziesz w konsoli.
Po pierwsze: czy istnieje reguła korelacji, której zadziałanie oznacza „prawdopodobny incydent poważny w rozumieniu ustawy”, a nie tylko wysoki priorytet techniczny? Po drugie: czy ktoś ma obowiązek zareagować na nią w czasie krótszym niż 24 godziny, także w nocy i w sobotę, i czy obowiązek ten jest zapisany w umowie albo w zakresie stanowiska? Po trzecie: czy istnieje procedura, która z alertu robi zgłoszenie z liczbą użytkowników i zasięgiem geograficznym?
Po czwarte: czy osoby realizujące zadania z art. 8 i art. 11 przedstawiły informację z Krajowego Rejestru Karnego o niekaralności za przestępstwa przeciwko ochronie informacji, wymaganą przez art. 8f ust. 1 przed dopuszczeniem do tych zadań? Po piąte: czy retencja logów pozwala odtworzyć przebieg incydentu na potrzeby sprawozdania końcowego? Trzy odpowiedzi „nie” oznaczają, że SIEM działa poprawnie jako system monitorowania i nie jest jeszcze wpięty w obowiązek ustawowy.
Co dokładnie zostaje do dołożenia po wdrożeniu SIEM-a?
Zostaje wszystko, co dzieje się po alercie. Tabela zestawia wymóg ustawy o krajowym systemie cyberbezpieczeństwa z tym, co typowe wdrożenie SIEM daje bez dodatkowej pracy, i z tym, co trzeba dołożyć osobno.
| Wymóg ustawy o KSC | Co daje SIEM z pudełka | Co zostaje do dołożenia |
|---|---|---|
| Monitorowanie ciągłe (art. 8 ust. 1 pkt 2 lit. g) | Zbieranie i korelacja zdarzeń z objętych źródeł | Objęcie monitorowaniem wszystkich systemów w procesie usługi |
| Informacje o cyberzagrożeniach (art. 8 ust. 1 pkt 3) | Wzbogacanie zdarzeń danymi o zagrożeniach | Subskrypcja źródeł i przegląd ich adekwatności do sektora |
| Zarządzanie incydentami (art. 8 ust. 1 pkt 4) | Kolejka alertów i statusy | Runbooki, role decyzyjne, eskalacja, dyżur poza godzinami pracy |
| Kwalifikacja incydentu (art. 11 ust. 4) | Priorytety producenta (critical/high) | Progi z rozporządzenia właściwego dla sektora, wpisane do procedury |
| Wczesne ostrzeżenie w 24 h (art. 11 ust. 1 pkt 4) | Znacznik czasu wykrycia | Obsada zdolna zareagować w terminie, konto w systemie z art. 46 ust. 1, właściwy CSIRT |
| Treść wczesnego ostrzeżenia (art. 12 ust. 1) | Dane techniczne zdarzenia | Imienne dane osoby zgłaszającej i składającej wyjaśnienia |
| Treść zgłoszenia w 72 h (art. 12 ust. 3) | Przebieg techniczny i działania naprawcze | Liczba dotkniętych użytkowników, zasięg geograficzny, wpływ na inne podmioty |
| Sprawozdanie końcowe (art. 12a) | Materiał dowodowy z logów | Analiza przyczyny źródłowej, opis szkód, skutki transgraniczne |
| Informowanie użytkowników (art. 11 ust. 2b) | — | Kryterium decyzyjne i gotowe komunikaty w planie kryzysowym |
| Niekaralność wykonujących zadania (art. 8f ust. 1) | — | Procedura pozyskania informacji z KRK przed dopuszczeniem |
Kolumna środkowa kończy się wszędzie tam, gdzie przepis przestaje opisywać system, a zaczyna opisywać czyjeś działanie w wyznaczonym czasie.
Od czego zacząć, jeśli masz SIEM i nie masz pewności co do NIS2?
Zacznij od ustalenia własnego statusu, nie od przeglądu konfiguracji. Sprawdź, czy jesteś podmiotem kluczowym czy ważnym i który załącznik do ustawy Cię obejmuje — od tego zależy, czy progi bierzesz z rozporządzenia Rady Ministrów, czy z rozporządzenia wykonawczego (UE) 2024/2690.
Drugim krokiem jest zegar: ustal, kto i w jakim trybie reaguje na alert kwalifikujący się jako prawdopodobny incydent poważny, i porównaj to z terminem 24 godzin liczonym od wykrycia. Trzecim jest przygotowanie kanału — konto w systemie z art. 46 ust. 1, wskazany CSIRT sektorowy i szablon zgłoszenia z polami z art. 12.
Żeby zobaczyć całą lukę naraz, zamiast odkrywać ją incydent po incydencie, zestaw obowiązki z ustawy o KSC ze stanem faktycznym — tym zajmuje się wsparcie w zakresie zgodności z ustawą o KSC. Kontekst nowelizacji opisaliśmy w tekście o nowelizacji ustawy o KSC i wymaganiach NIS2, a różnice między narzędziem a zespołem — w porównaniu SOC, SIEM i SOAR.
Kluczowy wniosek: SIEM jest warunkiem koniecznym i realnie skraca drogę, ale zgodność z NIS2 rozstrzyga się tam, gdzie żadna konsola nie sięga — przy progu ustawowym, zegarze liczonym od wykrycia, imieniu osoby dyżurującej i podpisie kierownika podmiotu.
Źródła:
- Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa w brzmieniu nadanym nowelizacją z 23 stycznia 2026 r. (Dz.U. 2026 poz. 252, obowiązuje od 3 kwietnia 2026 r.) — art. 8, 8b, 8c, 8f, 11, 12, 12a, 12b, 46 ust. 1, 73 i 73a.
- Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 z 14 grudnia 2022 r. (NIS2), Dz. Urz. UE L 333 z 27.12.2022, s. 80 — art. 21 ust. 5, art. 23 ust. 11.
- Rozporządzenie wykonawcze Komisji (UE) 2024/2690 z 17 października 2024 r., Dz. Urz. UE L 2024/2690 z 18.10.2024.
- NIST SP 800-61r3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile, kwiecień 2025.
