SOC in-house, hybrydowy czy SOC-as-a-Service — jak wybrać model SOC

SOC in-house to własny zespół na własnych narzędziach, SOC hybrydowy dzieli zadania między firmę a dostawcę, a SOC-as-a-Service przenosi całą funkcję do zewnętrznego dostawcy w abonamencie. O wyborze decyduje jedno kryterium: ile kontekstu i decyzji organizacja musi utrzymać u siebie, a ile pokrycia 24/7 i specjalizacji opłaca się kupić. Dla większości średnich i dużych organizacji odpowiedzią jest model hybrydowy.

Stan prawny na dzień 2 września 2026 r.

Czym różnią się SOC in-house, SOC hybrydowy i SOC-as-a-Service?

Trzy modele SOC różnią się tym, kto obsługuje alerty, gdzie zostaje kontekst i decyzje oraz jak szybko organizacja uzyskuje pokrycie 24/7. SOC (Security Operations Center) to w każdym wariancie ten sam zestaw: ludzie, procesy i narzędzia do wykrywania zagrożeń, analizy i reagowania. Zmienia się tylko to, po której stronie umowy znajduje się każdy z tych elementów.

Model	Kto obsługuje	Kontrola i dane	Czas uruchomienia	Koszt względny	Skalowanie 24/7	Dla kogo
SOC in-house	Własny zespół: analitycy, inżynier detekcji, lider IR	Pełna; logi, reguły i decyzje zostają w organizacji	Najdłuższy: rekrutacja, narzędzia, procesy	Najwyższy koszt stały, głównie ludzie	Trudne: zmiany, urlopy, rotacja	Duża skala sygnałów, sektor będący celem, bezpieczeństwo jako kompetencja strategiczna
SOC hybrydowy	Trzon wewnętrzny plus dostawca (MDR, MSSP) na noc, piki i specjalizacje	Wysoka; kontekst i decyzje w firmie, część telemetrii u dostawcy	Średni: onboarding dostawcy plus RACI i integracje	Umiarkowany; za skalę płaci się wtedy, gdy jest potrzebna	Łatwe: dostawca przejmuje zmiany poza 8/5	Organizacje z własnym zespołem IT lub bezpieczeństwa, którym brakuje 24/7 i specjalistów
SOC-as-a-Service	Dostawca zewnętrzny: ludzie, procesy i narzędzia w abonamencie	Ograniczona; zakres, reguły i reakcja w granicach umowy	Najkrótszy: podłączenie źródeł i baselining	Niski koszt wejścia, koszt bieżący rośnie z wolumenem logów	W standardzie usługi	Brak zespołu, potrzeba szybkiego startu, etap przejściowy przed hybrydą

Największa różnica między hybrydą a czystym outsourcingiem: w hybrydzie organizacja nie traci kontekstu i nie oddaje steru. Dostawca jest drugą linią albo nocną zmianą, a nie mózgiem operacji. W SOC-as-a-Service mózgiem jest dostawca, a organizacja musi zadbać, by ktoś po jej stronie odbierał eskalacje i podejmował decyzje.

SOC-as-a-Service, MDR i MSSP: co jest czym?

SOC-as-a-Service (także „Managed SOC”) obejmuje pełną funkcję SOC: proces incydentu, monitoring, raportowanie, często zarządzany SIEM. MDR (Managed Detection and Response) koncentruje się na detekcji i reakcji na podstawie EDR/XDR i playbooków. MSSP (Managed Security Service Provider) to pojęcie szersze: firewalle, VPN, zgodność, ale nie zawsze pełny SOC. Liczy się nie nazwa, tylko zakres: co dostawca widzi, co robi sam, co automatyzuje, co eskaluje i w jakim czasie.

Kiedy SOC in-house ma sens?

SOC in-house ma sens wtedy, gdy organizacja ma realną skalę ryzyka, własne złożone środowisko i chce kontrolować jakość reakcji, dane oraz priorytety biznesowe. Warunkiem jest traktowanie SOC jak produktu operacyjnego z właścicielem, procesem i celami, a nie jak projektu wdrożenia SIEM.

Własny SOC jest uzasadniony, gdy spełnione są co najmniej trzy z poniższych warunków:

• środowisko generuje dużo sygnałów: chmura, on-prem, SaaS, endpointy, sieć;
• organizacja jest atrakcyjnym celem: finanse, zdrowie, e-commerce, produkcja, logistyka, software house z dużymi klientami;
• regulacje i audyty wymagają dowodów reakcji, logów, retencji i kontroli dostępu;
• incydent oznacza realne straty: przestój, wyciek, kary, reputacja;
• zarząd chce budować kompetencje wewnątrz, bo bezpieczeństwo jest elementem strategii.

SOC in-house nie ma sensu, gdy zespół IT ledwo wyrabia z utrzymaniem albo organizacja nie ma sensownych logów. Nie ma go też wtedy, gdy oczekiwanie brzmi „24/7″, a budżet starcza na „8/5″, albo gdy panuje przekonanie, że narzędzia zrobią robotę za ludzi. Na start własny SOC potrzebuje ról, nie armii. Są to: SOC Lead lub Incident Response Lead (właściciel procesu, eskalacje), analityk L1/L2 (triage, korelacja) oraz inżynier detekcji (reguły, tuning, mapowanie na MITRE ATT&CK). Do tego opcjonalnie threat hunter oraz specjalizacje na wezwanie, najczęściej zewnętrzne: forensics, malware, incydenty w chmurze. W małej organizacji jedna osoba może łączyć kilka ról, ale role muszą istnieć.

Kiedy SOC hybrydowy ma sens?

SOC hybrydowy ma sens wtedy, gdy organizacja ma własny zespół IT lub bezpieczeństwa, który chce utrzymać kontekst i decyzje, ale brakuje mu pokrycia 24/7 i wąskich specjalizacji. Jest to najczęstszy docelowy model dla organizacji średnich i dużych, bo daje kontrolę bez kosztu własnego SOC działającego całą dobę. W praktyce funkcjonują cztery warianty hybrydy:

1. In-house 8/5 plus zewnętrzny 16/7 lub 24/7. W dzień działa zespół wewnętrzny, w nocy i w weekendy dostawca prowadzi monitoring, triage i eskalacje.
2. Wewnętrzny Incident Response plus zewnętrzny monitoring (MDR). Dostawca wykrywa i potwierdza incydent, zespół wewnętrzny prowadzi reakcję, izolacje, komunikację i decyzje biznesowe.
3. Wewnętrzne detekcje i tuning plus zewnętrzny „ops”. Organizacja buduje reguły, integracje i mapowanie na MITRE ATT&CK, dostawca obsługuje kolejkę alertów według playbooków klienta.
4. Core SOC in-house plus specjalizacje na żądanie. Threat hunting, forensics i incydenty w chmurze zamawiane u ekspertów, gdy są potrzebne.

Jak podzielić odpowiedzialność w SOC hybrydowym (RACI)?

Macierz RACI w SOC hybrydowym określa, kto wykonuje zadanie (R, Responsible), kto za nie odpowiada (A, Accountable), z kim się konsultuje (C, Consulted) i kogo informuje (I, Informed). Bez niej powstaje sytuacja: dostawca wykrył, klient myślał, że dostawca zablokuje, a dostawca myślał, że zablokuje klient. Poniższy podział odpowiada wariantowi in-house 8/5 plus dostawca 24/7.

Zadanie	Zespół wewnętrzny	Dostawca zewnętrzny	Do ustalenia w umowie
L1: monitoring i triage alertów	A, I	R	Definicja incydentu, progi i czas eskalacji
L2: analiza i potwierdzenie incydentu	A, C	R	Dostęp dostawcy do kontekstu: systemy krytyczne, wyjątki, konta uprzywilejowane
L3: forensics, malware, cloud IR	A, C	R (na żądanie)	Czas rozpoczęcia, zakres, przekazanie materiału dowodowego
Threat hunting	A, R (hipotezy z kontekstu firmy)	R, C (wykonanie, feedy TI)	Częstotliwość, dostępna telemetria, format wyników
Reagowanie na incydent (IR)	A, R (decyzje, komunikacja)	R (akcje z playbooka), C	Które akcje dostawca wykonuje sam, kto jest dowódcą incydentu
Tuning reguł	A, R (reguły pod środowisko)	R (reguły standardowe), C	Kto aktualizuje detekcje po zmianach w infrastrukturze, kto zarządza whitelistą
Raportowanie zgodności (NIS2, KSC, DORA)	A, R (zgłoszenia do CSIRT lub KNF)	R (dane, osie czasu), I	Retencja logów, termin dostarczenia danych do zgłoszeń 24 h i 72 h

Macierz RACI działa tylko razem z integracjami, które kończą się akcją. Chodzi o EDR do izolacji endpointu, IdP do blokady kont i resetów sesji oraz pocztę do kwarantanny wiadomości. Do tego firewall, DNS i proxy do blokad oraz ITSM do ticketów i SLA. Do tego potrzebne są wspólne playbooki (klasyfikacja, progi eskalacji, które działania są automatyczne). Potrzebna jest też jedna prawda o danych: co jest logowane, gdzie, z jaką retencją i kto płaci za rosnący storage.

Kiedy SOC-as-a-Service ma sens?

SOC-as-a-Service ma sens wtedy, gdy organizacja nie ma zespołu ani czasu na budowę własnego SOC. Sprawdza się też, gdy potrzebuje pokrycia 24/7 szybciej, niż trwa rekrutacja, albo musi szybko pokazać proces i dowody działania na potrzeby audytu. Jest to także dobry etap przejściowy: start na usłudze, a z czasem przejęcie części kompetencji do wewnątrz i przejście do modelu hybrydowego.

Z SOC-as-a-Service należy uważać, gdy organizacja oczekuje pełnej reakcji, ale nie chce dać dostawcy uprawnień i integracji. Ostrożność jest wskazana także wtedy, gdy organizacja ma nietypowe środowisko, traktuje SOC jako pozycję do odhaczenia w zgodności, albo nie ma nikogo, kto odbierze eskalację i podejmie decyzję. Usługa bez osoby po stronie klienta to teatr alarmów.

Co powinna zawierać dobra umowa SOC-as-a-Service?

Dobra umowa SOC-as-a-Service precyzuje detekcje, SLA i raportowanie. Detekcje mają być dopasowane do ryzyka organizacji (konta uprzywilejowane, aplikacje krytyczne, CI/CD, chmura), nie tylko do standardowego pakietu reguł. SLA musi definiować, co znaczy „zareagujemy”: analiza, ticket, telefon czy akcja. Raport ma odpowiadać, co wykryto, co zrobiono i co poprawiono; sama lista alertów oznacza, że SOC pracuje dla własnych metryk. Osobno trzeba uregulować dostęp dostawcy według zasady najmniejszych uprawnień, audytowalność jego działań, retencję logów i lokalizację danych, bo logi to mapa firmy.

Jak wybrać model SOC: kryteria decyzyjne

Wybór modelu SOC sprowadza się do siedmiu kryteriów, które organizacja powinna ocenić przed rozmową z jakimkolwiek dostawcą. Odpowiedzi wskazują model, a nie odwrotnie.

1. Skala i różnorodność sygnałów. Dużo źródeł (chmura, on-prem, SaaS, OT) przemawia za trzonem wewnętrznym, bo dostawca nie zna kontekstu każdego systemu.
2. Dostępność ludzi. Brak możliwości zatrudnienia i utrzymania analityków oznacza SOC-as-a-Service lub hybrydę.
3. Wymagany czas reakcji na incydent krytyczny. Krótki także w nocy i w weekend wymaga pokrycia poza 8/5: dostawca albo własny dyżur.
4. Kto ma mandat do decyzji. Jeśli izolacja hosta czy zatrzymanie wdrożenia muszą zostać w firmie, model czysto zewnętrzny się nie sprawdzi.
5. Wymogi regulacyjne i dowody. Każdy model musi dostarczać osie czasu i dowody do zgłoszeń w terminach z NIS2, KSC i DORA.
6. Wrażliwość i lokalizacja danych. Ograniczenia sektorowe co do miejsca przetwarzania logów mogą wykluczyć część dostawców.
7. Horyzont. Organizacja, która chce budować kompetencje, planuje ścieżkę: SOC-as-a-Service, potem hybryda, a większy SOC in-house tylko wtedy, gdy uzasadnia to skala.

Jakie KPI mierzyć niezależnie od modelu SOC?

Niezależnie od modelu SOC należy mierzyć wynik, a nie liczbę alertów. Alerty mogą rosnąć, bo rośnie widoczność, i to jest zjawisko pozytywne. Wskaźniki, które mówią, czy SOC działa:

• MTTD (Mean Time To Detect): czas od pierwszego sygnału do wykrycia, osobno dla godzin pracy i poza nimi.
• MTTR (Mean Time To Respond): czas od wykrycia do powstrzymania i domknięcia incydentu.
• Pokrycie źródeł logów: odsetek systemów krytycznych, które faktycznie wysyłają telemetrię do SOC.
• Odsetek alarmów fałszywych i jego trend; wzrost po zmianach w infrastrukturze sygnalizuje brak tuningu.
• Pokrycie technik MITRE ATT&CK w obszarach krytycznych.
• Czas eskalacji od dostawcy do zespołu wewnętrznego oraz liczba playbooków wykonywanych automatycznie.
• Czas od incydentu do wdrożenia poprawki: zamknięcie pętli detekcja, prewencja, lessons learned.

Wartości docelowe zależą od sektora i środowiska, dlatego punktem odniesienia jest własny baseline zmierzony po pierwszych tygodniach działania, a nie benchmarki z materiałów dostawców.

Jak wdrożyć wybrany model SOC w 90 dni?

Wdrożenie każdego modelu SOC w 90 dni przebiega w trzech etapach: widoczność i porządek, detekcja i tuning, reakcja jak zespół. Plan jest wspólny; różni się tylko to, które zadania wykonuje organizacja, a które dostawca.

Dni 0–30: widoczność i porządek

• zakres: co ma być wykrywane, jakie systemy są krytyczne, jakie godziny pokrycia, maksymalny czas reakcji na incydent krytyczny;
• inwentaryzacja i centralizacja logów: EDR, IdP, poczta, chmura, firewall, DNS, proxy;
• macierz RACI i wskazanie dowódcy incydentu; w SOC-as-a-Service osoba odbierająca eskalacje po stronie klienta;
• pierwsze reguły (MFA fatigue, impossible travel, anomalie w dostępie do poczty i chmury) i runbooki na pięć najczęstszych scenariuszy;
• baseline: pomiar szumu, MTTD i pokrycia źródeł jako linia startu.

Dni 31–60: detekcja, tuning, mniej szumu

• tuning reguł i whitelisty, bez wyciszania wszystkiego;
• mapowanie detekcji na MITRE ATT&CK, aby zobaczyć luki w pokryciu;
• playbooki i automatyzacje: izolacja endpointu, blokada domeny, reset sesji, kwarantanna wiadomości;
• metryki i pierwsze raportowanie do zarządu.

Dni 61–90: reakcja jak zespół, nie jak chaos

• ćwiczenia tabletop i symulacje: co robimy o 2 w nocy w niedzielę;
• uzgodnienie z IT, zespołami deweloperskimi i prawnikami, kto podpisuje decyzje;
• uruchomienie dyżuru on-call albo zewnętrznego wsparcia poza 8/5;
• przeglądy detekcji, incydentów i poprawek; pierwsze porównanie KPI z baseline.

Jeśli po 90 dniach organizacja nadal nie wie, ile ma fałszywych alarmów i ile trwa obsługa incydentu, SOC jest dekoracją, a nie funkcją.

Najczęstsze błędy przy budowie lub zakupie SOC

Najczęstsze błędy przy SOC nie dotyczą technologii, tylko własności, danych i decyzji. Powtarzają się w każdym modelu, choć w każdym przybierają inną postać.

• Budowanie SOC od narzędzi, a nie od pytań. SOC ma odpowiadać na konkretne pytania. Czy ktoś loguje się niestandardowo do kont uprzywilejowanych? Czy jest ruch do domen C2, czy ktoś masowo eksportuje dane, czy wykryty zostanie lateral movement? Bez pytań są tylko alerty.
• Brak ownershipu i mandatu do decyzji. SOC widzi problem, ale nikt nie może wyłączyć usługi, zablokować konta prezesa ani zatrzymać wdrożenia.
• SOC jako raportowanie, nie reagowanie. Jeśli jedynym produktem są dashboardy, powstało centrum prezentacji, nie operacji.
• Detekcje nieaktualizowane po zmianach w infrastrukturze. SOC staje się ślepy w nowych miejscach i przewrażliwiony w starych.
• SLA bez sensu operacyjnego: „zareagujemy w 60 minut” bez definicji, czym jest reakcja.
• Hybryda jako „kupmy usługę, reszta zrobi się sama”. Nie zrobi się; to nadal operacja wymagająca ludzi po obu stronach.

Czy NIS2 i DORA wymagają SOC?

Ani dyrektywa (UE) 2022/2555 (NIS2), ani rozporządzenie (UE) 2022/2554 (DORA), ani ustawa o krajowym systemie cyberbezpieczeństwa nie nakazują wprost posiadania SOC. Wszystkie trzy akty wymagają natomiast zdolności do wykrywania i obsługi incydentów, dowodów działania i zgłoszeń w krótkich terminach. Wybór między własnym zespołem, hybrydą i SOC-as-a-Service jest dla regulatora obojętny, o ile proces działa i da się go wykazać.

• NIS2: art. 21 ust. 2 lit. b wymienia obsługę incydentów wśród minimalnych środków zarządzania ryzykiem. Art. 23 ustala terminy: wczesne ostrzeżenie w 24 godziny, zgłoszenie w 72 godziny, sprawozdanie końcowe w miesiąc od zgłoszenia.
• Ustawa o KSC po nowelizacji ustawą z 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa (Dz.U. 2026 poz. 252). Nowelizacja jest w mocy od 3 kwietnia 2026 r. Art. 8 ust. 1 pkt 4 nakłada obowiązek zarządzania incydentami, a pkt 3 zbierania informacji o cyberzagrożeniach i podatnościach. Incydent poważny zgłasza się do CSIRT sektorowego: wczesne ostrzeżenie w 24 godziny od wykrycia, zgłoszenie w 72 godziny (według omówienia NASK).
• DORA: art. 10 wymaga mechanizmów wykrywania anomalii i incydentów ICT, a art. 11 reagowania i przywracania. Art. 17 i 19 wymagają procesu zarządzania incydentami i zgłaszania poważnych incydentów do Komisji Nadzoru Finansowego (KNF). Rozporządzenie delegowane (UE) 2025/301 w art. 5 ust. 1 wyznacza terminy. Powiadomienie wstępne składa się w 4 godziny od sklasyfikowania incydentu jako poważny i nie później niż 24 godziny od powzięcia wiedzy. Sprawozdanie śródokresowe składa się w 72 godziny od powiadomienia, a końcowe w miesiąc od śródokresowego.

Terminy 4, 24 i 72 godzin liczą się od wykrycia lub sklasyfikowania incydentu, dlatego wykrywanie poza godzinami pracy przestaje być kwestią komfortu. Audytora interesuje proces, dowody (logi, zgłoszenia, post-mortem) i to, czy umowa z dostawcą obejmuje to, co organizacja deklaruje w politykach. Szczegóły obowiązków opisują strony usług wdrożenia NIS2 i zgodności z DORA, a terminy w sektorze finansowym omawia wpis o raportowaniu incydentów według DORA.

Najczęstsze pytania o wybór modelu SOC

Czy SOC-as-a-Service wystarczy do zgodności z NIS2?

SOC-as-a-Service może pokrywać wymóg obsługi incydentów z art. 21 ust. 2 lit. b dyrektywy NIS2 i art. 8 ust. 1 pkt 4 ustawy o KSC. Odpowiedzialność za zgłoszenie incydentu w 24 i 72 godziny oraz za decyzje pozostaje jednak po stronie podmiotu. Umowa musi gwarantować dane i osie czasu w terminach umożliwiających zgłoszenie, a organizacja musi mieć osobę, która je wysyła.

Czy SOC hybrydowy można zacząć od SOC-as-a-Service?

Tak, SOC-as-a-Service jest naturalnym pierwszym etapem na drodze do SOC hybrydowego. Organizacja startuje na usłudze, buduje własne runbooki i kompetencje, a następnie przejmuje kontekst, tuning reguł i reagowanie, pozostawiając dostawcy monitoring poza godzinami pracy i specjalizacje. Warunkiem jest zapisanie w umowie dostępu do własnych logów i reguł, aby przejście nie oznaczało startu od zera.

Ile osób potrzeba na SOC in-house działający 24/7?

Pełne pokrycie 24/7 własnymi siłami wymaga obsadzenia trzech zmian z uwzględnieniem urlopów, chorób i rotacji, więc zespół musi być kilkukrotnie większy niż w modelu 8/5. Dokładna liczba zależy od skali sygnałów i poziomu automatyzacji. Z tego powodu większość organizacji zaczyna od trzonu wewnętrznego 8/5 i dokupuje pokrycie nocne i weekendowe u dostawcy.

Czy da się zbudować SOC in-house bez SIEM?

Da się zacząć bez pełnego SIEM, ale nie bez logów i korelacji. Minimum to centralizacja zdarzeń z tożsamości, endpointów, poczty i chmury oraz analityka pozwalająca łączyć zdarzenia w łańcuch. Jeśli trzeba wybierać, EDR daje szybki efekt na endpointach, a SIEM centralny obraz; zaczyna się od tego, co zamyka największą lukę w widoczności.

Jak sprawdzić, czy SOC naprawdę wykrywa ataki?

Skuteczność SOC sprawdza się ćwiczeniami, które symulują realne techniki atakujących, a nie przeglądem dashboardów. Purple teaming testuje wybrane techniki MITRE ATT&CK wspólnie z zespołem SOC i od razu poprawia detekcje. Red teaming sprawdza cały łańcuch od wejścia do celu bez uprzedzenia obrońców, a tabletop weryfikuje decyzje i komunikację. Wynikiem powinny być zmierzone MTTD i MTTR oraz lista luk w pokryciu.

Jak Pentestica może pomóc

Pentestica nie prowadzi SOC, ale sprawdza, czy wybrany model SOC wykrywa i powstrzymuje ataki. W ramach red teamingu i purple teamingu odtwarzamy techniki z MITRE ATT&CK w środowisku klienta. Mierzymy, które z nich zespół SOC lub dostawca zauważył, w jakim czasie i jak zareagował. Testy penetracyjne pokazują, które podatności mogą stać się początkiem incydentu. Audyt bezpieczeństwa IT weryfikuje proces obsługi incydentów, umowę z dostawcą SOC i dowody wymagane przez NIS2, ustawę o KSC i DORA. Zakres współpracy można wstępnie określić w konfiguratorze zakresu.

Źródła

• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (NIS2): art. 21 ust. 2 lit. b (obsługa incydentów), art. 23 (terminy 24 h, 72 h, 1 miesiąc)
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 (DORA): art. 10 (wykrywanie), art. 11 (reagowanie i przywracanie), art. 17 i 19 (incydenty i zgłaszanie)
• Rozporządzenie delegowane Komisji (UE) 2025/301: art. 5 ust. 1, terminy zgłoszeń poważnych incydentów wg DORA
• Ustawa z 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa (Dz.U. 2026 poz. 252): art. 8 ust. 1 (SZBI, w tym pkt 4 zarządzanie incydentami)
• Ministerstwo Cyfryzacji: nowelizacja ustawy o KSC, najważniejsze terminy: wejście w życie 3 kwietnia 2026 r.
• NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: model obsługi incydentów powiązany z NIST Cybersecurity Framework 2.0
• MITRE ATT&CK: baza taktyk i technik używana do mapowania pokrycia detekcji