Jak wybrać dostawcę SOC w Polsce — 11 pytań, które musisz zadać

Dlaczego wybór dostawcy SOC to nie jest zakup narzędzia

Kupując firewall, porównujesz specyfikacje techniczne. Kupując SOC, powierzasz komuś codzienną odpowiedzialność za bezpieczeństwo organizacji. To bliżej wyboru lekarza niż wyboru oprogramowania.

Problem w tym, że każdy dostawca na rynku obiecuje to samo: monitoring 24/7, wykrywanie zagrożeń, reakcję na incydenty. Różnice ujawniają się dopiero pod presją — o 3 w nocy, w weekend, gdy leci ransomware.

Poniżej 11 pytań, które pozwolą Ci odróżnić realne kompetencje od prezentacji sprzedażowej.

1. Czy reagujecie, czy tylko powiadamiacie?

To pytanie eliminuje połowę rynku.

Wielu dostawców oferuje „monitoring 24/7", który w praktyce oznacza: widzimy alert, wysyłamy e-mail do Twojego IT. O 3 w nocy. W sobotę. Do osoby, która śpi.

Pytaj konkretnie: Jeśli wykryjecie ransomware o 2 w nocy w sobotę — co robicie? Izolujecie zagrożony endpoint? Blokujecie skompromitowane konto? Czy czekajcie, aż ktoś u nas przeczyta e-mail?

Realna wartość SOC to containment w minutach — nie alert w skrzynce.

2. Jaki jest SLA na czas reakcji w godzinach pozabiurowych?

Dane są jednoznaczne: 76% ataków ransomware rozpoczyna się w nocy, weekendy lub święta. Atakujący znają rozkłady zmian IT.

Pytaj o SLA z podziałem:

• Czas reakcji w godzinach biurowych (poniedziałek-piątek 8-17)
• Czas reakcji w nocy (17-8)
• Czas reakcji w weekendy i święta
• Czas reakcji w długie weekendy (majówka, Boże Narodzenie)

Jeśli odpowiedź to „taki sam 24/7" — dobrze. Jeśli zaczyna się od „no, w weekendy mamy dyżur telefoniczny..." — wiesz, na czym stoisz.

3. Gdzie przechowujecie logi?

To pytanie, które zbyt mało firm zadaje. A powinno być jednym z pierwszych.

Profesjonalni atakujący po uzyskaniu dostępu do sieci zamrażają lub usuwają logi. Jeśli logi są na tym samym serwerze, który został skompromitowany — tracisz dowody. Nie odtworzysz łańcucha ataku. Nie dotrzymasz terminów raportowania KSC 2.0.

Szukaj dostawcy, który przechowuje logi w chmurze — fizycznie poza infrastrukturą klienta. W SecIQ używamy Azure Sentinel z retencją w chmurze Microsoft, poza zasięgiem lokalnego atakującego.

4. Czy znacie moje środowisko?

Model „jeden analityk na 300 klientów" oznacza, że nikt nie wie, jak wygląda „normalne" w Twojej firmie. Analityk widzi alert, ale nie wie, czy logowanie z Rumunii o 23:00 to atak czy Twój handlowiec na delegacji.

Pytaj o model pracy:

• Czy mam dedykowanego opiekuna bezpieczeństwa?
• Jak często się spotykamy (operacyjnie, nie sprzedażowo)?
• Czy analityk zna specyfikę mojej branży?
• Czy znacie moją infrastrukturę, polityki, wyjątki?

Model concierge — z dedykowanym opiekunem, który zna Twoje środowisko — daje fundamentalnie inne wyniki niż anonimowa platforma alertów.

5. Jak wygląda onboarding i ile trwa?

Dostawca, który mówi „podłączymy się w 2 godziny", prawdopodobnie podłączy agenta na endpointach i nazwie to „SOC". Prawdziwe wdrożenie wymaga:

• Mapowania infrastruktury i zasobów
• Konfiguracji źródeł logów (SIEM)
• Dostrojenia reguł detekcji do specyfiki firmy
• Ustalenia procedur eskalacji i kontaktów
• Testowania reakcji (tabletop exercise)

Realistyczny czas wdrożenia pełnego SOC: 2-4 tygodnie. Wdrożenie w 48h jest możliwe dla podstawowego monitoringu (to oferujemy w SecIQ), ale pełne dostrojenie trwa dłużej — i tak powinno być.

Dlaczego to ważne? Bo w pierwszych tygodniach SOC uczy się, co jest „normalne" w Twojej firmie. Bez tego okresu kalibracji będziesz zalewany fałszywymi alarmami — a Twój zespół IT zacznie ignorować powiadomienia. I wróci to samo, od czego zacząłeś.

6. Co się dzieje po incydencie?

Incydent to nie koniec — to początek procesu doskonalenia. Pytaj:

• Czy po incydencie aktualizujecie reguły detekcji?
• Czy dostaję raport post-incydentowy (root cause analysis)?
• Czy wspieracie raportowanie do CSIRT wg wymogów KSC 2.0?
• Czy proponujecie konkretne zmiany w konfiguracji, żeby zapobiec powtórce?

Dobry SOC buduje odporność organizacji na co dzień. Po każdym incydencie firma powinna być bezpieczniejsza niż przed nim. Jeśli dostawca kończy pracę na „incydent zamknięty" — to za mało.

7. Jaką rolę gra AI w Waszym SOC?

To pytanie, które jeszcze dwa lata temu nie miało sensu. Dziś dzieli dostawców na dwie kategorie.

Pierwsza kategoria: dostawcy, u których AI to slajd w prezentacji sprzedażowej. „Wykorzystujemy sztuczną inteligencję" — ale w praktyce analityk ręcznie przegląda każdy alert, ręcznie wzbogaca kontekst, ręcznie pisze raport. Alert o 3:17 w nocy dostaje mniej uwagi niż ten o 9 rano, bo analityk jest zmęczony.

Druga kategoria: dostawcy, u których AI realnie pracuje. Klasyfikuje alert w sekundach. Wzbogaca kontekst — sprawdza reputację IP, historię konta, wzorce behawioralne. Wskazuje analitykowi „tu popatrz" — z taką samą dokładnością o północy co w południe. Ale decyzję — izolacja, blokada, eskalacja — podejmuje zawsze człowiek.

Pytaj konkretnie: Jaki jest średni czas triażu alertu? Jakie zadania wykonuje AI, a jakie analityk? Czy AI klasyfikuje alerty automatycznie, czy tylko „wspiera" analityka (co zwykle oznacza, że analityk robi wszystko sam)?

W SecIQ AI jest czwartym filarem operacyjnym — nie marketingowym. Klasyfikacja alertu trwa sekundy, nie kilkanaście minut. Analityk weryfikuje i decyduje, zamiast przesiewać szum.

8. Jakie technologie używacie — i czy ze sobą rozmawiają?

To nie pytanie o listę logotypów, lecz o integrację i korelację.

• Czy platforma koreluje zdarzenia cross-domain (endpoint + poczta + tożsamość + chmura)?
• Czy widzicie pełny łańcuch ataku, czy tylko fragmenty?
• Czy narzędzia współpracują natywnie, czy to patchwork z 5 vendorów?

W SecIQ postawiliśmy na natywny ekosystem Microsoft Security (Sentinel + Defender XDR), bo korelacja cross-domain w ramach jednej platformy daje fundamentalnie lepszą widoczność niż łączenie narzędzi od różnych vendorów. Phishing, przejęte konto, lateral movement i eksfiltracja — jeden widok, nie cztery osobne konsole.

9. Jak wyglądają raporty?

Raport z SOC, który zawiera „87 432 zdarzeń, 12 alertów HIGH" — nie mówi zarządowi nic. Pytaj:

• Czy raporty są w języku biznesowym (nie tylko technicznym)?
• Czy zawierają KPI i trendy (poprawa/pogorszenie w czasie)?
• Czy zawierają rekomendacje (co zrobić, żeby było lepiej)?
• Jak często je dostaję? (comiesięcznie minimum)

Dobry raport daje zarządowi poczucie kontroli — wie, co się dzieje, jak firma jest chroniona i co warto poprawić.

10. Czy wspieracie compliance KSC 2.0 / NIS2?

KSC 2.0 wymaga nie tylko monitoringu, ale też:

• Raportowania incydentów w terminach (24h / 72h / 30 dni)
• Dokumentacji procedur reagowania
• Audytowalności logów i zdarzeń
• Nadzoru nad łańcuchem dostaw

Pytaj, czy dostawca SOC aktywnie wspiera compliance, czy to jest „osobna usługa za dodatkową opłatą". W SecIQ wsparcie compliance jest częścią usługi — bo rozdzielanie monitoringu od raportowania nie ma sensu operacyjnego.

KSC 2.0 to nie jednorazowy projekt — to ciągły obowiązek. Dostawca, który pomoże Ci zdać audyt raz, ale nie wesprze raportowania incydentu w sobotę o 2 w nocy — rozwiązuje połowę problemu.

11. Mogę porozmawiać z Waszym klientem?

Najlepszy test. Jeśli dostawca nie może podać referencji — to red flag. Jeśli klient powie „tak, reagowali o 2 w nocy w weekend i było dobrze" — to więcej niż najładniejsza prezentacja.

Bonus: jedno pytanie, które mówi najwięcej

Po zadaniu 11 pytań powyżej, dodaj jedno na koniec: „Opowiedzcie mi o ostatnim poważnym incydencie, który obsługiwaliście."

Dostawca z prawdziwym doświadczeniem opowie konkretną historię — z timeline'em, decyzjami i lekcjami. Dostawca bez doświadczenia zacznie mówić ogólnikami albo powoła się na „poufność". Poufność to ważna rzecz — ale dobry dostawca potrafi opowiedzieć historię bez ujawniania nazw klientów.

To pytanie nie jest w oficjalnej liście, bo nie ma na nie „poprawnej odpowiedzi". Ale jakość odpowiedzi mówi więcej niż jakikolwiek certyfikat na ścianie.

Checklista przed podpisaniem umowy

• Dostawca reaguje, nie tylko powiadamia
• SLA na noc i weekendy jest konkretny i taki sam jak w dzień
• Logi przechowywane w chmurze, poza zasięgiem atakującego
• Mam dedykowanego opiekuna (model concierge)
• Po incydencie aktualizowane są reguły i procedury
• Raporty w języku biznesowym z rekomendacjami
• Wsparcie KSC 2.0 w pakiecie, nie za dodatkową opłatą
• Mogę porozmawiać z klientem dostawcy

Umów bezpłatną konsultację z SecIQ →

Źródła

• Ustawa o KSC 2.0 — obowiązki podmiotów
• Co to jest SOC — kompletny przewodnik
• SOC vs MDR vs MSSP — porównanie modeli