Jak wdrożyć monitoring w trybie ciągłym i raportować zgodnie z wymaganiami UoKSC?

Trecom Data publikacji: 08.09.2026 14 min. czytania

Praktyczny przewodnik dla zarządów, CIO, CISO i działów zgodności

Uwaga: artykuł ma charakter edukacyjny i poglądowy, nie jest „wyrocznią” merytoryczną, architektoniczną ani formalno-prawną. Każda organizacja powinna potwierdzić swoje potrzeby, swój status podmiotu, właściwe terminy i zakres obowiązków na podstawie aktualnego tekstu ustawy, aktów wykonawczych, komunikatów właściwego CSIRT, własnej analizy prawnej.

Wprowadzenie: dlaczego to nie jest projekt technologiczny

Załóżmy czysto hipotetyczną sytuację, która może wydarzyć się w rzeczywistości. W poniedziałek o 8:20 zespół IT dostaje alert o nietypowym logowaniu do konta uprzywilejowanego. O 10:15 EDR izoluje komputer administratora. O 13:40 analiza pokazuje, że atakujący uzyskał dostęp do części środowiska, a w skrzynce pocztowej pojawiła się reguła przekierowania wiadomości.

Organizacja ma licencje bezpieczeństwa, narzędzie do zbierania logów i umowę z dostawcą SOC. Nie ma jednak uzgodnionej definicji incydentu poważnego, pełnej listy osób decyzyjnych, przetestowanego modelu eskalacji ani gotowego procesu raportowania.

W takiej sytuacji problemem rzadko jest brak alertu. Problemem jest brak zdolności do podjęcia właściwej decyzji i przekazania wymaganych informacji w odpowiednim czasie.

Nowelizacja Ustawy o Krajowym Systemie Cyberbezpieczeństwa (UoKSC), wdrażająca wymagania dyrektywy NIS2, rozszerza obowiązki podmiotów kluczowych i ważnych w obszarze zarządzania ryzykiem, obsługi incydentów, systemu zarządzania bezpieczeństwem informacji oraz współpracy z właściwymi organami i CSIRT.

Monitoring w trybie ciągłym nie sprowadza się do samego zakupu SIEM, wdrożenia EDR ani podpisania umowy z zewnętrznym dostawcą usługi SOC. To zdolność organizacyjna obejmująca ludzi, procesy, technologię, dane, odpowiedzialność, komunikację i udokumentowane decyzje, które mają przekładać się na możliwość ciągłego monitoringu i raportowania.

Ten artykuł pokazuje, jak do budowania takiej zdolności można podejść — od określenia usług krytycznych, przez wybór modelu SOC/MDR i narzędzi, aż po organizację procesu raportowania.

1. Co UoKSC wymaga od organizacji

Tekst UoKSC nie wskazuje literalnie zakup konkretnych technologii typu SIEM, EDR, XDR, SOAR ani usługi SOC. Wymaga natomiast, aby podmiot objęty regulacją potrafił skutecznie zarządzać ryzykiem, zapobiegać incydentom, wykrywać je, reagować na nie, ograniczać ich skutki oraz — jeśli spełnione są przesłanki — przekazywać wymagane zgłoszenia o ich wystąpieniu do uprawnionych organów (CSIRT poziomu krajowego lub CSIRT sektorowy).

W praktyce oznacza to zdolność do odpowiedzi na osiem podstawowych pytań:

Jakie usługi, procesy i systemy są krytyczne dla działalności mojej organizacji?
Jakie zagrożenia i podatności mogą zakłócić ich dostępność, integralność, poufność lub autentyczność?
Czy moja organizacja widzi istotne zdarzenia w tych systemach wystarczająco szybko?
Czy a jeśli tak to kto analizuje alerty poza godzinami pracy?
Kto podejmuje decyzję, że zdarzenie może być incydentem poważnym?
Kto odpowiada za kontakt z właściwym CSIRT oraz obsługę systemu S46?
Czy organizacja posiada dowody, że jej procesy rzeczywiście działają?

Ciągły monitoring należy traktować jako element większego systemu zarządzania bezpieczeństwem informacji, powiązany co najmniej z: inwentaryzacją aktywów i usług krytycznych, analizą ryzyka, zarządzaniem tożsamościami i dostępami, zarządzaniem podatnościami, ochroną endpointów/sieci/poczty/chmury, procesem zarządzania incydentami, planami ciągłości działania i odtwarzania po awarii, zarządzaniem dostawcami oraz testami i doskonaleniem procesów.

Najczęstszy błąd to rozpoczęcie od pytania „jaki SIEM powinniśmy kupić?”. Lepsze pytanie brzmi: jakie zdarzenia w naszym środowisku ICT musimy wykryć, kto podejmie decyzję i jakie informacje będą potrzebne w pierwszych godzinach incydentu?

Tabela 1. Co organizacja powinna potrafić wykazać

Obszar	Zdolność organizacyjna	Przykładowy dowód
Monitoring	Zbieranie i analiza kluczowej telemetrii	Mapa źródeł logów, wykaz systemów objętych monitoringiem, konfiguracja retencji
Zarządzanie incydentami	Wykrywanie, triage, klasyfikacja, eskalacja i reakcja	Procedura IR, rejestr incydentów, playbooki, raporty z ćwiczeń
Raportowanie	Terminowe przekazywanie informacji do właściwych podmiotów	Macierz odpowiedzialności, procedura 24/72 h, wzory zgłoszeń, log decyzji
Zarządzanie ryzykiem	Priorytetyzacja działań zgodnie z wpływem na usługi	Rejestr ryzyk, analiza usług krytycznych, plan postępowania z ryzykiem
Doskonalenie	Uczenie się po incydentach i testach	Raport lessons learned, plan działań naprawczych, mierniki KPI/KRI
Dostawcy	Nadzór nad usługami zewnętrznymi i ich rolą w cyberodporności	Umowy, SLA, RACI, wyniki okresowych przeglądów i ćwiczeń

2. Czym w praktyce jest monitoring ciągły

Monitoring w trybie ciągłym to zdolność do stałego zbierania, analizy i korelacji istotnych sygnałów i zdarzeń bezpieczeństwa, ich priorytetyzacji, weryfikacji przez kompetentne osoby oraz uruchomienia reakcji i eskalacji. Nie chodzi o rejestrowanie „wszystkiego” — chodzi o rejestrowanie, przechowywanie i analizowanie właściwych danych dla usług oraz ryzyk istotnych dla organizacji.

Diagram 1. Łańcuch procesu monitoringu ciągłego

Diagram 1. Łańcuch procesu monitoringu ciągłego

Luka na dowolnym etapie tego łańcucha oznacza wykrycie zbyt późne, brak zrozumienia wpływu incydentu albo brak danych potrzebnych do skutecznej reakcji.

Zacznij od usług krytycznych

Punktem wyjścia nie powinien być katalog narzędzi (a narzędzia często potrafią nas oczarować), lecz lista usług krytycznych — np. system obsługi klientów, platforma e-commerce, system płatności, środowisko produkcyjne, system rejestracji pacjentów, logistyka, sterowanie procesem technologicznym, poczta i współpraca, systemy księgowe lub kadrowe, usługi tożsamościowe (Active Directory, Entra ID, IAM).

Dla każdej usługi należy określić: właściciela biznesowego i technicznego, zależne aplikacje/serwery/konta/dostawców, maksymalny akceptowalny czas niedostępności, skutki utraty poufności/integralności/dostępności, wymagania dotyczące logowania i monitoringu oraz sposób eskalacji i kontakty awaryjne. Jeżeli organizacja nie potrafi wskazać, które systemy są krytyczne, nie będzie też w stanie racjonalnie zdecydować, które alerty obsłużyć w pierwszej kolejności.

Minimalna telemetria bezpieczeństwa

Zakres logowania musi wynikać z analizy ryzyka, architektury i charakteru usług. Poniższa tabela to przykładowy, praktyczny punkt startowy, nie uniwersalna lista zakupowa.

Tabela 2. Minimalna telemetria bezpieczeństwa wg obszaru

Obszar	Przykładowe źródła danych	Pytanie kontrolne
Tożsamość i dostęp	Active Directory, Entra ID, IDM, MFA, PAM, VPN	Czy wykrywamy nietypowe logowania, eskalację uprawnień, wyłączenie MFA i nadużycia kont uprzywilejowanych?
Endpointy i serwery	XDR, EDR, MDM, logi Windows/Linux, systemy zarządzania aktualizacjami	Czy widzimy uruchamiane procesy, próby wyłączenia ochrony, izolację hosta oraz zdarzenia administracyjne?
Poczta i współpraca	Microsoft 365, Google Workspace, secure email gateway, DLP	Czy wykryjemy phishing, przejęcie skrzynki, reguły przekierowań i nietypowe eksporty danych?
Sieć	Firewall, VPN, DNS, proxy, IDS/IPS, NDR, Wi-Fi	Czy widzimy podejrzane połączenia, anomalie zdalnego dostępu, ruch do złośliwych domen i eksfiltrację?
Chmura i SaaS	AWS, Azure, GCP, systemy SaaS, CASB	Czy rejestrujemy zmiany konfiguracji, logowania administracyjne, zdarzenia IAM i działania na danych?
Aplikacje i dane	WAF, API gateway, logi aplikacyjne, bazy danych, kolejki	Czy odtworzymy działania administracyjne, błędy aplikacji i zdarzenia naruszające integralność danych?
Backup i DR	Systemy kopii zapasowych, repliki, narzędzia odtwarzania	Czy wykrywamy usuwanie backupów, zmiany retencji, błędne zadania i nieudane odtworzenia?
OT i IoT (jeśli dotyczy)	Segmentacja przemysłowa, bramy OT, systemy sterowania, urządzenia medyczne	Czy monitoring uwzględnia ograniczenia OT i zależność bezpieczeństwa od ciągłości procesu?

Nie wszystkie dane muszą trafiać do jednego narzędzia — ważne jest, aby zespół obsługujący incydent miał dostęp do informacji wystarczających do oceny zdarzenia, ustalenia wpływu i odtworzenia jego przebiegu.

Jakość logów jest równie ważna (a może nawet ważniejsza) jak ich ilość

Duża liczba logów nie gwarantuje skutecznego monitoringu! Warto regularnie sprawdzać: czy czas na wszystkich systemach jest zsynchronizowany, czy logi zawierają identyfikator użytkownika, hosta, adres IP, wynik operacji i czas zdarzenia, czy dostęp do logów jest kontrolowany i audytowany, czy istnieje ryzyko ich usunięcia lub modyfikacji przez napastnika, czy retencja wystarcza do wykrycia kampanii trwającej tygodniami, czy zespół SOC szybko znajduje potrzebne dane oraz czy źródła logów są testowane po zmianach infrastruktury. Nawet najlepszy SIEM nie rozpozna incydentu, jeśli dane dotrą z opóźnieniem, w nieczytelnej formie lub bez kontekstu.

3. Od alertu do zgłoszenia incydentu

Proces raportowania trzeba projektować „od końca”: nie od formularza zgłoszeniowego, lecz od tego, jakie dane organizacja będzie w stanie zebrać i kto podejmie decyzję pod presją czasu.

W reżimie UoKSC kluczowa jest zdolność do wczesnego przekazania informacji o poważnym incydencie, następnie przekazania zgłoszenia oraz przygotowania raportu końcowego.

UoKSC wymaga następującej sekwencji:

wczesne ostrzeżenie o incydencie poważnym do 24 godzin,
zgłoszenie potwierdzenia incydentu poważnego do 72 godzin
raport końcowy w ciągu miesiąca od zgłoszenia.

Diagram 2. Oś czasu raportowania

Diagram 2. Oś czasu raportowania

Alert, zdarzenie, incydent i naruszenie RODO

Z moich doświadczeń jednym z najczęstszych problemów jest mieszanie pojęć odnoszących się do różnych etapów i różnych reżimów prawnych.

Tabela 3. Alert, zdarzenie, incydent, naruszenie RODO

Pojęcie	Co oznacza w praktyce	Przykład
Alert	Sygnał wygenerowany przez narzędzie lub człowieka	EDR zgłasza uruchomienie podejrzanego procesu
Zdarzenie	Zarejestrowana aktywność, która może, ale nie musi mieć znaczenie dla bezpieczeństwa	Nieudane logowanie administratora z nietypowego kraju
Incydent	Zdarzenie wpływające lub potencjalnie wpływające na bezpieczeństwo systemu albo usługi	Przejęcie konta administracyjnego i zmiana konfiguracji
Incydent poważny	Incydent o istotnym wpływie, którego kwalifikacja wymaga oceny wg aktualnych kryteriów	Ransomware powodujący przerwę w krytycznej usłudze
Naruszenie ochrony danych osobowych	Zdarzenie naruszające bezpieczeństwo danych osobowych	Nieuprawniony dostęp do skrzynki z danymi klientów

UWAGA: Jeden incydent może jednocześnie uruchamiać kilka ścieżek: techniczną reakcję, raportowanie w reżimie UoKSC, ocenę naruszenia ochrony danych osobowych, obowiązki kontraktowe wobec klienta, zgłoszenie do ubezpieczyciela cyber i komunikację kryzysową.

Kiedy i dlaczego upływ czasu ma znaczenie

Nie należy czekać z działaniem do pełnego ustalenia przyczyny, zakresu i sprawcy — analiza bywa złożona i może trwać dni lub tygodnie. Proces powinien umożliwiać: szybkie potwierdzenie, czy alert wymaga pilnej analizy; ustalenie, jakich usług, systemów i danych może dotyczyć; wstępną ocenę wpływu; zabezpieczenie dowodów; ograniczenie skutków; uruchomienie właściwej ścieżki decyzyjnej; przekazanie informacji dostępnych na danym etapie; późniejsze uzupełnianie ustaleń. Niepełna wiedza techniczna nie powinna paraliżować procesu — w pierwszych godzinach ważniejsza jest sprawna ocena ryzyka niż perfekcyjny raport techniczny.

Tabela 4. Model operacyjny 24/72 h

Moment	Cel	Co musi zadziałać	Przykładowe role
T0: alert lub podejrzenie	Szybki triage i zabezpieczenie informacji	Kanał 24/7, dostęp do logów, playbook, kontakt do właściciela usługi	SOC/MDR, IT
Pierwsze godziny	Ocena krytyczności, skali i ryzyka	Mapa usług, klasyfikacja aktywów, właściciel biznesowy, działania ograniczające wpływ	IR lead, bezpieczeństwo, IT, biznes
Do 24 h	Wczesne ostrzeżenie, gdy przesłanki są spełnione	Upoważniona osoba, aktualne dane kontaktowe, dostęp do S46, minimalny pakiet informacji	Osoba kontaktowa KSC, właściciel bezpieczeństwa
Do 72 h	Potwierdzone i uzupełnione zgłoszenie	Znane skutki, status, wskaźniki kompromitacji, opis działań i dalszej analizy	IR, bezpieczeństwo, IT, prawnik/IOD
Do miesiąca	Raport końcowy	Analiza przyczyn, opis skutków, działania naprawcze, lessons learned, dowody	Właściciel IR, właściciel bezpieczeństwa, właściciele działań

System S46 służy podmiotom kluczowym i ważnym m.in. do realizacji obowiązków zgłaszania incydentów oraz komunikacji z organami właściwymi dla KSC.

Case study: przejęcie konta administratora

Dostawca MDR wykrywa logowanie do konta administratora Microsoft 365 z nowej lokalizacji, następuje utworzenie reguły automatycznego przekierowania poczty i nietypowe pobrania dokumentów. W poprawnie działającym modelu:

SOC/MDR analizuje alert, weryfikuje podstawowe dane i uruchamia eskalację.
IT blokuje sesje, resetuje poświadczenia, wymusza MFA i zabezpiecza logi.
Właściciel usługi określa, jakie procesy biznesowe i dane mogły zostać dotknięte.
Właściciel bezpieczeństwa koordynuje klasyfikację incydentu i rejestr decyzji.
IOD i prawnik oceniają, czy doszło do naruszenia ochrony danych osobowych.
Osoba kontaktowa KSC ocenia, czy uruchomić właściwą ścieżkę raportową.
Zespół dokumentuje znane fakty, działania ograniczające skutki, niepewności i kolejne kroki.

Dostawca SOC dostarcza analizę techniczną, wskaźniki kompromitacji i dane dowodowe — nie przejmuje jednak automatycznie odpowiedzialności organizacji za ocenę obowiązku i formalne zgłoszenie.

4. SIEM, EDR, XDR, SOC, SOAR, … — co jest potrzebne

Nie istnieje „cudowne rozwiązanie” ani jedno narzędzie, które samo zapewnia monitoring ciągły. Każda technologia pomaga rozwiązywać określony problem, ale zawsze ma też swoje ograniczenia.

Tabela 5. Porównanie rozwiązań technologicznych

Element	Główna wartość	Czego sam nie zastępuje	Kiedy ma zwykle sens
SIEM	Centralizacja logów, korelacja, analiza i retencja	Analityków, pełnego pokrycia telemetrią, procesu IR	Gdy organizacja zbiera dane z wielu domen i potrzebuje jednolitej widoczności
EDR	Detekcja i reakcja na endpointach oraz serwerach	Monitoringu tożsamości, chmury, sieci, aplikacji i decyzji biznesowych	Jako fundament ochrony urządzeń użytkowników i serwerów
XDR	Korelacja danych z endpointów, poczty, tożsamości i chmury	Pełnej widoczności całej organizacji i reakcji po stronie biznesu	Gdy ekosystem jednego dostawcy zapewnia wysokiej jakości telemetrię
SOC/MDR	Stała analiza, triage, eskalacja i wsparcie reakcji	Właściciela ryzyka, decydenta, formalnej odpowiedzialności klienta	Gdy organizacja nie utrzymuje wewnętrznej funkcji analitycznej 24/7
SOAR	Automatyzacja powtarzalnych działań i dokumentowanie playbooków	Dojrzałych procesów, jakości danych, kompetencji analitycznych	Po uporządkowaniu detekcji, eskalacji i procedur IR
NDR	Widoczność i analiza aktywności sieciowej	Pełnej obserwacji endpointów lub aplikacji	W środowiskach z istotnym ruchem wewnętrznym, OT lub systemami legacy

Sam SIEM nie jest ani synonimem SOC ani ciągłego monitorowania

SIEM umożliwia zbieranie i korelowanie danych oraz może wygenerować alert o podejrzanym zachowaniu — nie oznacza to jednak, że ktoś go zinterpretuje, oceni wpływ na usługę i uruchomi reakcję.

SOC to funkcja operacyjna: ludzie, procedury, narzędzia i odpowiedzialność za obsługę alarmów. Wartość SOC wynika nie tylko z obecności analityków, lecz z tego, czy mają oni właściwe dane, uprawnienia, playbooki i ścieżki eskalacji.

XDR nie eliminuje potrzeby zarządzania logami

XDR może bardzo skutecznie korelować dane w obrębie ekosystemu jednego producenta — endpointów, poczty, tożsamości, chmury — ale nie musi obejmować wszystkich systemów krytycznych, urządzeń sieciowych, aplikacji własnych, systemów legacy, środowisk OT czy usług dostawców.

Istotną wartością XDR jest również zintegrowana odpowiedź na incydent: na podstawie skorelowanego kontekstu może on przyspieszać triage i dochodzenie oraz uruchamiać skoordynowane działania ograniczające skutki ataku, np. izolację endpointu, blokadę wskaźników kompromitacji, zawieszenie konta lub unieważnienie sesji. Dzięki temu XDR nie tylko poprawia jakość detekcji, lecz także skraca czas od wykrycia do ograniczenia skutków i redukuje liczbę ręcznych czynności SOC.

Przed decyzją „SIEM czy XDR” warto odpowiedzieć na trzy pytania: jakie systemy krytyczne są poza ekosystemem głównego dostawcy bezpieczeństwa, czy organizacja potrzebuje długiej retencji i analizy danych z wielu źródeł, oraz czy zespół może wykrywać zagrożenia i prowadzić dochodzenia wyłącznie na danych dostępnych w XDR.

W wielu organizacjach sensowny jest model mieszany: EDR/XDR zapewnia szybką widoczność w najważniejszych domenach, a SIEM lub platforma log management agreguje dane z systemów dodatkowych i wspiera analizę incydentów.

5. Jaki model operacyjny wybrać

Model działania powinien wynikać z ryzyka, skali środowiska, dostępnych kompetencji, budżetu i wymaganej szybkości reakcji — nie z mody na budowanie własnego SOC.

Wewnętrzny SOC może mieć sens, gdy organizacja prowadzi działalność wymagającą szczególnie wysokiej kontroli nad danymi i reakcją, posiada złożone, rozproszone środowisko, ma wystarczającą liczbę specjalistów do pracy zmianowej, może zapewnić rozwój kompetencji i use case’ów, oraz realizuje wiele podobnych procesów bezpieczeństwa w grupie kapitałowej. Największym wyzwaniem pozostaje rzeczywista dostępność 24/7, jakość analityki i rotacja zespołu.

Model hybrydowy jest optymalny dla wielu organizacji objętych UoKSC: zewnętrzny SOC/MDR prowadzi monitoring, triage i eskalację 24/7; organizacja zachowuje właściciela bezpieczeństwa; IT odpowiada za działania techniczne; właściciele biznesowi oceniają wpływ na usługi; kierownictwo podejmuje decyzje biznesowe; osoba kontaktowa KSC koordynuje formalną komunikację; IOD i prawnik obsługują ocenę obowiązków związanych z danymi osobowymi, umowami i komunikacją formalną.

Model ten zwykle pozwala szybciej uzyskać dostęp do analityki 24/7, ale wymaga bardzo dobrego podziału odpowiedzialności.

Zewnętrzny SOC/MDR może być praktycznym rozwiązaniem, ale nie może stać się outsourcingiem odpowiedzialności. Przed podpisaniem umowy warto ustalić: jakie systemy i źródła danych są objęte usługą, co dokładnie oznacza „monitoring 24/7”, jak szybko dostawca dokonuje triage’u i eskalacji, kto i w jakich warunkach może odizolować urządzenie, zablokować konto lub zmienić regułę firewall, jakie dane i raporty otrzyma organizacja, jak wygląda wsparcie w trakcie incydentu, czy dostawca przeprowadzi ćwiczenie procesu eskalacji oraz jak wygląda przekazanie danych i konfiguracji po zakończeniu umowy.

Tabela 6. Przykładowa macierz odpowiedzialności (RACI)

Działanie	SOC/MDR	IT	Właściciel bezpieczeństwa	Kierownictwo / zarząd	IOD / prawnik
Wykrycie i triage alertu	R	C	A	I	I
Izolacja techniczna	C lub R (zależnie od umowy)	R	A	I	I
Ocena wpływu na usługę	C	C	R	A	C
Decyzja o zgłoszeniu UoKSC	C	C	R	A	C
Formalne zgłoszenie przez S46	C	I	R	A	C
Ocena obowiązków RODO	I	I	C	A	R
Raport końcowy i lessons learned	C	R	A	I	C

R — realizuje, A — zatwierdza i ponosi odpowiedzialność, C — jest konsultowany, I — jest informowany.

Macierz należy dopasować do rzeczywistej struktury organizacji — w małej firmie jedna osoba może pełnić kilka ról. Kluczowe jest jednak wyeliminowanie wątpliwości: kto odbiera eskalację o 2:00 w nocy, kto zatwierdza działania ograniczające skutki i kto może podjąć decyzję o uruchomieniu ścieżki raportowej.

6. Jak wybrać dostawcę SOC lub MDR

Wybierając dostawcę, nie warto ograniczać się do pytania o liczbę analityków, listę certyfikatów czy logo technologii. Najważniejsze są warunki rzeczywistego działania w incydencie.

Dziesięć pytań do dostawcy:

Czy monitoring działa rzeczywiście 24/7/365, czy tylko alerty są automatycznie generowane poza godzinami pracy?
Jakie są gwarantowane czasy triage’u, eskalacji i powiadomienia, rozdzielone według krytyczności incydentu?
Które źródła telemetrii będą objęte usługą od pierwszego dnia, a które wymagają dodatkowej integracji?
Czy dostawca identyfikuje luki w widoczności i rekomenduje plan rozbudowy źródeł logów?
Jak obsługiwane są środowiska hybrydowe: M365/Google Workspace, infrastruktura lokalna, chmura, aplikacje własne, VPN, firewalle, backup i OT?
Kto i na jakiej podstawie może podjąć działania ograniczania skutków ataku — izolację endpointu, zablokowanie konta, zablokowanie ruchu sieciowego?
Gdzie przechowywane są dane telemetryczne, jaka jest retencja i jak organizacja uzyska dostęp do danych i eksportów?
Czy dostawca wesprze analizę techniczną i przygotowanie danych do zgłoszenia, bez tworzenia wrażenia, że przejmuje odpowiedzialność regulacyjną klienta?
Czy usługa obejmuje regularny tuning detekcji, threat hunting, raporty zarządcze i ćwiczenia playbooków?
Co organizacja otrzyma po zakończeniu umowy: logi, raporty, konfigurację, reguły detekcji, dokumentację i historię incydentów?

Czerwone flagi w umowie:

„24/7” oznaczające jedynie automatyczne wysyłanie e-maili;
SLA obejmujące wyłącznie czas reakcji na zgłoszenie klienta, a nie czas triage’u alertów; brak zdefiniowanych źródeł danych objętych monitoringiem;
brak dostępu klienta do danych, raportów lub historii incydentów;
niejasne zasady containment; obowiązki eskalacji pomijające właścicieli usług i osoby decyzyjne;
brak propozycji testów, ćwiczeń i rozwoju use case’ów;
nieprzewidywalny koszt obsługi realnego incydentu;
brak zapisów o przekazaniu danych i konfiguracji po zakończeniu umowy.

7. Roadmapa wdrożenia monitoringu ciągłego

Budowę zdolności monitoringu ciągłego warto podzielić na etapy — to pozwala uniknąć wielomiesięcznego projektu narzędziowego bez efektu operacyjnego.

Tabela 7. Roadmapa wdrożenia

Horyzont	Priorytetowe działania	Rezultat
0–30 dni	Określenie usług krytycznych, właścicieli, zakresu obowiązków, stanu telemetrii i procedur	Mapa zakresu, RACI, lista najważniejszych luk, plan działań
31–90 dni	Uruchomienie minimalnej telemetrii, modelu SOC/MDR, rejestru incydentów, kanału eskalacji 24/7 i procedury raportowej	Działająca ścieżka wykrycia, analizy, eskalacji i decyzji
91–180 dni	Rozbudowa źródeł danych, tuning detekcji, ćwiczenie tabletop, integracja z BCP/DR i dostawcami	Przetestowana zdolność operacyjna, mierzalne pokrycie środowiska
181–365 dni	Ćwiczenia pełnoskalowe, testy techniczne, audyt gotowości, aktualizacja umów, rozwój KPI/KRI	Udokumentowane dowody działania, ciągłe doskonalenie

Diagram 3. Oś czasu wdrożenia

Diagram 3. Oś czasu wdrożenia

Etap 0–30 dni — podstawa decyzyjna. W pierwszym miesiącu nie trzeba wdrażać wszystkich narzędzi. Należy natomiast: zidentyfikować usługi krytyczne, przypisać właścicieli biznesowych i technicznych, ustalić aktualne źródła logów, ocenić pokrycie endpointów, tożsamości, poczty, chmury i sieci, określić brakujące kontakty i uprawnienia awaryjne, przeanalizować obecny proces IR, zdecydować o modelu docelowym (SOC wewnętrzny, hybrydowy czy MDR) oraz wyznaczyć właściciela programu.

Etap 31–90 dni — minimalna zdolność. Kluczowe jest osiągnięcie minimalnego, ale działającego procesu: monitoring najważniejszych aktywów i usług, dostępny poza godzinami pracy kanał eskalacji, właściciel każdego istotnego alertu, rejestr incydentów, podstawowe playbooki (phishing, przejęcie konta, ransomware, naruszenie dostępności, wyciek danych), osoby kontaktowe i procedura komunikacji oraz test pierwszego scenariusza w warunkach zbliżonych do realnych.

Uwaga: organizacja nie musi mieć na tym etapie perfekcyjnego pokrycia wszystkich systemów — musi jednak wiedzieć, czego nie widzi i jak zamierza tę lukę zamknąć.

Etap 91–180 dni — doskonalenie widoczności i reakcji. Po uruchomieniu podstaw należy: objąć monitoringiem kolejne źródła, poprawić jakość logów, dostroić reguły detekcji, ograniczyć liczbę fałszywych alertów, rozwinąć use case’y oparte na realnych zagrożeniach, przetestować eskalację do kierownictwa, połączyć monitoring z BCP/DR i zarządzaniem dostawcami oraz wprowadzić raportowanie dla zarządu.

Etap 181–365 dni — potwierdzenie gotowości. Dojrzałość należy potwierdzać, nie deklarować: ćwiczenie tabletop dla scenariusza incydentu poważnego, ćwiczenie techniczne obejmujące SOC/MDR, IT i właścicieli biznesowych, test ścieżki eskalacji poza godzinami pracy, przegląd umów z dostawcami, ocena jakości retencji i dostępności logów, wewnętrzny audyt gotowości oraz aktualizacja planów działań i rejestru ryzyk.

8. Jak mierzyć skuteczność monitoringu

Liczba alertów nie jest dobrym wskaźnikiem poziomu zarządzania cyberbezpieczeństwem — może oznaczać zarówno dobrą widoczność, jak i źle skonfigurowane narzędzia. Raport dla zarządu powinien pokazywać, czy organizacja potrafi wykryć i ograniczyć zagrożenia dla usług krytycznych.

Tabela 8. Metryki operacyjne i zarządcze

Miernik	Co pokazuje	Na co uważać
Pokrycie telemetryczne aktywów krytycznych	Czy organizacja widzi systemy najważniejsze dla działalności	Wysoki procent może ukrywać brak monitoringu pojedynczego, ale kluczowego systemu
MTTD (czas wykrycia)	Średni czas wykrycia incydentu	Analizuj osobno różne klasy zagrożeń
MTTA (czas reakcji na alert)	Czas przejęcia i oceny alertu	Szczególnie ważny przy modelu SOC/MDR 24/7
Czas eskalacji	Jak szybko właściwy decydent otrzymuje informację	Powinien być mierzony od momentu potwierdzenia istotności
MTTR (czas usunięcia skutków)	Czas ograniczenia i usunięcia skutków	Nie premiuj pozornie szybkiego zamykania trudnych incydentów
Jakość detekcji	Przydatność reguł i alertów	Uwzględnij false positives, false negatives i luki wykryte w ćwiczeniach
Pokrycie testowanych playbooków	Czy procedury działają w praktyce	Sama obecność dokumentu nie jest dowodem gotowości
Zamknięte działania po incydentach	Czy organizacja faktycznie się doskonali	Mierz terminowość i skuteczność działań naprawczych

Dobre raportowanie zarządcze nie powinno ograniczać się do wykresu liczby alertów. Powinno pokazywać relację między ryzykiem, krytycznymi usługami, lukami w widoczności, zdolnością reakcji i planem poprawy.

9. Relacja UoKSC–RODO

UODO wskazuje, że obowiązki RODO mogą funkcjonować równolegle wobec obowiązków wynikających z UoKSC. W przypadku RODO zgłoszenie naruszenia do organu nadzorczego następuje bez zbędnej zwłoki, w miarę możliwości nie później niż w ciągu 72 godzin od stwierdzenia naruszenia; reżim UoKSC ma własny, wieloetapowy tryb zgłaszania.

Incydent dotyczący dostępności systemu może nie obejmować danych osobowych, a naruszenie ochrony danych osobowych nie zawsze będzie incydentem o znaczeniu w reżimie UoKSC. Wiele sytuacji będzie jednak wymagało równoległej oceny przez zespół bezpieczeństwa, IOD i prawników.

Rekomendacja operacyjna: proces zarządzania incydentami powinien mieć wbudowany punkt decyzyjny „czy uruchamiamy ścieżkę RODO równolegle do ścieżki UoKSC”, z jasno przypisaną odpowiedzialnością — patrz macierz RACI w Tabeli 6.

10. Najczęstsze błędy

„Kupiliśmy SIEM, więc mamy monitoring ciągły.” SIEM bez odpowiednich danych, reguł, analityków i procedur jest przede wszystkim kosztownym repozytorium logów. Przed zakupem należy zdefiniować, jakie przypadki użycia, źródła danych i procesy organizacja chce obsłużyć oraz czy posiada wystarczającą liczbę kompetentnych specjalistów, którzy będą potrafili to narzędzie wykorzystać.

„EDR działa na większości komputerów.” „Większość” nie zawsze jest właściwym kryterium — brak widoczności na jednym serwerze tożsamości, systemie płatności czy urządzeniu administracyjnym może stworzyć poważną lukę.

„Mamy SOC 24/7.” Warto sprawdzić, czy oznacza to rzeczywistą analizę i eskalację przez całą dobę, czy wyłącznie automatyczne powiadomienie na skrzynkę administratora.

„Dostawca odpowiada za raportowanie.” Dostawca może wspierać zbieranie danych i analizę techniczną. Organizacja powinna jednak zachować własność procesu, wyznaczone osoby, kompetencję decyzyjną i zdolność formalnego działania.

„Zgłosimy incydent, gdy będziemy znali przyczynę.” Czekanie na kompletną analizę może powodować utratę czasu. Proces powinien umożliwiać podejmowanie decyzji i przekazywanie dostępnych informacji, a następnie ich aktualizowanie.

„Mamy procedurę, więc jesteśmy gotowi.” Procedura nieprzetestowana w warunkach presji czasu jest hipotezą. Ćwiczenie tabletop i test kontaktów często ujawniają istotne braki: nieaktualne numery telefonów, niejasne uprawnienia, brak dostępu do systemów lub niezdefiniowane decyzje.

„Mamy logi.” Trzeba jeszcze wiedzieć, czy są kompletne, spójne czasowo, chronione przed modyfikacją, dostępne dla analityków i przechowywane odpowiednio długo.

„Jeden proces obsłuży wszystkie obowiązki.” Ten sam incydent może wymagać równoległej obsługi technicznej, raportowania UoKSC, oceny RODO, działań kontraktowych, komunikacji z klientami i uruchomienia planów BCP/DR. Procesy muszą być połączone, ale nie powinny być ze sobą mylone.

11. Checklista: czy moja organizacja jest gotowa?

Czy znamy usługi, których zakłócenie może mieć istotny wpływ na działalność?
Czy każda usługa krytyczna ma właściciela biznesowego i technicznego?
Czy wiemy, które systemy, konta i dostawcy wspierają te usługi?
Czy posiadamy aktualną mapę źródeł logów i telemetrii?
Czy zidentyfikowaliśmy krytyczne ślepe punkty monitoringowe?
Czy chronimy i monitorujemy konta uprzywilejowane?
Czy monitoring i triage działają 24/7/365?
Czy wiadomo, kto odbiera eskalację poza godzinami pracy?
Czy mamy aktualne dane kontaktowe do właścicieli usług, IT, bezpieczeństwa, IOD i kierownictwa?
Czy proces rozróżnia alert, incydent, incydent poważny oraz naruszenie ochrony danych?
Czy osoby odpowiedzialne za KSC posiadają uprawnienia i dostęp do niezbędnych narzędzi?
Czy testowaliśmy scenariusz, w którym decyzja musi zostać podjęta w ciągu pierwszych 24 godzin?
Czy umowa z SOC/MDR opisuje źródła danych, SLA, eskalację, containment oraz przekazanie danych?
Czy posiadamy rejestr incydentów oraz rejestr decyzji?
Czy po incydentach i ćwiczeniach realizujemy działania naprawcze?
Czy zarząd otrzymuje informacje o ryzyku, widoczności i gotowości, a nie tylko o liczbie alertów?

Jeżeli większość odpowiedzi brzmi „częściowo” lub „nie”, organizacja powinna zacząć od warsztatu zakresowego, a nie od zakupu kolejnej technologii czy usługi z rynku …

12. FAQ

Czy UoKSC wymaga wdrożenia SIEM? UoKSC nie wskazuje konkretnego produktu ani producenta. Organizacja musi jednak zapewnić zdolność do monitorowania, wykrywania, analizy, obsługi i raportowania incydentów. W wielu środowiskach SIEM może być ważnym elementem tej zdolności, ale sam jej nie gwarantuje.

Czy XDR zastępuje SIEM i SOC? XDR może rozszerzyć widoczność i korelację danych w określonym ekosystemie technologicznym. Nie zastępuje jednak wszystkich źródeł logów, procesu zarządzania incydentami, właścicieli ryzyka ani ludzi analizujących i podejmujących decyzje. To, czy ograniczy potrzebę SIEM, zależy od architektury i zakresu telemetrii. Co do zasady każda inna platforma log management, która agreguje dane z systemów dodatkowych i wspiera analizę incydentów może być wystarczająca w wielu przypadkach.

Czy można korzystać z zewnętrznego SOC lub MDR? Tak, outsourcing może być rozsądnym sposobem na zapewnienie analityki i eskalacji 24/7. Organizacja nie powinna jednak przenosić na dostawcę swojej odpowiedzialności za ryzyko, decyzje, raportowanie i relację z organami.

Czy dostawca SOC może sam zgłosić incydent przez S46? Dostawca może wspierać analizę i przygotowanie informacji. Właściciel obowiązku oraz formalny model zgłoszenia powinny wynikać z aktualnych przepisów, upoważnień i wewnętrznych procedur organizacji — warto to wyraźnie opisać w RACI i umowie.

Kiedy rozpoczyna się termin raportowania? Właściwy moment zależy od aktualnych przepisów i kwalifikacji incydentu. Organizacja musi mieć procedurę pozwalającą szybko ustalić, kiedy zdarzenie zostało wykryte, kto dokonał oceny oraz kiedy uruchomiono ścieżkę raportową. Nie należy czekać na zakończenie pełnej analizy technicznej, jeżeli przesłanki wskazują na konieczność działania.

Czy incydent UoKSC zawsze oznacza naruszenie RODO? Nie. Incydent dotyczący dostępności systemu może nie obejmować danych osobowych, a naruszenie ochrony danych osobowych nie zawsze będzie incydentem o znaczeniu w reżimie UoKSC. Wiele sytuacji będzie jednak wymagało równoległej oceny przez zespół bezpieczeństwa, IOD i prawników.

Jak długo należy przechowywać logi? Nie ma jednej wartości właściwej dla wszystkich organizacji. Retencja powinna wynikać z analizy ryzyka, charakteru usług, cyklu wykrywania zagrożeń, zobowiązań umownych, regulacji sektorowych i potrzeb dochodzeniowych. Kluczowe jest, aby organizacja potrafiła uzasadnić przyjęty okres i zapewnić dostępność danych podczas analizy incydentu.

Ilu pracowników potrzeba do monitoringu 24/7? Utrzymanie pełnej funkcji SOC 24/7 wewnętrznie wymaga znacznie więcej niż jednej lub dwóch osób. Z tego powodu wiele organizacji korzysta z modelu hybrydowego lub MDR. Niezależnie od wybranego modelu po stronie organizacji muszą pozostać właściciele ryzyka, osoby decyzyjne i kompetencje do wdrażania działań technicznych.

Podsumowanie

Monitoring ciągły nie zaczyna się od zakupu licencji SIEM, XDR ani podpisania umowy z SOC. Zaczyna się od zrozumienia usług krytycznych, ryzyk, odpowiedzialności i decyzji, które organizacja musi podjąć w pierwszych godzinach incydentu.

Technologia ma skrócić drogę do właściwego działania. SOC lub MDR ma zapewnić analizę i eskalację. Żadne z tych rozwiązań nie zastąpi jednak właścicieli procesu, przetestowanego modelu raportowania, dobrej jakości telemetrii ani gotowości kierownictwa do podejmowania decyzji.

Organizacja, która chce przygotować się do wymagań UoKSC, powinna zacząć od pięciu kroków: