SOC 24/7 w 2026 r. - jak działa, czego wymaga prawo i jak ocenić jego skuteczność

SOC obserwuje środowisko, kwalifikuje alarmy, prowadzi dochodzenie techniczne, ogranicza skutki incydentów i przekazuje sprawy do właścicieli systemów, kierownictwa lub właściwych zespołów reagowania. Łączy więc analizę techniczną z procesem decyzyjnym. Informacja, że konto wykonało nietypową operację, jest tylko początkiem. Analityk powinien wiedzieć, czy konto jest uprzywilejowane, jaki zasób został użyty, jaki proces biznesowy zależy od tego zasobu oraz jakie skutki może wywołać blokada konta albo izolacja urządzenia.

Pojęcia używane przy opisie usług bezpieczeństwa nie są zamienne.

• SIEM (Security Information and Event Management) służy do gromadzenia, wyszukiwania, normalizacji i korelacji danych o zdarzeniach. Jest narzędziem wspierającym operacje, a nie zespołem reagowania.
• SOAR (Security Orchestration, Automation and Response) integruje narzędzia bezpieczeństwa i uruchamia zdefiniowane przepływy działania. Może automatyzować wzbogacenie alarmu, utworzenie sprawy, pobranie dodatkowej telemetrii, izolację urządzenia, unieważnienie sesji albo blokadę konta. Automatyzacja nie usuwa jednak ryzyka błędnej decyzji. Działania o dużym wpływie powinny mieć jasno określone warunki, zakres uprawnień, ślad audytowy i, gdy to potrzebne, zatwierdzenie człowieka ^[17].
• SOC jest zdolnością organizacyjną do wykrywania, analizy i reakcji. Może działać wewnątrz organizacji, jako usługa zewnętrzna albo w modelu współzarządzanym.
• CSIRT jest zespołem reagowania na incydenty z określonym zakresem odpowiedzialności i grupą podmiotów, które obsługuje. Nazwa CERT jest powszechnie używana w podobnym kontekście, ale sama nazwa zespołu nie przesądza o jego kompetencjach. W KSC ustawowo zdefiniowano między innymi CSIRT MON, CSIRT NASK, CSIRT GOV i CSIRT sektorowe ^[8].
• MDR (Managed Detection and Response) oznacza usługowe dostarczenie części lub całości zdolności wykrywania i reagowania. Jedna oferta MDR może obejmować tylko urządzenia końcowe, a inna także tożsamości, sieć, pocztę, chmurę i aplikacje. Nazwa usługi nie mówi więc jeszcze, jakie źródła danych są obserwowane i co dostawca może zrobić po wykryciu zagrożenia.

Własny SOC daje organizacji największą bezpośrednią kontrolę nad personelem, telemetrią i reakcją, ale wymaga kompetencji, dyżurów, utrzymania platformy i stałego rozwoju detekcji. Model zewnętrzny pozwala korzystać z wyspecjalizowanego zespołu i infrastruktury dostawcy, lecz zwiększa znaczenie umowy, integracji technicznej, nadzoru oraz kwestii jurysdykcji danych. Model współzarządzany dzieli zadania: na przykład dostawca prowadzi monitoring i pierwszą analizę, a klient zachowuje decyzje dotyczące krytycznych systemów. Badanie Kokulu i współautorów, oparte na 18 wywiadach z analitykami i menedżerami SOC, pokazuje znaczenie dopasowania sposobu organizacji SOC do realnych warunków pracy, w tym relacji między personelem, zarządzaniem i technologią ^[3].

Tryb 24/7 ma sens wtedy, gdy krytyczna usługa działa bez przerwy, skutki opóźnionej reakcji szybko rosną albo procedury i przepisy wymagają krótkiej eskalacji. Nie oznacza to, że każda specjalistyczna rola musi być stale obsadzona przy stanowisku. Model może łączyć całodobową pierwszą linię z dyżurem specjalistów i osób decyzyjnych. Ważniejsze od deklaracji "24/7" jest to, kto rzeczywiście odbierze alarm o 03:00, jakie ma uprawnienia, w jakim czasie może eskalować sprawę i czy po stronie klienta istnieje osoba zdolna zatwierdzić działanie wpływające na usługę.

SOAR może mieć dostęp do logów, danych o tożsamościach, konfiguracji zabezpieczeń, tokenów API, informacji o podatnościach oraz materiału dowodowego z incydentów. W praktyce jest więc elementem infrastruktury o wysokim poziomie zaufania. W modelu rozwijanym przez 4crypto system SOAR jest projektowany tak, aby podstawowe procesy automatyzacji i obsługi zdarzeń mogły działać w kontrolowanym środowisku bez konieczności przekazywania operacyjnych danych klientów do zewnętrznych usług automatyzacji lub generatywnej AI poza przyjętą architekturą. Jest to opis założenia projektowego, a nie samodzielny dowód bezpieczeństwa.

Sam adres serwera w Polsce lub EOG nie wystarcza, aby uznać usługę za suwerenną. Trzeba sprawdzić właściciela infrastruktury, jurysdykcję podmiotów uczestniczących w świadczeniu usługi, podwykonawców, zdalny dostęp administracyjny, telemetrię produktu, kopie zapasowe, zarządzanie kluczami, proces aktualizacji oraz połączenia wychodzące. Jeżeli w logach znajdują się dane osobowe, transfer do państwa trzeciego podlega zasadom rozdziału V RODO ^[14]. Dla podmiotów objętych KSC bezpieczeństwo łańcucha dostaw jest jednym z elementów zarządzania ryzykiem ^[8]. Deklarację dostawcy o lokalnym przetwarzaniu warto więc weryfikować architekturą, umową, listą podmiotów przetwarzających i obserwacją rzeczywistego ruchu sieciowego.

Praca SOC tworzy cykl, w którym jakość każdego etapu ogranicza jakość następnego. Automatyzacja nie naprawi brakującej telemetrii, a rozbudowany SIEM nie pomoże, jeżeli nie wiadomo, które zasoby są krytyczne.

Zakres i priorytety. Najpierw trzeba określić usługi, systemy, tożsamości i przepływy danych, których utrata poufności, integralności lub dostępności miałaby istotny skutek. Z tego wynikają scenariusze zagrożeń, wymagane źródła danych i kolejność reakcji. Sama lista urządzeń nie pokazuje zależności biznesowych.

Stan telemetrii. SOC powinien wiedzieć nie tylko, jakie logi zbiera, ale także czy źródła działają. Trzeba kontrolować kompletność danych, opóźnienie, synchronizację czasu, jakość pól, integralność, retencję i możliwość bezpiecznego eksportu. Brak zdarzeń z krytycznego kontrolera domeny albo bramy VPN powinien być widoczny jako problem z sensorem, a nie traktowany jako oznaka spokojnej nocy.

Kontekst. Zdarzenie staje się użyteczne po powiązaniu go z właścicielem zasobu, jego krytycznością, rolą użytkownika, znanymi podatnościami, zmianami administracyjnymi i wcześniejszą aktywnością. Geolokalizacja adresu IP czy wskaźnik reputacji są poszlakami. Nie są samodzielnym dowodem włamania.

Detekcja. Reguła powinna odpowiadać określonej hipotezie: jakie zachowanie chcemy wykryć, jakiej telemetrii potrzebujemy i jakie legalne działania mogą wyglądać podobnie. MITRE ATT&CK pomaga uporządkować wiedzę o taktykach i technikach przeciwnika oraz powiązać ją z detekcją. Na 29 sierpnia 2026 r. dostępne są dane ATT&CK v19.2, w tym osobne zbiory Detection Strategies i Analytics ^[19]. Mapa ATT&CK nie jest jednak wynikiem testu. Samo oznaczenie techniki jako "covered" nie dowodzi, że konkretna reguła zadziała na dostępnej telemetrii.

Ocena i dochodzenie. Analityk powinien ustalić, czy alarm opisuje rzeczywistą aktywność, jaki jest jej zasięg i wpływ oraz czego jeszcze nie wiadomo. Dobre dochodzenie jest odtwarzalne: zawiera oś czasu, źródła danych, dowody, hipotezy i poziom pewności. Ważne jest także rozdzielenie faktów od wniosków analityka.

Reakcja. Izolacja urządzenia, unieważnienie sesji, zablokowanie konta lub adresu może ograniczyć szkodę, ale może również zatrzymać legalny proces. Automatyczna reakcja powinna być oparta na wcześniej zatwierdzonym scenariuszu i ograniczona do przypadków, w których koszt fałszywej reakcji jest akceptowalny. NIST SP 800-61 Rev. 3 traktuje reagowanie na incydenty jako część szerszego zarządzania ryzykiem i łączy przygotowanie, wykrywanie, reakcję oraz odtwarzanie z funkcjami NIST CSF 2.0 ^[17][20].

Uczenie się. Po incydencie trzeba poprawić reguły, źródła danych, konfigurację, architekturę, procedury i szkolenia. Jeżeli przyczyną skutecznego phishingu była słaba konfiguracja poczty, samo zamknięcie incydentu nie rozwiązuje problemu. W takim przypadku znaczenie może mieć przegląd SPF, DKIM i DMARC, analiza procesu uwierzytelniania oraz Security Awareness. Jeżeli wejście nastąpiło przez podatną usługę brzegową, potrzebne mogą być skanowanie podatności, hardening albo test penetracyjny. Te działania uzupełniają SOC, ale go nie zastępują.

SOC nie widzi wszystkiego. Szyfrowanie ogranicza możliwość analizy treści. Część usług SaaS udostępnia ograniczoną telemetrię albo wymaga wyższej licencji do rejestrowania zdarzeń administracyjnych. Urządzenie brzegowe może zostać przejęte zanim wyśle alarm, agent EDR może zostać wyłączony, a lokalny log usunięty. Z tego powodu architektura detekcji powinna obejmować kontrolę stanu źródeł danych, rozproszenie dowodów i - dla najważniejszych zdarzeń - możliwość weryfikacji z więcej niż jednego źródła.

Brak alarmu nie jest dowodem braku ataku. Jest jedynie informacją, że przy dostępnych danych i regułach nic nie wywołało alarmu.

Raporty Mandiant, Verizon, ENISA i CERT Polska opisują różne populacje, stosują różne definicje i powstają z innych źródeł danych. Nie należy zestawiać ich procentów tak, jakby mierzyły ten sam rynek. Są przydatne do obserwowania rodzajów problemów widocznych w konkretnych zbiorach, ale nie pozwalają obiecać skuteczności konkretnego SOC.

Mandiant M-Trends 2026 opiera się na ponad 500 tys. godzin dochodzeń prowadzonych przez Mandiant w 2025 r. Globalna mediana dwell time, czyli czasu od kompromitacji do wykrycia, wyniosła 14 dni wobec 11 dni rok wcześniej. Dla analizowanych spraw cyberszpiegowskich oraz incydentów związanych z północnokoreańskimi pracownikami IT mediana wyniosła 122 dni. Wykorzystanie podatności odpowiadało za 32% obserwowanych przez Mandiant początkowych wektorów infekcji ^[4]. Są to dane z dochodzeń Mandiant, a nie uniwersalna statystyka dla wszystkich organizacji.

Verizon DBIR 2026 analizuje ponad 31 tys. incydentów, w tym ponad 22 tys. potwierdzonych naruszeń danych dotyczących organizacji w 145 państwach ^[5]. W publicznym podsumowaniu Verizon wskazuje, że 31% naruszeń rozpoczynało się od wykorzystania podatności oprogramowania, a ransomware występował w 48% naruszeń ^[5]. Sam DBIR zastrzega, że opisuje zdarzenia, które znalazły się w zbiorze i spełniły kryteria raportu. Procenty nie są więc prawdopodobieństwem, że dowolna organizacja doświadczy danego typu naruszenia.

ENISA Threat Landscape 2025 obejmuje 4875 incydentów z okresu od 1 lipca 2024 r. do 30 czerwca 2025 r. DDoS stanowił 77% raportowanych incydentów i był w dużej części związany z haktywizmem, natomiast ransomware zostało ocenione przez ENISA jako zagrożenie o największym wpływie w UE ^[6]. Widać tu ważne rozróżnienie: liczba zdarzeń i dotkliwość ich skutków to dwie różne miary.

CERT Polska w raporcie za 2025 r. podaje 658 320 zgłoszeń i 260 783 zarejestrowane unikalne incydenty. Oszustwa komputerowe stanowiły 253 238 incydentów, czyli 97,1% wszystkich zarejestrowanych ^[7]. Raport wskazuje również, że wzrost liczby zgłoszeń i rejestrowanych incydentów jest związany między innymi z rosnącą świadomością oraz rolą zespołu w monitorowaniu i analizie. Z tych danych nie można więc wprost wyprowadzić wniosku, że liczba skutecznych cyberataków wzrosła w takim samym tempie.

Wspólny praktyczny wniosek z tych źródeł jest szerszy niż samo wdrożenie EDR. Program detekcji powinien uwzględniać urządzenia końcowe, tożsamości, usługi internetowe, systemy brzegowe, chmurę, pocztę i zależności od dostawców, ponieważ istotne ścieżki ataku nie kończą się na stacji roboczej.

Badanie Alahmadi, Axon i Martinovica obejmowało ankietę internetową wśród 20 praktyków pracujących w SOC oraz następujące po niej jakościowe badanie z udziałem 21 praktyków ^[2]. Autorzy zwrócili uwagę, że część alarmów określanych przez praktyków jako fałszywe alarmy (false positives) była w rzeczywistości poprawnym wykryciem legalnej aktywności. To ważne rozróżnienie: narzędzie może prawidłowo wykryć zachowanie odpowiadające regule, lecz alarm nadal nie wymaga reakcji na incydent.

Tytuł publikacji "99% False Positives" nie oznacza, że 99% alarmów w typowym SOC jest błędnych. Badanie nie ustanawia takiej uniwersalnej wartości. Pokazuje natomiast problem jakości i interpretowalności alarmów oraz potrzebę kontekstu umożliwiającego szybką walidację ^[2].

Dobre strojenie detekcji nie polega wyłącznie na zmniejszaniu liczby alertów. Zbyt agresywne filtrowanie może obniżyć liczbę fałszywych alarmów kosztem przeoczonych zdarzeń. Trzeba więc obserwować jednocześnie jakość alarmów, pokrycie scenariuszy, wyniki testów i zdarzenia wykryte inną drogą.

Organizacja może przetwarzać miliony zdarzeń dziennie, a jednocześnie nie rejestrować zmian konfiguracji w chmurze, operacji administratorów, aktywności na koncentratorach VPN, użycia tokenów aplikacyjnych albo zmian zasad dostępu. Duży wolumen danych nie oznacza szerokiej widoczności.

Pokrycie warto opisywać przez parę: scenariusz zagrożenia - wymagana telemetria. Następnie trzeba sprawdzić, czy dane rzeczywiście docierają, czy detekcja potrafi je rozpoznać i czy reakcja działa. NIST CSF 2.0 może pomóc uporządkować oczekiwane wyniki programu bezpieczeństwa ^[20], a ATT&CK służyć jako model zachowań przeciwnika ^[19]. Żaden z tych dokumentów nie zastępuje kontrolowanego testu we własnym środowisku.

Test może mieć różną skalę: od odtworzenia pojedynczego zdarzenia administracyjnego, przez ćwiczenie purple team, po pełny test penetracyjny z uzgodnionym celem. Ważne, aby rezultat odpowiadał na pytanie, czy organizacja potrafi zaobserwować i poprawnie obsłużyć konkretny scenariusz.

SOAR skraca czas wykonywania powtarzalnych czynności i pomaga zachować jednolity przebieg reakcji. Ten sam mechanizm może jednak szybko powiększyć skutek błędu. Automatyczna izolacja zwykłej stacji roboczej i automatyczne odcięcie kontrolera domeny, węzła klastra albo elementu OT mają zupełnie inne ryzyko operacyjne.

Dlatego działania powinny być podzielone według wpływu. Część może być wykonywana automatycznie, na przykład wzbogacenie alarmu czy pobranie dodatkowych danych. Część może wymagać wysokiego progu pewności i zatwierdzenia analityka. Działania mogące przerwać usługę powinny mieć uzgodnioną ścieżkę autoryzacji, możliwość cofnięcia zmiany tam, gdzie jest to technicznie możliwe, oraz pełny zapis wykonania ^[17].

Nie istnieje jedna metryka, która dobrze opisuje SOC. Szczególnie łatwo nadużyć wskaźników czasu.

MTTD może oznaczać czas od początku incydentu do wykrycia, ale w innym raporcie bywa liczony od utworzenia alarmu do jego potwierdzenia. MTTR może oznaczać czas reakcji, naprawy albo pełnego odtworzenia usługi. Bez definicji początku i końca liczba jest nieporównywalna.

Dwell time z raportu Mandiant także nie jest tym samym co wewnętrzny czas obsługi alertu. Obejmuje okres obecności napastnika przed wykryciem ^[4].

Lepszy zestaw metryk łączy kilka perspektyw:

• pokrycie krytycznych usług, zasobów i scenariuszy sprawdzoną telemetrią oraz przetestowanymi detekcjami;
• stan źródeł danych: kompletność, opóźnienie, błędy parserów i przerwy w dostarczaniu telemetrii;
• jakość alarmów, w tym udział alarmów potwierdzonych, poprawnych alarmów wywołanych legalną aktywnością oraz przyczyny fałszywych i przeoczonych detekcji;
• czasy z jednoznacznie zdefiniowanymi punktami pomiaru: przyjęcie alarmu, potwierdzenie, eskalacja, ograniczenie skutków i odtworzenie;
• liczbę zdarzeń ujawnionych inną drogą, które powinny zostać wykryte przez SOC;
• czas usuwania luk w telemetrii i detekcji oraz realizację działań po incydentach;
• stan kolejki spraw, obciążenie dyżurów i jakość przekazywania dochodzeń między zmianami.

Celem nie jest uzyskanie jak największej liczby wskaźników. Metryka ma sens, jeżeli prowadzi do decyzji: zmiany reguły, zwiększenia widoczności, poprawy procedury, dodatkowego szkolenia albo inwestycji w konkretną zdolność.

Na 29 sierpnia 2026 r. obowiązuje KSC w brzmieniu po nowelizacji, która weszła w życie 3 kwietnia 2026 r. Aktualny tekst ujednolicony Kancelarii Sejmu według stanu na 18 sierpnia 2026 r. uwzględnia Dz.U. 2026 poz. 20, 252, 815 i 1003 ^[8][9]. NIS2 pozostaje dyrektywą UE; dla polskich podmiotów konkretne obowiązki krajowe wynikają przede wszystkim z KSC wdrażającej tę dyrektywę ^[10].

Art. 8 wymaga od podmiotu kluczowego lub ważnego wdrożenia systemu zarządzania bezpieczeństwem informacji w systemie informacyjnym wykorzystywanym w procesach wpływających na świadczenie usługi. Wśród wymagań znajduje się objęcie takiego systemu monitorowaniem w trybie ciągłym, a także zarządzanie incydentami, podatnościami, dostępem, aktywami, ciągłością działania i łańcuchem dostaw ^[8]. Ustawa wymaga więc określonych zdolności. Nie wskazuje, że trzeba je kupić jako produkt nazwany SOC.

Art. 11 przewiduje dla incydentu poważnego kilka etapów. Podmiot zgłasza wczesne ostrzeżenie niezwłocznie, nie później niż w ciągu 24 godzin od wykrycia, a zgłoszenie incydentu poważnego niezwłocznie, nie później niż w ciągu 72 godzin od wykrycia. Sprawozdanie końcowe jest przekazywane nie później niż w ciągu miesiąca od zgłoszenia 72-godzinnego ^[8]. Dla dostawców usług zaufania ustawa przewiduje odrębną 24-godzinną regułę zgłoszenia incydentu poważnego ^[8].

Terminy przejściowe także wymagają ostrożności. Podmioty, które 3 kwietnia 2026 r. spełniały kryteria podmiotu kluczowego albo ważnego, mają co do zasady 12 miesięcy na wykonanie obowiązków z rozdziału 3, czyli do 3 kwietnia 2027 r. ^[9]. Nie jest to jednak uniwersalny termin dla każdego przyszłego podmiotu. Gdy kryteria zostaną spełnione później, zastosowanie ma mechanizm przewidziany w KSC, liczony od dnia spełnienia przesłanek ^[8].

Nie należy automatycznie nakładać na jeden incydent wszystkich terminów KSC i DORA. Art. 8i KSC przewiduje szczególną relację dla podmiotów kluczowych lub ważnych z sektora bankowości i infrastruktury rynków finansowych. Co do zasady nie stosuje się do nich przepisów KSC dotyczących systemu zarządzania bezpieczeństwem informacji lub zgłaszania poważnych incydentów, poza wyraźnie wymienionymi wyjątkami ^[8]. W zakresie objętym tym wyłączeniem podstawowe znaczenie ma DORA.

To rozróżnienie ma praktyczny skutek dla SOC. Procedura raportowania nie powinna mieć jednej uniwersalnej ścieżki "NIS2/KSC/DORA/RODO". Najpierw trzeba ustalić status podmiotu, rodzaj incydentu i właściwy reżim prawny.

DORA, czyli rozporządzenie (UE) 2022/2554, stosuje się od 17 stycznia 2025 r. do podmiotów finansowych wskazanych w tym rozporządzeniu ^[11]. Wymaga między innymi mechanizmów wykrywania anomalii i procesu zarządzania incydentami związanymi z ICT.

Rozporządzenie delegowane (UE) 2024/1774 doprecyzowuje wymagania techniczne. Art. 23 wymaga między innymi zbierania, monitorowania i analizowania określonych źródeł informacji, identyfikacji anomalnych działań oraz stosowania narzędzi generujących alarmy co najmniej dla aktywów wspierających funkcje krytyczne lub istotne. Alarmy mają być priorytetyzowane tak, aby incydenty mogły być obsługiwane w oczekiwanym czasie zarówno w godzinach pracy, jak i poza nimi ^[12].

Dla poważnego incydentu związanego z ICT rozporządzenie delegowane (UE) 2025/301 przewiduje pierwsze zawiadomienie możliwie szybko, w każdym razie w ciągu czterech godzin od zaklasyfikowania incydentu jako poważny i nie później niż 24 godziny od chwili, gdy podmiot finansowy dowiedział się o incydencie. Sprawozdanie pośrednie jest przekazywane najpóźniej w ciągu 72 godzin od pierwszego zawiadomienia, a końcowe - zasadniczo w ciągu miesiąca od sprawozdania pośredniego lub jego ostatniej aktualizacji ^[13].

DORA nie mówi, że instytucja ma kupić konkretny SOC. W praktyce stawia jednak wymagania, które dla wielu organizacji oznaczają potrzebę zdolności detekcji i eskalacji poza zwykłymi godzinami pracy.

RODO nie ustanawia ogólnego obowiązku posiadania SOC. Art. 32 nakazuje dobrać środki bezpieczeństwa odpowiednie do ryzyka ^[14]. Art. 33 dotyczy naruszenia ochrony danych osobowych, a nie każdego incydentu cyberbezpieczeństwa.

Jeżeli dochodzi do naruszenia ochrony danych osobowych, administrator zgłasza je właściwemu organowi nadzorczemu bez zbędnej zwłoki i, w miarę możliwości, nie później niż 72 godziny po stwierdzeniu naruszenia, chyba że jest mało prawdopodobne, aby powodowało ono ryzyko naruszenia praw lub wolności osób. Podmiot przetwarzający zawiadamia administratora bez zbędnej zwłoki po stwierdzeniu naruszenia ^[14].

SOC powinien więc umieć szybko przekazać informacje potrzebne do oceny incydentu, ale kwalifikacja naruszenia danych osobowych jest odrębnym procesem prawnym. Zegar RODO nie zaczyna automatycznie biec w chwili dowolnego alarmu SIEM. Szerzej o obowiązkach administratora w materiale o audycie zgodności z RODO.

Na 29 sierpnia 2026 r. obowiązuje rozporządzenie Rady Ministrów z 21 maja 2024 r. w sprawie KRI ^[15]. § 19 nakłada na podmioty realizujące zadania publiczne wymagania dotyczące systemu zarządzania bezpieczeństwem informacji i wymaga okresowego audytu wewnętrznego bezpieczeństwa informacji nie rzadziej niż raz w roku. § 19 ust. 3 przewiduje mechanizm uznania wymagań ust. 1 i 2 za spełnione, jeżeli SZBI opracowano na podstawie PN-ISO/IEC 27001, a ustanawianie zabezpieczeń, zarządzanie ryzykiem i audytowanie oparto na właściwych Polskich Normach związanych z PN-ISO/IEC 27001, w tym PN-ISO/IEC 27002 i PN-ISO/IEC 27005 ^[15].

Dla SOC szczególnie praktyczny jest § 20. Wymaga rozliczalności działań w systemach, a w określonym zakresie rejestrowania między innymi dostępu administracyjnego i zmian konfiguracji zabezpieczeń. Jeżeli odrębne przepisy nie określają innego okresu, informacje w dziennikach są przechowywane przez dwa lata ^[15]. KRI nie ustanawia jednak obowiązku zakupu SOC ani certyfikacji ISO/IEC 27001.

Trzeba też uważać na horyzont 2027 r. ELI wskazuje 23 lutego 2027 r. jako datę utraty mocy obecnego KRI ^[15]. Projekt nowego rozporządzenia RD313 został opublikowany w 2026 r. i na 29 sierpnia 2026 r. pozostaje projektem, a nie obowiązującym prawem ^[16]. Uzasadnienie projektu zakłada między innymi zmianę miejsca regulacji części zagadnień bezpieczeństwa w związku z nowym KSC. Nie należy więc przenosić dzisiejszego brzmienia § 19 i § 20 na stan prawny po 23 lutego 2027 r. bez ponownego sprawdzenia przepisów.

ISO/IEC 27001:2022 wraz z Amendment 1:2024 określa wymagania dla systemu zarządzania bezpieczeństwem informacji ^[21]. ISO/IEC 27035-1:2023 opisuje zasady i proces zarządzania incydentami bezpieczeństwa informacji ^[18]. NIST CSF 2.0 stanowi dobrowolne ramy zarządzania ryzykiem cyberbezpieczeństwa, a NIST SP 800-61 Rev. 3 przedstawia rekomendacje dotyczące reagowania na incydenty w powiązaniu z CSF 2.0 ^[17][20].

Te dokumenty mogą być użytecznymi punktami odniesienia, a czasem stają się wymaganiem umownym. Nie są jednak tym samym co polska ustawa czy bezpośrednio stosowane rozporządzenie UE. W audycie KSC & NIS2, audycie KRI albo audycie bezpieczeństwa IT trzeba jasno wskazać kryterium oceny. Zgodność z jednym dokumentem nie powinna być przedstawiana jako automatyczne spełnienie wszystkich pozostałych.

Modele językowe mogą pomagać w streszczaniu spraw, budowaniu osi czasu, proponowaniu zapytań do SIEM, porządkowaniu danych i przygotowaniu roboczej wersji reguły. Ich odpowiedź nie jest jednak niezależnym dowodem. Twierdzenie wygenerowane przez model trzeba potwierdzić w surowej telemetrii albo innym wiarygodnym źródle.

Ryzyka są konkretne. Do zewnętrznego modelu mogą trafić logi klientów, dane osobowe, sekrety techniczne albo informacje o architekturze. Model może przedstawić błędny wniosek pewnym językiem. Treść analizowanego zgłoszenia, wiadomości lub strony może zawierać instrukcje wpływające na zachowanie systemu korzystającego z LLM. OWASP opisuje ten problem jako prompt injection, w tym jego odmianę pośrednią, gdy instrukcje pochodzą z analizowanych stron lub plików ^[22]. Największe ryzyko powstaje wtedy, gdy niezweryfikowany wynik modelu jest bezpośrednio połączony z uprawnieniem do wykonania działania w infrastrukturze.

Rozsądna architektura ogranicza zakres danych i uprawnień, separuje klientów, rejestruje wywołania, testuje zapytania i skrypty przed użyciem produkcyjnym oraz wymaga zatwierdzenia dla działań o dużym wpływie. Wysoki stopień automatyzacji jest wartościowy tam, gdzie konsekwencje błędnej decyzji są dobrze rozpoznane i kontrolowane.

MITRE opublikował w sierpniu 2026 r. aktualizację v19.2, a oficjalny zestaw danych obejmuje między innymi techniki, Detection Strategies i Analytics dla poszczególnych domen ATT&CK ^[19]. Pozwala to dokładniej łączyć zachowanie przeciwnika z oczekiwaną telemetrią i logiką detekcji.

Nie należy jednak oceniać SOC wyłącznie procentem technik ATT&CK "pokrytych" przez produkt. Jedna technika może występować w wielu wariantach. Reguła może zależeć od źródła danych, którego organizacja nie zbiera. Detekcja może działać dla Windows, ale nie dla Linuxa albo chmury. Pokrycie ma znaczenie dopiero po sprawdzeniu scenariusza w środowisku, którego dotyczy.

Dojrzały SOC nie jest definiowany przez liczbę monitorów, liczbę reguł ani nazwę kupionej usługi. Jego wartość można wykazać dopiero wtedy, gdy organizacja wie, co chce chronić, ma wiarygodną telemetrię, potrafi wykryć istotny scenariusz, odtworzyć tok analizy, podjąć proporcjonalną reakcję i poprawić zabezpieczenia po zdarzeniu.

Tryb 24/7 jest uzasadniony tam, gdzie zagrożenia i skutki nie mieszczą się w godzinach pracy. Prawo może dodatkowo narzucać ciągłe monitorowanie lub bardzo krótkie terminy raportowe. Nie zmienia to podstawowej zasady: narzędzie, dyżur i zgodność formalna są tylko częściami zdolności operacyjnej. O skuteczności decyduje to, czy cały proces działa wtedy, gdy naprawdę jest potrzebny.