SLA na usługi SOC — co musisz wiedzieć zanim podpiszesz

Dlaczego SLA na SOC to nie jest formalność

Umowa SLA (Service Level Agreement) na usługi SOC to nie dokument, który podpisujesz i chowasz do szuflady. To zobowiązanie, które decyduje o tym, co się stanie, gdy zaatakują Twoją firmę o 2 w nocy w sobotę.

Wielu dostawców SOC prezentuje SLA jako jedną liczbę: „czas reakcji 15 minut". Ale diabeł tkwi w szczegółach. Co znaczy „reakcja"? Alert e-mailem? Telefon? Izolacja zagrożonego systemu? I czy te 15 minut obowiązuje o 2 w nocy tak samo jak o 10 rano?

Trzy metryki, które musisz rozumieć

MTTD — Mean Time to Detect

Czas od momentu, gdy zagrożenie pojawia się w infrastrukturze, do momentu, gdy SOC je wykryje. Zależy głównie od technologii (SIEM, reguły detekcji, AI).

Dobry benchmark: < 5 minut dla znanych wzorców ataku, < 1 godzina dla nowych zagrożeń.

MTTR — Mean Time to Respond

Czas od wykrycia do pierwszej reakcji. To najważniejsza metryka. Reakcja to nie alert — to działanie: izolacja endpointu, zablokowanie konta, wdrożenie reguły firewalla.

Dobry benchmark: < 15 minut 24/7/365 (istotne: nie tylko w godzinach biurowych).

MTTR — Mean Time to Resolve

Czas od wykrycia do pełnego rozwiązania incydentu. Obejmuje analizę, remediację, przywrócenie normalnej pracy i raport.

Dobry benchmark: < 4 godziny dla incydentów krytycznych, < 24h dla średnich.

Na co uważać w SLA — 7 pułapek

1. Różne SLA na dzień i noc

Pytaj wprost: „Czy te parametry obowiązują 24/7/365?" Niektórzy dostawcy podają czas reakcji 15 minut w godzinach biurowych, ale w nocy i weekendy — „best effort" lub 4 godziny.

Atakujący to wiedzą. Dlatego 76% ataków ransomware zaczyna się poza godzinami pracy.

2. „Reakcja" = alert e-mailem

Sprawdź definicję „reakcji" w umowie. Alert wysłany na e-mail to nie reakcja — to powiadomienie. Realna reakcja to containment: izolacja systemu, zablokowanie konta, zatrzymanie procesu.

3. Brak kar umownych

SLA bez konsekwencji za niedotrzymanie to życzenie, nie zobowiązanie. Pytaj o kary umowne (service credits) za przekroczenie parametrów.

4. Ukryte wyłączenia

Czytaj drobny druk. Typowe wyłączenia: „SLA nie obowiązuje w trakcie planowanych prac serwisowych", „SLA nie obowiązuje, gdy incydent wynika z działań klienta", „SLA nie obejmuje incydentów zero-day".

Niektóre wyłączenia są rozsądne. Ale wyłączenie zero-day z SLA oznacza, że w przypadku najgroźniejszych ataków dostawca nie ma żadnych zobowiązań.

5. Brak retencji logów w SLA

KSC 2.0 wymaga utrzymywania logów. Sprawdź:

• Jak długo przechowywane są logi? (minimum 12 miesięcy)
• Gdzie są przechowywane? (chmura vs lokalnie)
• Czy możesz je pobrać/wyeksportować?

6. Brak wsparcia raportowania incydentów

KSC 2.0 wymaga raportowania w 24h/72h/30 dni. Sprawdź, czy dostawca pomaga w przygotowaniu zgłoszenia do CSIRT — czy to „Twoja odpowiedzialność".

7. Vendor lock-in przez format danych

Jeśli zmienisz dostawcę — czy logi i konfiguracje są eksportowalne? Czy dostawca używa standardowych formatów?

Jak SLA wygląda w praktyce — scenariusze

Liczby w tabeli to jedno. To, co się dzieje o 2 w nocy w sobotę — to drugie. Kilka scenariuszy, które pokazują, dlaczego szczegóły SLA mają znaczenie.

Scenariusz 1: Ransomware w piątek wieczór. SOC wykrywa anomalną aktywność szyfrowania na serwerze plików. SLA mówi „reakcja w 15 minut". Ale co to znaczy w praktyce? W dobrym SOC: izolacja serwera od sieci w ciągu minut, zablokowanie konta źródłowego, powiadomienie dyżurnego u klienta. W słabym SOC: e-mail na adres IT. Który nikt nie czyta do poniedziałku. Przez weekend ransomware szyfruje backup i dwa dodatkowe serwery.

Scenariusz 2: Alert o wycieku danych. SOC widzi masowe pobieranie plików z SharePointa przez konto, które właśnie zalogowało się z nietypowej lokalizacji. SLA mówi „czas wykrycia < 10 minut". Ale czy obejmuje też analizę kontekstu? Czy analityk sprawdzi, że to nie planowany eksport dla audytora? Czy skontaktuje się z właścicielem konta? Dobry SLA definiuje nie tylko „jak szybko wykrywamy" ale też „jak szybko rozumiemy".

Scenariusz 3: Fałszywy alarm na produkcji. System korelacji flaguje aktywność na serwerze OT jako podejrzaną. Automatyczna izolacja mogłaby zatrzymać linię produkcyjną. SLA powinno definiować procedurę eskalacji dla systemów krytycznych — kiedy izolować automatycznie, kiedy dzwonić do klienta, kiedy czekać na decyzję. Bez tej granulacji SLA jest albo za agresywne (ryzyko fałszywego przestoju), albo za pasywne (ryzyko braku reakcji).

Jak negocjować SLA — 5 zasad

1. Zacznij od scenariuszy, nie od metryk. Nie pytaj „jaki macie MTTR". Pytaj „co się stanie, gdy ransomware uderzy o 2 w nocy w sobotę". Odpowiedź pokaże, czy dostawca myśli o metrykach, czy o Twojej firmie.

2. Żądaj jednolitego SLA 24/7. Atakujący nie pracują w godzinach biurowych. Twój SLA nie powinien mieć przerwy na lunch. Jeśli dostawca proponuje różne parametry na dzień i noc — to pierwszy sygnał, że jego zespół nie jest gotowy na prawdziwe 24/7.

3. Definiuj „reakcję" precyzyjnie. Zapiszcie w umowie, co znaczy containment: izolacja endpointu, zablokowanie konta, zatrzymanie procesu. „Reakcja" bez definicji to puste słowo.

4. Pytaj o kary i mechanizm ich egzekwowania. Service credits to standard. Ale sprawdź: czy naliczane automatycznie czy na żądanie? Czy dostawca sam mierzy parametry, czy masz dostęp do dashboardu z danymi? Kto rozstrzyga spory?

5. Uwzględnij KSC 2.0. Od 3 kwietnia 2026 r. KSC 2.0 nakłada na podmioty obowiązek raportowania incydentów w terminach 24h/72h/30 dni. Twój SLA powinno precyzować, kto przygotowuje zgłoszenie do CSIRT — Ty czy dostawca. W SecIQ robimy to w pakiecie, bo wiemy, że o 3 w nocy nie będziesz szukał formularza.

Co powinno zawierać dobre SLA na SOC

Ile kosztuje brak dobrego SLA

Warto zadać sobie pytanie od drugiej strony: ile kosztuje SLA, które nie działa?

Scenariusz: ransomware w nocy, SLA „best effort". Firma produkcyjna, 180 osób. Atak rozpoczyna się w piątek o 22:00. Dostawca SOC ma SLA „best effort" w godzinach pozabiurowych. Alert dociera do dyżurnego po 2 godzinach. Dyżurny dzwoni do analityka, który się budzi, loguje, ocenia sytuację — następne 90 minut. W tym czasie ransomware szyfruje kolejne serwery. Łączne opóźnienie reakcji: ~4 godziny. Koszt: 3 dodatkowe serwery zaszyfrowane, backup skompromitowany, odtwarzanie zajmuje 5 dni zamiast 1.

Gdyby SLA wynosiło < 15 minut 24/7 z containmentem w pakiecie — izolacja nastąpiłaby po kilku minutach. Ransomware zostałby zamknięty na jednym serwerze. Odtwarzanie z backupu: kilka godzin.

Różnica w koszcie incydentu: dziesiątki, czasem setki tysięcy złotych. Różnica w koszcie SLA: kilkaset złotych miesięcznie.

SLA w SecIQ SOC

W SecIQ podchodzimy do SLA tak, jak sami chcielibyśmy być chronieni:

• Czas reakcji < 15 minut — 24/7/365, bez rozróżnienia na dzień/noc. Te same parametry w Wigilię co w poniedziałek o 10
• Containment w pakiecie — izolacja endpointu, zablokowanie konta, zatrzymanie procesu. Nie tylko alert w skrzynce
• Retencja logów w chmurze Azure — minimum 12 miesięcy, poza zasięgiem atakujących. Fundament dla forensyki i compliance KSC 2.0
• Comiesięczne raporty — KPI, trendy, rekomendacje w języku zrozumiałym dla zarządu
• Wsparcie raportowania KSC 2.0 — pomagamy przygotować zgłoszenie do CSIRT w wymaganych terminach 24h/72h/30 dni
• Kary umowne — service credits za przekroczenie parametrów. Bo SLA bez konsekwencji to życzenie, nie zobowiązanie

Ochrona SOC w SecIQ zaczyna się od 1 499 PLN miesięcznie.

Umów konsultację i poznaj SLA dla Twojej firmy →

Źródła

• Co to jest SOC — kompletny przewodnik
• Koszty SOC — pełna kalkulacja
• KSC 2.0 — raportowanie incydentów