MSSP: co robi dostawca usług bezpieczeństwa i kiedy naprawdę się opłaca

MSSP (Managed Security Service Provider) to zewnętrzny dostawca, który przejmuje część operacji bezpieczeństwa IT w modelu usługi. Monitoruje zdarzenia, utrzymuje narzędzia, zarządza podatnościami, a w części umów obsługuje incydenty. Wartością MSSP jest ciągłość operacyjna: nie musisz budować dużego zespołu wewnątrz. Ryzykiem jest zakres, w którym dostajesz raporty i zgłoszenia, a reakcja zostaje po twojej stronie.

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

Czym jest MSSP i za co odpowiada?

MSSP (Managed Security Service Provider) to firma świadcząca zarządzane usługi bezpieczeństwa, czyli taka, która narzędzie nie tylko dostarcza, ale też konfiguruje, utrzymuje, monitoruje i raportuje jego wyniki. Zakres zależy wyłącznie od kontraktu, dlatego dwie oferty o tej samej nazwie potrafią oznaczać zupełnie inny podział obowiązków.

W typowym zakresie dostawca monitoruje zdarzenia bezpieczeństwa i zarządza firewallami, WAF, VPN oraz IDS/IPS. Wdraża i utrzymuje EDR/XDR, skanuje podatności i nadaje im priorytety. Dba też o utrzymanie platformy SIEM wraz z korelacjami i raportami oraz obsługuje incydenty, od eskalacji po aktywną reakcję.

Istotne zastrzeżenie: MSSP nie zawsze oznacza pełny SOC w trybie 24/7. Jeden dostawca prowadzi własne centrum operacji bezpieczeństwa, inny tylko zarządza narzędziami i je utrzymuje, bez triage i bez obsługi incydentu. Różnicę widać w opisie usługi i w SLA, nie w nazwie oferty.

Czym MSSP różni się od SOC-as-a-Service, MDR i własnego zespołu?

Cztery modele różnią się przede wszystkim tym, kto reaguje i gdzie znajdują się dane. Porównuj je po zakresie odpowiedzialności, a nie po etykiecie z oferty.

Model	Zakres	Kto reaguje	Dane i narzędzia	Umowa i SLA	Dla kogo
MSSP	Szeroki: utrzymanie narzędzi, konfiguracje, monitorowanie, podatności, raporty	Zwykle zespół klienta po eskalacji; zakres działań dostawcy zależy od nadanych uprawnień	Często narzędzia i licencje dostawcy	SLA na dostępność usługi i czas odpowiedzi na zgłoszenie	Firmy bez zespołu utrzymującego narzędzia bezpieczeństwa na co dzień
SOC-as-a-Service	Wąski i głęboki: detekcja, triage, analiza, obsługa incydentu	Analitycy dostawcy prowadzą incydent, decyzje o odcięciu systemów zostają u klienta	Zwykle SIEM dostawcy	SLA na czas triage i eskalacji według priorytetu	Firmy potrzebujące ciągłego monitorowania bez własnej zmianowości
MDR	Detekcja i reakcja oparta na telemetrii EDR/XDR, z threat huntingiem	Dostawca wykonuje działania powstrzymujące w ramach uzgodnionego mandatu	Platforma dostawcy, mniej integracji	SLA na czas do działania, nie tylko do zgłoszenia	Firmy, które potrzebują szybkiego zamykania incydentów na endpointach
Własny zespół	Pełny, dopasowany do środowiska i priorytetów biznesowych	Zespół wewnętrzny, z pełnym kontekstem i uprawnieniami	Dane i licencje po stronie organizacji	Procedury wewnętrzne zamiast SLA	Organizacje o wysokim profilu ryzyka, zdolne utrzymać zmianowość

Rozróżnisz je jednym pytaniem: czym kończy się usługa w scenariuszu przejętego konta o drugiej w nocy? Odpowiedź „zakładamy zgłoszenie i eskalujemy” opisuje inny produkt niż „unieważniamy sesje, blokujemy konto i raportujemy wykonane działania”. Modele mieszane opisujemy we wpisie o modelach SOC i podejściu hybrydowym.

Jakie usługi obejmuje typowa umowa z MSSP?

• Monitorowanie i obsługa alertów – poziom usługi zależy od tego, czy dostawca tylko przekazuje alerty, czy analityk weryfikuje je wcześniej.
• Zarządzane bezpieczeństwo sieci – reguły firewalli, aktualizacje, przeglądy, segmentacja, utrzymanie VPN i polityk dostępu.
• SIEM w modelu zarządzanym – opieka nad źródłami logów, retencja, korelacje, strojenie reguł i mapowanie detekcji na MITRE ATT&CK.
• Zarządzane EDR/XDR – agenci, polityki, obsługa alertów, a w mocniejszych wariantach izolacja hostów i threat hunting.
• Zarządzanie podatnościami – samo skanowanie to jeszcze nie zarządzanie; to drugie oznacza domknięty cykl: wykrycie, priorytet, naprawa, weryfikacja.
• Obsługa incydentów – od wsparcia konsultacyjnego po pełne DFIR (Digital Forensics and Incident Response). Tu zapisy SLA rozjeżdżają się z oczekiwaniami.

Kiedy MSSP się opłaca, a kiedy rozczarowuje?

MSSP opłaca się wtedy, gdy organizacja potrzebuje stałej operacji bezpieczeństwa szybciej, niż jest w stanie zbudować własny zespół. Przesłanki powtarzają się. Brakuje zasobów, żeby monitorować poza godzinami pracy, a dział IT zajmuje się utrzymaniem i projektami. Dochodzi potrzeba uporządkowanego procesu zmian na narzędziach oraz wymagania raportowe z audytu lub kontraktów. Ostatnia przesłanka to szybki wzrost, przy którym rekrutacja nie nadąża za ryzykiem.

Dostawca rozczarowuje z równie powtarzalnych przyczyn. Dzieje się tak, gdy organizacja oczekuje, że dostawca naprawi bezpieczeństwo bez żadnych zmian po jej stronie. Gdy nie ma osoby decyzyjnej do odbioru eskalacji, zgłoszenie o drugiej w nocy trafia w pustkę. Gdy nie uzgodniono integracji potrzebnych do reakcji, czyli blokad kont, izolacji hostów czy wycofywania wiadomości ze skrzynek, dostawca zdoła wyłącznie poinformować. Gdy zakres wygląda szeroko, ale poszczególne pozycje opisano jako „best effort”, umowa nie zobowiązuje do niczego mierzalnego.

Druga klasyczna pułapka to mylenie monitorowania z ochroną. Monitorowanie mówi, że dzieje się coś złego. Ochrona to zatrzymuje. Ustal, zanim podpiszesz umowę, za które z tych dwóch zjawisk organizacja płaci.

Co musi znaleźć się w umowie z MSSP?

Umowa przesądza o wartości usługi bardziej niż prezentacja handlowa, ponieważ w kryzysie obowiązuje wyłącznie to, co zapisano. Poniższe elementy decydują o sporze.

Element umowy	Dlaczego jest potrzebny	Czerwona flaga
Zakres i inwentarz	Określa, które systemy, źródła logów, endpointy i środowiska chmurowe są monitorowane	Zakres opisany ogólnie, bez listy źródeł i procedury dodawania nowych systemów
Podział ról w incydencie	Wskazuje, kto wykrywa, kto decyduje i kto wykonuje działanie powstrzymujące	Brak rozróżnienia między eskalacją a reakcją; wszystko opisane jako „wsparcie”
SLA i definicje priorytetów	Czas reakcji ma sens tylko wtedy, gdy zdefiniowano, czym jest incydent krytyczny	SLA liczone od przyjęcia zgłoszenia przez klienta, a nie od wykrycia przez dostawcę
Eskalacja poza godzinami pracy	Poważne incydenty zaczynają się wieczorem, w weekend albo w święto	Jedynym kanałem kontaktu jest system zgłoszeń lub poczta, bez dyżuru telefonicznego
Uprawnienia do reakcji	Bez integracji z EDR i systemem tożsamości dostawca może tylko informować	Brak listy działań wykonywanych automatycznie i wymagających zgody klienta
Dane, retencja i dostęp	Logi są materiałem dowodowym i podstawą zgłoszeń do organów nadzoru	Retencja „zgodnie z polityką dostawcy” i brak prawa do eksportu danych
Wsparcie przy zgłoszeniach	Terminy zgłoszeń do organów liczone są w godzinach i wymagają danych od dostawcy	Umowa milczy o obowiązku i czasie przekazania materiału do zgłoszenia
Prawo do audytu i testów	Pozwala zweryfikować skuteczność detekcji, także kontrolowanym atakiem	Zakaz testów bezpieczeństwa albo zgoda uzależniona od decyzji uznaniowej
Podwykonawcy	Usługa bywa świadczona przez dalszych dostawców i w innych lokalizacjach	Brak wykazu podwykonawców i obowiązku informowania o jego zmianie
Wyjście z umowy	Zmiana dostawcy bez planu wyjścia oznacza przerwę w monitorowaniu	Brak strategii wyjścia, terminu zwrotu danych i formatu ich przekazania

Czy MSSP wystarczy do zgodności z NIS2 i DORA?

Gdy powierzasz usługi dostawcy, nie przenosisz na niego odpowiedzialności regulacyjnej. Podmiot objęty przepisami może kupić operację, ale nie kupi zwolnienia z obowiązków.

W polskim porządku prawnym art. 8c ustawy o krajowym systemie cyberbezpieczeństwa wiąże odpowiedzialność za wykonywanie obowiązków w zakresie cyberbezpieczeństwa z kierownikiem podmiotu. Przepis w tym brzmieniu nadała ustawa z 23 stycznia 2026 r. (Dz.U. 2026 poz. 252), która weszła w życie 3 kwietnia 2026 r. Umowa z MSSP zmienia sposób realizacji obowiązku, nie jego adresata.

Dyrektywa (UE) 2022/2555 (NIS2) czyni z relacji z dostawcą przedmiot regulacji. Art. 21 ust. 2 lit. d wymienia bezpieczeństwo łańcucha dostaw wśród minimalnych środków zarządzania ryzykiem, obejmując relacje między podmiotem a jego bezpośrednimi dostawcami. Oznacza to, że oceniasz dostawcę, zapisujesz wymagania w umowie i okresowo sprawdzasz, czy dostawca je spełnia. Zakres obowiązków opisujemy na stronie usługi wdrożenia NIS2.

Podmioty finansowe podlegają najbardziej szczegółowym wymaganiom. Rozporządzenie (UE) 2022/2554 (DORA) poświęca relacjom z zewnętrznymi dostawcami usług ICT odrębny rozdział. Art. 28 określa zasady ogólne wraz z obowiązkiem prowadzenia rejestru informacji o umowach (art. 28 ust. 3). Art. 29 dotyczy ryzyka koncentracji. Art. 30 wymienia obowiązkowe postanowienia umowne: opis usług, lokalizacje przetwarzania danych, prawa dostępu, inspekcji i audytu oraz warunki wypowiedzenia i strategie wyjścia. Nadzór nad tym obszarem rośnie: 18 listopada 2025 r. Europejskie Urzędy Nadzoru (EBA, EIOPA i ESMA) wyznaczyły pierwszych 19 krytycznych dostawców usług ICT objętych bezpośrednim nadzorem.

Wniosek praktyczny jest taki, że obok umowy potrzebny jest wewnętrzny właściciel relacji. Taka osoba rozumie zakres usługi, odbiera eskalacje i potrafi wykazać przed organem, jak podmiot realizuje obowiązki. Gdy takiej roli nie ma, lukę zamyka model vCISO.

Jak podzielić odpowiedzialność między MSSP a zespół wewnętrzny?

Najbardziej odporny podział opiera się na prostej zasadzie: dostawca wnosi operację, organizacja wnosi kontekst i decyzje. Sprowadza się to do czterech ustaleń.

1. MSSP utrzymuje narzędzia, monitoruje zdarzenia i prowadzi triage według uzgodnionych kryteriów.
2. Po stronie organizacji pozostaje właściciel ryzyka, który ma prawo odciąć system produkcyjny.
3. Decyzje krytyczne zostają u klienta, ale automat wykonuje je wszędzie tam, gdzie scenariusz się powtarza.
4. Przeglądy odbywają się cyklicznie i odpowiadają na trzy pytania: co wykryto, co poprawiono, czego jeszcze nie zrobiono.

Bez kontekstu biznesowego dostawca eskaluje wszystko. Bez operacji po stronie dostawcy organizacja jest systematycznie spóźniona. Dlatego sprawdza się układ mieszany, w którym kupujesz utrzymanie narzędzi i monitoring, a inżynieria detekcji i decyzje zostają wewnątrz.

Od czego zależy koszt usług MSSP?

Koszt kształtuje sześć zmiennych. Pierwsze trzy to zakres usług, skala środowiska (liczba endpointów, wolumen logów, lokalizacje, chmura) i wymagane godziny obsługi. Dalej liczy się długość retencji danych oraz poziom reakcji, od monitorowania po działania powstrzymujące. Szósta zmienna to liczba zmian i zgłoszeń w miesiącu, która staje się ukrytą pozycją kosztową.

Oszczędności pojawiają się tam, gdzie na etapie oferty najtrudniej je zauważyć: w jakości triage, w strojeniu reguł i w realnym zakresie reakcji. Zamiast porównywać stawki, porównaj opis scenariusza incydentu i zapisy SLA. Zakres własnych potrzeb w obszarze testów i audytu ustalisz w konfiguratorze zakresu.

Najczęstsze pytania o MSSP

Czym różni się MSSP od MDR?

MSSP obejmuje szeroki zakres zarządzanych usług bezpieczeństwa: utrzymuje narzędzia, monitoruje je i raportuje wyniki. MDR koncentruje się na detekcji i reakcji, zwykle na bazie telemetrii EDR/XDR, i zakłada, że dostawca sam wykonuje działania powstrzymujące, takie jak izolacja hosta. Różnicę rozstrzyga jedno pytanie: czy usługa kończy się na zgłoszeniu, czy na wykonanej reakcji.

Czy MSSP zwalnia z obowiązków wynikających z NIS2?

Nie. Powierzenie zadań dostawcy nie przenosi odpowiedzialności regulacyjnej. Art. 8c ustawy o krajowym systemie cyberbezpieczeństwa wiąże odpowiedzialność za wykonywanie obowiązków w zakresie cyberbezpieczeństwa z kierownikiem podmiotu. Art. 21 ust. 2 lit. d dyrektywy (UE) 2022/2555 (NIS2) wymaga natomiast uwzględnienia bezpieczeństwa łańcucha dostaw, w tym relacji z bezpośrednimi dostawcami.

Czy MSSP to to samo co SOC?

Nie zawsze. MSSP może prowadzić własne centrum operacji bezpieczeństwa, ale może też świadczyć wyłącznie zarządzane utrzymanie narzędzi, bez triage i bez obsługi incydentu. O zakresie przesądza opis usługi i SLA, a nie nazwa oferty. Warto zapytać wprost, kto ocenia alerty, w jakich godzinach i czym kończy się obsługa zdarzenia.

Jakie dane musi otrzymać MSSP, żeby usługa miała sens?

Minimalny zestaw to logi systemów operacyjnych i serwerów, zdarzenia z firewalli i VPN, dane z systemów tożsamości, logi środowisk chmurowych, poczta oraz telemetria z EDR/XDR. Pominięcie tożsamości i poczty tworzy trwałą lukę w detekcji, ponieważ tam najczęściej zaczyna się przejęcie konta i dalsza eskalacja uprawnień.

Jak sprawdzić, czy MSSP faktycznie wykrywa ataki?

Raport z liczbą alertów niczego nie dowodzi. Skuteczność sprawdza kontrolowany atak: purple teaming z jawnym odtwarzaniem technik albo red teaming prowadzony bez uprzedzenia zespołu obrony. Prawo do takich testów warto zapisać w umowie z góry, razem z zasadami powiadamiania dostawcy i zakresem systemów objętych próbą.

Jak Pentestica może pomóc

Pentestica nie świadczy usług MSSP i nie prowadzi SOC. Sprawdzamy natomiast, czy usługa kupiona u dostawcy działa tak, jak opisuje ją umowa. Prowadzimy audyt bezpieczeństwa IT obejmujący kompletność źródeł danych, jakość detekcji i procedury eskalacji. Do tego dochodzą red teaming i purple teaming, które weryfikują realny czas wykrycia i reakcji. Wspieramy też ocenę zapisów umownych pod kątem wymagań NIS2 i DORA, a w roli vCISO obejmujemy nadzór nad relacją z dostawcą. Zakres ustalisz w konfiguratorze zakresu.

Źródła

• Dyrektywa (UE) 2022/2555 (NIS2) – art. 21 ust. 2 lit. d: bezpieczeństwo łańcucha dostaw i relacje z bezpośrednimi dostawcami.
• Ustawa z 23 stycznia 2026 r. o zmianie ustawy o KSC (Dz.U. 2026 poz. 252) – art. 8c: odpowiedzialność kierownika podmiotu.
• Rozporządzenie (UE) 2022/2554 (DORA) – art. 28 (rejestr umów), art. 29 (ryzyko koncentracji), art. 30 (postanowienia umowne).
• Europejskie Urzędy Nadzoru (EBA, EIOPA, ESMA) – wyznaczenie pierwszych 19 krytycznych dostawców usług ICT z 18 listopada 2025 r.
• MITRE ATT&CK – baza taktyk i technik atakujących używana do mapowania pokrycia detekcji.