Umowa SLA SOC: Co Musisz Wiedzieć Zanim Podpiszesz?
Rozważasz outsourcing Security Operations Center i właśnie analizujesz propozycję umowy? Dobrze skonstruowana umowa SOC – a w szczególności zapisane w niej parametry Service Level Agreement – to często ostatnia linia obrony Twojej firmy przed niejasnymi kosztami, długimi przerwami w działaniu lub zbyt wolną reakcją na incydent. W tym artykule wyjaśniamy, co powinno być w SLA bezpieczeństwo, na jakie liczby zwrócić uwagę oraz jak świadomie porównać oferty różnych dostawców SOC, aby finalna decyzja była bezpieczna zarówno dla działu IT, jak i zarządu.
1. SLA w kontekście usług SOC – szybkie przypomnienie
SLA (Service Level Agreement) to formalny dokument definiujący mierzalne parametry usługi. W przypadku SOC kluczowe są:
- Nieprzerwana dostępność monitoringu 24/7/365.
- Czas reakcji SOC na alert (ang. Time to Respond – TTR).
- Time to Contain i Time to Remediate – czyli ile czasu mija od wykrycia do opanowania zagrożenia oraz pełnego przywrócenia środowiska.
- Jasno opisane procedury eskalacji i komunikacji.
W odróżnieniu od SLA na usługi help-desk lub NOC, tutaj mówimy o krytycznej ochronie danych, reputacji i ciągłości biznesu. Dla polskich MŚP to często „być albo nie być” w relacjach z partnerami czy ubezpieczycielem cyber.
2. Dlaczego precyzyjna umowa SOC jest kluczowa dla MŚP?
Większe korporacje posiadają działy prawne i własne CERT-y, które potrafią obronić interesy firmy podczas incydentu. MŚP rzadko ma takie zasoby, dlatego to, co znajdzie się (lub czego zabraknie) w SLA SOC, może zadecydować o:
- minimalizacji przestojów produkcji, sklepu online lub systemu ERP,
- wysokości ewentualnych kar umownych i odszkodowań,
- łatwości uzyskania odszkodowania z polisy cyber,
- bezproblemowej współpracy z organami regulacyjnymi (np. KNF, UODO).
3. Kluczowe elementy, które muszą znaleźć się w SLA bezpieczeństwa
3.1 Zakres i granice odpowiedzialności
Koniecznie zdefiniuj, co jest monitorowane (stacje robocze, serwery, Office 365, aplikacje chmurowe, OT) oraz w jakim stopniu SOC odpowiada za reakcję. Czy tylko dostarcza alert i rekomendację, czy też wykonuje zdalnie działania naprawcze?
3.2 Dostępność usługi 24/7
Minimalna dostępność podawana jest zwykle w procentach (np. 99,9%). Sprawdź, jak przeliczana jest każda minuta niedostępności na ewentualne kary. W praktyce różnica między 99,5% a 99,9% to ponad 21 godzin rocznie.
3.3 Czas reakcji SOC
Najczęściej definiowany w poziomach priorytetu:
- P1 (krytyczny): ≤ 15 minut
- P2 (wysoki): ≤ 30 minut
- P3 (średni): ≤ 4 godzin
Zwróć uwagę, od którego momentu liczony jest czas – od wygenerowania alertu przez SIEM, od wejścia do systemu ticketowego SOC, czy od chwili, gdy Ty potwierdzisz zdarzenie? Różnice bywają kluczowe.
3.4 Poziomy eskalacji i komunikacji
Dla MŚP liczy się prostota. Dobry SLA definiuje:
- numery i e-maile do on-call analityków,
- czas oczekiwania na feedback od klienta do dalszych działań,
- kiedy i na jakim poziomie angażowany jest zarząd.
3.5 KPI i raportowanie
Nawet najlepsze SOC bez sensownych wskaźników w SLA trudno realnie rozliczyć. Standardem są:
- % incydentów obsłużonych w czasie,
- średni Mean Time to Detect (MTTD), Mean Time to Respond (MTTR),
- częstotliwość i zakres raportów (miesięczne, kwartalne, ad-hoc).
3.6 Kompetencje zespołu i zaplecze technologiczne
Warto dopisać, że analitycy posiadają określone certyfikaty (np. SC-200, AZ-500, ISO 27001 Lead Implementer) oraz pracują na uznanych technologiach – przykładowo na Microsoft Sentinel i Defender XDR, których telemetria pokrywa całe środowisko Microsoft 365, Azure i urządzenia końcowe.
3.7 Współdzielona odpowiedzialność
SOC nie zastąpi wszystkich zadań działu IT. Umowa powinna jasno określać, jakie logi i dostępy dostarcza klient, kto utrzymuje polityki backupu, a kto odpowiada za aktualizacje systemów.
3.8 Poufność danych i lokalizacja
Dla kancelarii prawnych, medycznych czy firm finansowych kluczowe jest, aby dane analityczne nie opuszczały UE, a najlepiej Polski. Sprawdź, czy SLA gwarantuje taką lokalizację (np. region Azure Poland Central).
3.9 Klauzule kar umownych i exit plan
Nikt nie lubi o tym mówić przed podpisaniem, ale sprawny exit plan oraz realne kary za niedotrzymanie SLA działają motywująco na dostawcę i zapewniają Ci spokojny sen.
4. Typowe pułapki w SLA SOC – ku przestrodze
Analizując kilkadziesiąt umów podsuwanych polskim MŚP, najczęściej spotykamy się z:
- „Czas reakcji liczony w godzinach… w dni robocze” – zero wsparcia w sobotę o 2:00 nad ranem.
- Sztywna definicja “incydentu” – jeśli zdarzenie nie spełnia ściśle opisanych kryteriów, nie zostanie przyjęte do obsługi.
- Kary liczone od „potwierdzenia awarii”, a nie od jej wystąpienia.
- Brak prawa do audytu – klient nie może zweryfikować faktycznej pracy SOC.
W praktyce produkcyjna firma z woj. śląskiego straciła 1,5 dnia pracy linii montażowej, bo atak ransomware miał miejsce w długi weekend, a dostawca SOC działał jedynie w biurowych godzinach. Wszystko zgodnie z umową.
5. Jak ocenić dostawcę SOC przed podpisaniem umowy?
- Pilot lub PoC – minimum 14 dni monitoringu na żywym środowisku.
- Referencje z podobnej branży – najlepiej polskiej.
- Transparentność dashboardu – klient powinien widzieć w czasie rzeczywistym status alertów.
- Weryfikacja procedur – poproś o schemat eskalacji i raport z przykładowego incydentu.
6. Model rozliczeń a gwarancje SLA
Popularne są dwa podejścia:
- Ryczałt miesięczny — przewidywalny koszt, ale dopilnuj, aby uniknąć ograniczeń ilości alertów („fair-use”).
- Opłata per incydent — atrakcyjna, jeśli incydentów jest mało, lecz może zniechęcać dostawcę do szybkiego wykrycia.
Niezależnie od modelu, SLA powinno zawierać finansowe konsekwencje dla dostawcy w przypadku przekroczenia czasów.
7. Renegocjacja SLA – kiedy i jak?
SOC oraz środowisko IT stale się zmieniają. Warto:
- Ustalić w umowie cykl przeglądu SLA (np. co 6 miesięcy).
- Zapisać prawo do adjustacji KPI wraz z rozbudową środowiska lub zmianą regulacji (RODO, NIS2).
- Wprowadzić mechanizm Continuous Improvement – np. kwartalne warsztaty IR.
8. Jak robi to SOcCloud.io – przykład dobrych praktyk
Choć każdy SLA tworzymy wspólnie z klientem, kilka elementów traktujemy jako non-negotiable:
- Reakcja P1 ≤ 15 minut, liczona od wygenerowania alertu w Microsoft Sentinel.
- Polskojęzyczni analitycy 24/7 oraz drugi zespół reagowania w modelu follow-the-sun (redundancja).
- Połączenie AI z Microsoft Defender XDR i doświadczenia człowieka; średni MTTD poniżej 5 minut.
- Dashboard w czasie rzeczywistym w ramach licencji Microsoft 365/Azure – bez dopłat.
- Raport podsumowujący incydent maks. 24 h po zamknięciu.
Dzięki pełnej specjalizacji w ekosystemie Microsoft możemy gwarantować pojedynczy punkt kontaktu i brak „spychologii” między vendorami, co z perspektywy MŚP upraszcza zarządzanie ryzykiem i budżetem.
9. Podsumowanie
Świadomie skonstruowana umowa SOC to nie tylko formalność. To realna gwarancja, że w krytycznym momencie:
- zespół reagowania będzie przy Twoich systemach w kilkanaście minut,
- koszty i odpowiedzialność są jasno określone,
- dane i reputacja firmy pozostaną bezpieczne.
Zanim podpiszesz, przejdź checklistę kluczowych punktów: zakres usług, czasy reakcji, procedury eskalacji, KPI, kary i exit plan. Tylko wtedy zyskasz pewność, że Twój biznes jest chroniony zgodnie z ryzykiem i regulacjami branżowymi.
