10 wskaźników jakości SOC, które powinien raportować każdy dostawca

Czy z punktu widzenia klienta lepiej być traktowany jak przysłowiowa pieczarka -trzymana w ciemności i karmiona … byle czym – i żyć w błogiej iluzji, że „bezpieczeństwo jest zapewnione”?
Czy jednak lepiej mieć pełny wachlarz możliwości weryfikacji pracy zespołu, któremu powierzamy stabilność i bezpieczeństwo całej organizacji?

Właśnie dlatego powstały wskaźniki jakości działania zespołu Security Operation Center.
Nie po to, żeby zasypywać kogoś tabelkami, ale po to, żeby klient wiedział, czy rzeczywiście płaci za bezpieczeństwo, czy tylko za poczucie bezpieczeństwa lub zgodność z wymaganiami. Dostawca dzięki stosowaniu i raportowaniu wskaźników może udowodnić, że jego praca to nie puste deklaracje ani marketing — tylko konkret, mierzalne efekty i prawdziwa odpowiedzialność.

Poniżej znajdziesz 10 praktycznych KPI, które realnie są stosowane w mierzeniu działania zespołu SOC. 

MTTD – Mean Time to Detect

Jak szybko SOC wykrywa incydent?

MTTD mierzy średni czas od wystąpienia incydentu do jego wykrycia przez SOC.

Co mierzy: 

• skuteczność detekcji, 
• czas reakcji systemów monitorujących, 
• zdolność SOC do szybkiego zauważenia anomalii.

Krótki MTTD ogranicza możliwość lateral movement, eskalacji uprawnień i utraty danych.

Przykład:

• Incydent rozpoczął się o 01:00 → wykryto o 01:12 → MTTD = 12 min
  Typowy dobry poziom: 8–20 minut

MTTA – Mean Time to Acknowledge

Ile czasu mija, zanim analityk zacznie obsługę alertu?

MTTA to czas od wygenerowania alertu do momentu, gdy analityk rozpocznie jego obsługę.

Co mierzy: 

• gotowość operacyjną SOC, 
• szybkość reakcji zespołu, 
• zgodność z SLA.

Jest to podstawowa metryka potwierdzająca, że SOC działa w trybie 24/7.

Przykład:
• Alert o 02:00 → analityk podjął o 02:03 → MTTA = 3 min
•     Typowe SLA: MTTA < 15 min czas podjęcia alertu, < 5 min dla alertów krytycznych

<5 minut – wyjątkowa responsywność, zespoły są bardzo skuteczne.

6–10 minut – dobra wydajność, mogą być potrzebne niewielkie ulepszenia.

11–15 minut – średnia wydajność, należy sprawdzić procesy pod kątem potencjalnych opóźnień.

>15 minut – słaba wydajność, konieczne są natychmiastowe działania w celu poprawy.

MTTI – Mean Time to Investigate

Jak szybko SOC wykonuje analizę incydentu?

MTTI to średni czas od podjęcia alertu do zakończenia triage i określenia, czy zdarzenie stanowi realne zagrożenie.

Co mierzy: 

• tempo pracy analityków, 
• efektywność procesu triage, 
• jakość procedur i automatyzacji.

Długi czas analizy opóźnia działania obronne i zwiększa ryzyko eskalacji incydentu.

Przykład:

• Alert podjęto o 10:00 → analiza zakończona o 10:18 → MTTI = 18 min

MTTR – Mean Time to Respond / Remediate

Jak szybko SOC doprowadza incydent do pełnego rozwiązania?

MTTR mierzy czas od potwierdzenia incydentu bezpieczeństwa do jego pełnego rozwiązania, obejmującego działania takie jak usunięcie malware, zresetowanie skompromitowanych poświadczeń, przywrócenie konfiguracji, wdrożenie poprawek lub inne czynności remediacyjne zależne od charakteru incydentu.

Co mierzy: 

• skuteczność procesu reagowania na incydenty, 
• zdolność SOC do współpracy z zespołami IT i systemowymi, 
• czas potrzebny na wdrożenie działań naprawczych, 
• operacyjną sprawność i organizację pracy, 
• jakość procedur reagowania i remediacji. 

MTTR jest jednym z najistotniejszych wskaźników potwierdzających dojrzałość operacyjną SOC. Nawet szybkie wykrycie i analiza incydentu nie wystarczy, jeśli jego usunięcie zajmuje zbyt dużo czasu. Krótki MTTR ogranicza szkody biznesowe, redukuje ryzyko ponownej infekcji i minimalizuje przestoje usług.

Przykład:

• Incydent potwierdzony: 09:00 
• Remediacja zakończona: 10:15

→ MTTR = 1h 15m 

Oczekiwany poziom KPI: 

• W incydentach wysokiego ryzyka: 1–4 godziny 
• W incydentach operacyjnych o niższym priorytecie: < 24 godzin
  (Wartości zależą od modelu współpracy SOC–IT oraz zakresu usługi.) 

Coverage Level / Monitoring Coverage

Jak duża część środowiska jest faktycznie monitorowana?

Coverage Level określa procent środowiska klienta objętego monitoringiem oraz możliwościami detekcji.

Co mierzy: 

• procent monitorowanych hostów/ źródeł/ systemów / aplikacji, 
• procent dostarczanych logów, 
• procent wykrywanych kluczowych technik MITRE ATT&CK.

Skuteczność SOC jest bezpośrednio zależna od widoczności środowiska. Braki w pokryciu oznaczają blind spoty.

Przykład

• 85% hostów monitorowanych 
• 92% wymaganych logów dostarczanych 
• 70% kluczowych technik ATT&CK z detekcją

Detection Rate (DET)

Jaki procent incydentów SOC wykrywa?

DET określa stosunek wykrytych incydentów do liczby incydentów, które faktycznie wystąpiły.

Co mierzy: 

• skuteczność detekcji, 
• jakość reguł i źródeł telemetrycznych.

Niski DET oznacza, że część incydentów pozostaje niewykryta.

Przykład:

• 20 incydentów → 17 wykrytych → DET = 85%

False Positive Rate (FPR)

Ile alertów okazuje się fałszywymi alarmami?

FPR to procent alertów, które po analizie nie stanowiły incydentu.

Co mierzy: 

• jakość reguł detekcyjnych, 
• poziom szumu alertowego, 
• obciążenie analityków. 

Wysoki FPR obniża efektywność i zwiększa ryzyko przeoczenia incydentu.

Przykład:

• 100 alertów → 40 fałszywych → FPR = 40%
  Dobry poziom: < 15%

Incident Closure Rate

Jaki procent incydentów SOC skutecznie zamyka?

Incident Closure Rate określa, ile incydentów zakończono pełną analizą i działaniami zgodnie z procedurą.

Co mierzy: 

• efektywność operacyjną SOC, 
• zdolność finalizowania incydentów, 
• poziom zaległości operacyjnych (backlog).

Niedomknięte incydenty zniekształcają obraz bezpieczeństwa i obciążają zespół.

Przykład:

• 450 incydentów otwartych → 430 zamkniętych → 95%

Incident Escalation Rate

Ile incydentów musi zostać przekazanych do wyższego poziomu SOC?

Incident Escalation Rate określa procent incydentów, które muszą zostać przekazane z L1 do L2/L3.

Co mierzy: 

• kompetencje analityków pierwszej linii, 
• jakość triage, 
• złożoność incydentów.

Wysoka eskalacja = przeciążenie L2/L3. Zbyt niska eskalacja = ryzyko, że L1 zajmuje się incydentami ponad swoje kompetencje.

Przykład:
• 600 incydentów → 120 eskalowanych → 20%

Alert Volume per Analyst

Jakie jest dzienne obciążenie analityków?

Alert fatigue to zjawisko, w którym analitycy SOC są przeciążeni nadmierną liczbą alertów, co prowadzi do spadku koncentracji, opóźnień w reakcji i ryzyka przeoczenia realnego zagrożenia. Alert Volume per Analyst określa średnią liczbę alertów przypadających na jednego analityka — im wyższa wartość, tym większe ryzyko błędów i obniżenia jakości obsługi incydentów. Może on stanowić jeden z mierników wskazujących na zjawisko alert fatigue.

Co mierzy:

• obciążenie operacyjne,
• ryzyko przeciążenia zespołu (tzw.„alert fatigue”),
• zdolność SOC do utrzymania jakości analizy.

Przykład:
• 1200 alertów dziennie / 6 analityków → 200 alertów/osobę
• Optymalnie: 60–80 alertów dziennie

Stosowanie jasno zdefiniowanych, mierzalnych i realnych do zastosowania KPI w usłudze SOC jest równie ważne jak w każdej innej, profesjonalnie świadczonej usłudze – zwłaszcza gdy odpowiada za nią zewnętrzny dostawca. Dzięki temu organizacja może mierzyć jakość, porównywać efektywność i mieć pewność, że bezpieczeństwo nie opiera się na deklaracjach, lecz na realnych wynikach.  

Klient nie chce być wspomnianą pieczarką. Chce wiedzieć:

• czy ktoś faktycznie patrzy w te logi,
• czy alerty mają sens,
• czy incydenty są wykrywane na czas,
• czy dostawca robi więcej niż tylko wysyła PDF raz w miesiącu.

Dzięki tym 10 KPI klient widzi czarno na białym, co dostaje, a dostawca — jeśli jest profesjonalny — może udowodnić, że robi kawał dobrej roboty.

Bez KPI klient nie ma możliwości oceny jakości, a dostawca nie ma jak potwierdzić wartości usług. Dlatego zestaw metryk opisanych powyżej jest powszechnie stosowanym standardem rynkowym w usługach SOC.

Tabela porównawcza KPI SOC

---