20 Wskaźników I KPI Cyberbezpieczeństwa Do Śledzenia W 2026 r.

Co naprawdę mierzyć w cyberbezpieczeństwie?

W świecie cyberbezpieczeństwa liczby nie kłamią. Kluczowe Wskaźniki (KPI) pozwalają zmierzyć, jak skutecznie bronimy się przed atakami, zamiast zgadywać na podstawie przeczucia. W 2026 roku, przy coraz sprytniejszych atakach (np. wykorzystujących AI) i rosnącej presji regulacyjnej, mierzenie wyników staje się obowiązkowe. jeżeli nie da się czegoś zmierzyć, nie da się tym efektywnie zarządzać – ta stara zasada menedżerska dotyczy także bezpieczeństwa IT.

Dlatego potrzebujemy konkretnych metryk. KPI w cyberbezpieczeństwie to nasze drogowskazy: pokazują, gdzie jesteśmy odporni, a gdzie dziury w obronie są największe. Zamiast ogólników, skupimy się na 20 konkretnych wskaźnikach – wraz z technicznymi przykładami, jak je liczyć i interpretować w praktyce.

Dlaczego to ma znaczenie?

Mierzalność = świadomość. Ataki zdarzają się każdemu, ale organizacje różnią się tym, jak gwałtownie je wykrywają i reagują. o ile nie śledzimy takich rzeczy jak czas wykrycia włamania czy liczba nieudanych logowań, działamy po omacku. KPI eliminują zgadywanie – dostarczają twardych danych do decyzji biznesowych. Dzięki nim wiemy, czy nowe narzędzie bezpieczeństwa faktycznie obniżyło ryzyko, czy szkolenia pracowników przynoszą efekt, i czy budżet na cyberbezpieczeństwo jest wydawany z sensem. Ma to bezpośredni wpływ na decyzje zarządu: łatwiej uzasadnić zakup nowych zabezpieczeń, jeżeli pokażemy, iż np. skróciliśmy średni czas reakcji o 50%. Co więcej, KPI to wspólny język z biznesem – przekładają techniczne szczegóły na liczby zrozumiałe dla kierownictwa. Zamiast mówić “mamy milion logów dziennie”, lepiej pokazać “incydenty kosztują nas średnio X PLN, ale nasze działania skróciły przestój o Y godzin”. Takie dane budują świadomość ryzyka na poziomie zarządczym i pomagają ustalać priorytety.

Brak mierzalności to ryzyko. jeżeli nie monitorujemy kluczowych wskaźników, możemy przeoczyć narastający problem – np. coraz dłuższy czas wdrażania poprawek (łatki zalegają miesiącami) albo spadającą skuteczność filtrów phishingowych. Wskaźniki działają jak alarm: sygnalizują odchylenia zanim dojdzie do poważnego incydentu. Wreszcie, wiele regulacji (RODO, NIS2, ISO 27001 itd.) wymaga wykazania, iż aktywnie zarządzamy bezpieczeństwem. Regularne raportowanie KPI to dowód, iż panujemy nad sytuacją, mamy kontrolę i spełniamy wymagania audytów. Krótko mówiąc – mierząc cyberbezpieczeństwo, łatwiej je poprawiać i udowadniać, iż nasze działania działają.

Przejdźmy teraz do 20 konkretnych wskaźników i KPI, pogrupowanych tematycznie. Każdy wskaźnik omówimy pod kątem: co mierzy, jak go obliczyć, jak interpretować wyniki, a także podamy przykład z praktyki (np. fragment logu, polecenie lub prosty algorytm). Wszystko w sposób techniczny, ale przystępny – jak rozmowa dwóch kolegów z zespołu SOC przy porannej kawie.

Wskaźniki czasu wykrycia i reakcji (Detection & Response)

Cel: zmierzenie, jak gwałtownie wykrywamy zagrożenia i przywracamy normalność po incydencie. Czas działa tu na korzyść atakującego – im szybciej zareagujemy, tym mniejsze szkody.

1. Średni czas wykrycia (MTTD) – Mean Time to Detect
   Co to mierzy: średni czas od momentu wystąpienia incydentu (np. włamania, infekcji) do chwili, gdy zespół bezpieczeństwa go wykryje i zarejestruje. MTTD mówi nam, jak długo zagrożenie może przebywać niezauważone w systemie.
   Jak liczyć: potrzebujesz znaczników czasu zarówno z momentu faktycznego początku incydentu, jak i z momentu detekcji/alertu. Ten pierwszy bywa trudny do ustalenia (np. czas pierwszego złośliwego działania wykryty w logach). W praktyce więc często liczymy od czasu pierwszego podejrzanego zdarzenia w logach do czasu wygenerowania alertu. Obliczamy różnicę dla wszystkich incydentu, a następnie wyciągamy średnią z wielu przypadków. Przykładowo, jeżeli w logu serwera widać, iż atak zaczął się o 01:10, a nasz system SIEM wypluł alert o 01:15, to dla tego incydentu MTTD = 5 minut. W skali miesiąca uśredniamy takie wartości. Można to zautomatyzować skryptem, np. parsując logi: # Pseudokod: oblicz różnicę między czasem alertu a czasem zdarzenia krytycznego
   grep „ALERT” /var/log/alerts.log > alerts.txt
   # Załóżmy, iż log zawiera ID incydentu i znacznik czasu alertu.
   # Mamy osobno log incydentów źródłowych inc.log z czasem zdarzenia.
   while read alert_line; do
   inc_id=$(echo „$alert_line” | awk '{print $3}’)
   alert_time=$(echo „$alert_line” | awk '{print $1″ „$2}’)
   event_time=$(grep „$inc_id” /var/log/inc.log | awk '{print $1″ „$2}’)
   # wylicz różnicę czasów (np. w sekundach) pomiędzy alert_time a event_time
   …
   done < alerts.txt Jak interpretować: im krótszy MTTD, tym lepiej. Krótki czas wykrycia oznacza, iż nasze systemy i analitycy gwałtownie zauważają podejrzane aktywności. Skrócenie MTTD zmniejsza czas, w którym atakujący pozostaje niezauważony w sieci (tzw. dwell time). jeżeli MTTD wynosi godziny lub dni – czerwone światło! – coś nam umyka (np. brakuje monitoringu krytycznych systemów albo reguły detekcji są za mało czułe). Dla kontekstu warto porównać MTTD z benchmarkami branżowymi albo poprzednimi okresami. Przykład: średnia w branży to 1 godzina, a u nas 15 minut – to sygnał, iż nasz SOC działa sprawnie. jeżeli odwrotnie – argument za wprowadzeniem lepszego monitoringu lub szybszych alertów.
2. Średni czas potwierdzenia (MTTA) – Mean Time to Acknowledge
   Co mierzy: średni czas od wygenerowania alertu/detekcji incydentu do momentu, gdy człowiek z zespołu przeanalizuje i potwierdzi, iż to rzeczywisty incydent (czyli nie fałszywy alarm). Mówiąc wprost: ile czasu alert „leży”, zanim ktoś kiwnie, iż tak, działamy.
   Jak liczyć: logujemy znacznik czasu, kiedy alert trafił do systemu zgłoszeń (ticketing) oraz czas, kiedy analityk go podjął lub oznaczył jako „w trakcie”. Różnica to MTTA dla danego zdarzenia. Średnią liczymy np. na podstawie wszystkich alertów wysokiego priorytetu z ostatniego miesiąca. W narzędziu helpdesk/SIEM często widać czasy podjęcia zgłoszeń – można je wyeksportować (CSV, API) i po prostu wyliczyć średnią. jeżeli takich narzędzi brak, choćby prosty skrypt grep + awk na pliku logów alertów może dać radę.
   Interpretacja: niskie MTTA oznacza, iż zespół szybko reaguje na alerty, mamy dobre procesy typu on-call i alerty nikomu nie umykają. Wysokie MTTA (np. wiele godzin) sugeruje problem – może za dużo alertów (toniemy w hałasie informacyjnym) albo braki kadrowe w SOC. Regularne przeglądy MTTA pokazują, czy nasze ulepszenia (np. lepsze filtrowanie alertów, automatyzacja powiadomień) działają. Ten wskaźnik dobrze jest powiązać z procedurami – np. polityka, iż krytyczny alert musi być przejrzany w 15 minut. jeżeli MTTA nagle rośnie, to sygnał aby przeanalizować, gdzie w procesie powstaje opóźnienie (czy alerty nie docierają na pager? czy zbyt częste fałszywe alarmy rozleniwiają ekipę?).
3. Średni czas powstrzymania (MTTC) – Mean Time to Contain
   Co mierzy: ile czasu zajmuje opanowanie incydentu od chwili, gdy go wykryjemy. „Opanowanie” oznacza zatrzymanie rozprzestrzeniania ataku lub ograniczenie jego skutków – np. odłączenie zainfekowanej maszyny od sieci, zablokowanie konta napastnika, zatrzymanie wycieku danych. MTTC liczymy od momentu wykrycia incydentu do momentu wdrożenia środków zaradczych, które powstrzymały dalszy rozwój ataku.
   Jak liczyć: najważniejsze są znaczniki czasowe: (a) detekcji incydentu, (b) podjęcia akcji zaradczej, która zatrzymała eskalację. Źródła danych to np. system ticketowy (czas oznaczenia incydentu jako „zawierzony/contained”) lub logi z narzędzi automatyzacji (SOAR) potwierdzające wykonanie akcji (np. „2026-07-01 10:35:26 – ISOLATE HOST X”). dla wszystkich incydentu liczysz Δt = t(Contain) – t(Detect), potem średnia. jeżeli brak automatycznych logów, można wymagać od analityków manualnego rejestrowania czasu opanowania (choć to mniej dokładne).
   Interpretacja: krótki MTTC = sprawne opanowanie incydentów. Oznacza to, iż procedury izolacji działały, zespół wiedział co robić i nie zwlekał. Duży MTTC wskazuje, iż choć wykrywamy problemy, to zbyt długo pozostają one aktywne w systemie. Przykładowo, jeżeli malware rozprzestrzenia się po sieci przez 4 godziny zanim ktoś go zablokuje – mamy pole do poprawy. Monitorując MTTC, możemy usprawniać narzędzia i procesy reagowania: może warto zainwestować w automatyczne blokowanie na firewallu, lepsze playbooki, szybszy obieg decyzji. Ten wskaźnik bezpośrednio wpływa na ograniczenie szkód – szybkie „zamknięcie wektora ataku” to mniej danych wykradzionych czy mniejszy obszar skażony przez ransomware. Docelowo chcemy MTTC tak niskie, jak to możliwe – liczone w minutach, nie godzinach.
4. Średni czas przywrócenia/usunięcia zagrożenia (MTTR) – Mean Time to Resolve/Recover
   Co mierzy: MTTR w kontekście cyberbezpieczeństwa to średni czas od wykrycia incydentu do pełnego przywrócenia normalnego stanu. Obejmuje zarówno usunięcie zagrożenia (remediation), jak i odzyskanie sprawności systemów (recovery). Innymi słowy: ile czasu mija, aż incydent zostanie w pełni „zamknięty”, a wszystkie systemy działają jak przedtem.
   Jak liczyć: mierzymy czas od wykrycia incydentu (t0, np. alert w SIEM) do oficjalnego zamknięcia incydentu (tn, np. ticket oznaczony jako rozwiązany, systemy przywrócone, raport powłamaniowy gotowy). Warto opracować standard określania tego momentu końcowego – np. gdy ostatni dotknięty system wrócił do produkcji i przeprowadzono weryfikację, iż zagrożenie nie powróci. Źródła danych: system zarządzania incydentami, oś czasu w raporcie powłamaniowym lub po prostu logi z komunikatami typu „Incident XYZ closed at 17:45”. Wyliczamy średnią dla wielu incydentów, często osobno dla różnych kategorii incydentów (inne MTTR będzie dla drobnego malware na stacji, a inne dla dużego wycieku danych).
   Interpretacja: MTTR to ogólny miernik skuteczności i sprawności zespołu. Krótki MTTR oznacza minimalizację skutków – gwałtownie wykryliśmy, opanowaliśmy i naprawiliśmy szkody. Długi MTTR sygnalizuje, iż gdzieś jest problem: może brakuje nam planów awaryjnych, może przywracanie danych z backupu trwa wieki albo koordynacja działań kuleje. Skracanie MTTR bezpośrednio przekłada się na mniejsze straty finansowe i operacyjne. Ważne jest jednak, by nie iść na skróty kosztem jakości – incydent zamknięty pochopnie wróci jak bumerang. Dlatego MTTR analizujemy wraz z retrospektywami incydentów: czy coś wydłużyło proces? (np. brak dostępu do narzędzi, opóźnienie decyzji biznesowej o wyłączeniu serwera). Wreszcie, porównanie MTTR do średniej rynkowej daje pogląd, czy nasza zdolność do regeneracji systemów jest poniżej czy powyżej przeciętnej. W 2026 r. wielu menedżerów oczekuje MTTR liczonych w godzinach, nie dniach – co stawia poprzeczkę wysoko.

Wskaźniki dostępu i uwierzytelniania (Identity & Access)

Cel: kontrola nad tym, kto i jak ma dostęp do systemów, oraz jak skuteczne są nasze mechanizmy uwierzytelniania. W dobie modelu Zero Trust skupiamy się na tym, by adekwatni ludzie mieli dostęp, a napastnicy – nie.

5. Odsetek kont z wymuszonym MFA – (Wdrożenie wieloskładnikowego uwierzytelniania)
   Co mierzy: procent kont użytkowników chronionych co najmniej dwoma składnikami uwierzytelniania (MFA – Multi-Factor Authentication). Mówiąc prościej: ile % naszych kont (pracowników, administratorów, partnerów) wymaga czegoś więcej niż samego hasła przy logowaniu. To jeden z najważniejszych wskaźników „higieny” bezpieczeństwa dostępu.
   Jak liczyć: najpierw określ pełną liczbę kont w krytycznych systemach (AD, VPN, poczta, systemy biznesowe). Następnie sprawdź, dla ilu z nich włączono MFA. W wielu organizacjach jest to konfigurowalne globalnie – np. polityka wymuszająca MFA na wszystkich kontach domenowych poza wyjątkami. Można wykorzystać skrypty lub API systemu tożsamości (IdP) do wylistowania kont bez MFA. Przykład prostego podejścia: jeżeli używamy Linuksa i ssh z kluczami+hasłem jako MFA, można policzyć konta z konfiguracją klucza publicznego vs ogólną liczbę kont. W AzureAD/Office365 da się wyciągnąć raport „Users with MFA enabled”. Wzór: (Liczba kont z MFA / ogólna liczba kont) * 100%.
   Interpretacja: dążymy do 100%. Im wyższy wskaźnik MFA, tym lepiej zabezpieczona organizacja przed przejęciem kont. Phishing hasła staje się wtedy mniej groźny, bo atakujący i tak potrzebuje drugiego czynnika. jeżeli wskaźnik jest niski, priorytetem powinno być wdrożenie MFA przynajmniej dla kont uprzywilejowanych i dostępu zdalnego. Wiele ataków zaczyna się od słabego lub wykradzionego hasła, więc MFA to must-have – w 2026 r. brak MFA na ważnych kontach to proszenie się o kłopoty. Uwaga: monitoruj też wyjątki i wyłączenia MFA. jeżeli 95% kont ma MFA, a 5% nie ma – trzeba rozumieć dlaczego (np. konta serwisowe? starsze systemy bez obsługi MFA? to też ryzyko do zarządzania).
6. Liczba i przegląd kont uprzywilejowanych
   Co mierzy: ile mamy kont z uprawnieniami administracyjnymi (root, administrator domeny, konta z prawami instalacji systemu itp.) oraz czy regularnie kontrolujemy zasadność ich istnienia. Można to ująć jako wskaźnik: % kont uprzywilejowanych zrecertyfikowanych w terminie (czyli jaki odsetek tych kont przeszło okresowy przegląd uprawnień).
   Jak liczyć: najpierw inwentaryzacja: np. liczba członków grup domenowych Administrators, Domain Admins, Root na serwerach Linux, konta serwisowe z uprawnieniami. Źródłem danych będzie AD (dla środowisk Windows) – tu prosty skrypt PowerShell wylistuje członków grup adminów. W systemach linuksowych – lista użytkowników z UID=0 lub należących do sudoers. Następnie, ustalamy politykę przeglądu: np. co kwartał właściciele tych kont muszą potwierdzić, iż uprawnienia są potrzebne. Wskaźnik może brzmieć: „100% kont uprzywilejowanych zweryfikowanych w ostatnich 6 miesiącach”. Liczymy go dzieląc liczbę skontrolowanych/odnowionych uprawnień przez ogólną liczbę takich kont. jeżeli jest system IAM, można z niego wyciągnąć raport recertyfikacji.
   Interpretacja: Im mniej kont uprzywilejowanych, tym lepiej, a te które istnieją powinny być pod stałą kontrolą. Każde konto admina to potencjalne „otwarte drzwi” dla atakującego, więc minimalizujemy ich liczbę i regularnie sprawdzamy, czy przez cały czas są potrzebne. jeżeli wskaźnik recertyfikacji spada (np. tylko 50% kont przeszło przegląd w terminie) – istnieje ryzyko, iż mamy “zapomniane” konta z wysokimi uprawnieniami, o których nikt już nie pamięta, a które mogą zostać wykorzystane. Trend liczby kont uprzywilejowanych też jest istotny: jeżeli rośnie – czy na pewno każdy nowy admin jest konieczny? Ten wskaźnik często ujawnia „stare” konta adminów po byłych pracownikach lub konta serwisowe z nieograniczonymi prawami. Dobrym wynikiem jest stabilna lub malejąca liczba takich kont oraz 100% regularnych przeglądów (audytorzy to uwielbiają). To świadczy o dojrzałości zarządzania tożsamością.
7. Wskaźnik nieudanych logowań (Failed Login Rate)
   Co mierzy: liczbę nieudanych prób logowania w odniesieniu do wszystkich prób logowania, w określonym czasie. Pokazuje nam to intensywność ataków na hasła i konta (np. ataków typu brute force, credential stuffing) oraz ewentualne problemy użytkowników z logowaniem (np. po wdrożeniu MFA). Wysoki odsetek nieudanych logowań może sygnalizować, iż ktoś próbuje złamać hasła albo iż użytkownicy zapominają hasła/mylą się, co też jest cenną informacją.
   Jak liczyć: analizujemy logi uwierzytelnienia (np. /var/log/auth.log w systemach Linux, logi domeny Windows, VPN, itp.). Szukamy wpisów oznaczających nieudane logowanie. Przykład z sysloga Linux: linie zawierające Failed password for user .... Możemy policzyć je w bashu: # Policz wszystkie nieudane logowania w ciągu ostatniej doby
   grep „Failed password” /var/log/auth.log | grep „$(date '+%b %d’)” | wc -l Podobnie zbieramy całkowitą liczbę prób logowań (np. linie Accepted password lub sumując udane i nieudane). Wskaźnik = (nieudane / wszystkie) * 100%. W środowiskach korporacyjnych dane z różnych systemów można zebrać do SIEM i tam wyliczyć tę metrykę bardziej kompleksowo.
   Interpretacja: niski procent nieudanych logowań (np. <1%) zwykle oznacza normalną pracę – użytkownicy rzadko się mylą, ataków siłowych brak. Wzrost wskaźnika może oznaczać atak na konta: np. nagle 20% prób logowania to błędne hasła, co wskazuje na skanowanie haseł lub próbę odgadnięcia cudzego konta. Może to też wskazać problem po stronie użytkowników (np. zmieniliśmy politykę haseł i wielu nie może się zalogować za pierwszym razem). W kontekście bezpieczeństwa interesuje nas głównie wykrycie nietypowych skoków. Taki wskaźnik można powiązać z alertem – np. jeżeli w ciągu godziny jest >1000 nieudanych logowań, automatycznie powiadom SOC. Ponadto, liczba nieudanych logowań ma znaczenie przy ocenie skuteczności naszych mechanizmów blokowania (np. czy po 5 błędnych próbach konto jest blokowane?). jeżeli atak słownikowy może generować tysiące nieudanych prób, to znak, iż brakuje ograniczeń. Monitorując ten KPI, zapewniamy sobie dodatkowy radar na ciche ataki na hasła.

Wskaźniki phishingu i świadomości użytkowników (Phishing & Awareness)

Cel: ocena, na ile ludzie w organizacji są przygotowani na ataki socjotechniczne. Człowiek bywa najsłabszym ogniwem, więc te wskaźniki pokazują skuteczność szkoleń i testów, a także realne powodzenie ataków phishingowych.

8. Wskaźnik kliknięć w phishing (Phishing Click Rate)
   Co mierzy: odsetek użytkowników, którzy kliknęli w link lub załącznik phishingowy. Zwykle mierzony podczas symulowanych kampanii phishingowych (kontrolowanych testów świadomości) – np. ile osób spośród 1000 odbiorców podstępnego maila dało się nabrać i kliknęło. Można też mierzyć rzeczywiste incydenty phishingowe, ale tam trudniej o dokładne dane (chyba iż mamy telemetrię z systemów bezpieczeństwa poczty).
   Jak liczyć: jeżeli prowadzimy kampanie phishingowe wewnętrznie lub z pomocą firmy, zwykle dostajemy raport: np. „30% pracowników otworzyło mail, 12% kliknęło link, 5% podało hasło na fałszywej stronie”. Interesuje nas głównie metryka kliknięć. Wystarczy więc: (liczba użytkowników, którzy kliknęli / liczba użytkowników, którzy otrzymali mail) * 100%. Warto segmentować wyniki według działów czy ról – może się okazać, iż np. dział finansów klika częściej niż dział IT. Dane bierzemy z narzędzia do testów phishing (które rejestruje kliknięcia) albo, jeżeli budujemy własne testy, logujemy każde wejście na kontrolowaną stronę phishingową.
   Interpretacja: niższy wskaźnik kliknięć = wyższa czujność załogi. Ideał to 0%, ale to utopia. jeżeli np. tylko 2% dało się nabrać – jest bardzo dobrze. jeżeli 30% – alarm: pracownicy klikają, w co popadnie. Wysoki wskaźnik oznacza, iż szkolenia albo nie dotarły, albo są nieskuteczne, bo ludzie przez cały czas odruchowo klikają w podejrzane treści. To sygnał dla działu bezpieczeństwa, by zintensyfikować treningi, przypomnieć najlepsze praktyki i może przeprowadzić dodatkowe kampanie. Można też wyciągnąć wnioski co do rodzaju podstępu – np. jeżeli największym wzięciem cieszą się fałszywe e-maile z HR o podwyżkach, to wiemy, na co są podatni. Trend jest kluczowy: spadek wskaźnika kliknięć w kolejnych testach świadczy o poprawie świadomości (uczymy się na błędach), wzrost – wręcz przeciwnie. W 2026 r. phishing to przez cały czas najczęstszy wektor ataku, więc ten KPI traktujmy poważnie. Wysoki odsetek kliknięć uzasadnia inwestycje w szkolenia i kampanie uświadamiające.
9. Wskaźnik raportowania phishingu
   Co mierzy: procent podejrzanych wiadomości phishingowych zgłoszonych przez użytkowników do zespołu bezpieczeństwa, spośród wszystkich, które do nich dotarły. Ten wskaźnik pokazuje odwrotną stronę medalu: nie tylko czy ludzie nie dają się nabrać, ale czy są aktywnie czujni i alarmują o zagrożeniu. Przykładowo, jeżeli pracownik otrzymał phishing i od razu przesłał go na adres security@twojafirma, to jest to „raportowanie phishingu” – chcemy, aby takich zachowań było jak najwięcej.
   Jak liczyć: do tego potrzebna jest kooperacja IT i SOC. jeżeli mamy dedykowany mechanizm (przycisk w Outlooku „Zgłoś phishing” lub specjalny mailbox), liczmy ile zgłoszeń przyszło vs. ile faktycznie było phishingów w obiegu. Licznik: liczba unikalnych zgłoszonych phishingów przez użytkowników. Mianownik: szacowana liczba phishingów, które dotarły na skrzynki (np. z logów bramki email wynika, iż 50 maili z danej kampanii trafiło do skrzynek). jeżeli trudno to ustalić, można mierzyć czas do zgłoszenia – np. ile minęło od rozpoczęcia kampanii phishingowej do chwili, gdy pierwszy pracownik nas powiadomił. Ale trzymajmy się prostszego: % zgłoszonych. Przykład: z 10 identycznych phishingów, które przeszły przez filtry, pracownicy zgłosili 3 – wskaźnik = 30%.
   Interpretacja: Im wyższy wskaźnik raportowania, tym lepiej. To znaczy, iż pracownicy nie tylko rozpoznają phishing (nie klikają), ale też pomagają aktywnie w obronie, alarmując SOC zanim inni wpadną w pułapkę. jeżeli wskaźnik jest bliski zeru – ludzie kasują podejrzane maile, ale ich nie zgłaszają, albo co gorsza w ogóle nie zauważają zagrożenia. Wysoki wskaźnik (np. >50%) to marzenie – oznacza kulturę bezpieczeństwa, gdzie personel traktuje sprawę serio. Ten KPI idzie w parze z poprzednim: dobrze wyszkolony zespół będzie i nie klikać, i zgłaszać. Dla SOC takie zgłoszenia to złoto: dają wczesne ostrzeżenie o nowych kampaniach ataków. Warto nagradzać (choćby pochwałą) za zgłoszenia, żeby motywować ludzi. jeżeli wskaźnik rośnie w czasie – szkolenia przynoszą efekt w postaci zaangażowania pracowników. To także argument dla biznesu, iż inwestycja w uświadamianie personelu się zwraca (ludzie stają się „czujnikami” wyłapującymi zagrożenia).
10. Pokrycie i skuteczność szkolenia bezpieczeństwa
    Co mierzy: na ile nasi pracownicy są przeszkoleni z cyberbezpieczeństwa oraz jakie efekty to przynosi. Można go rozbić na dwa wskaźniki: pokrycie szkoleniami (np. % pracowników, którzy ukończyli obowiązkowe szkolenie) oraz wyniki testów wiedzy (np. średni wynik quizu po szkoleniu, albo zdawalność). Ogólnie chodzi o efektywność programu podnoszenia świadomości.
    Jak liczyć: jeżeli firma ma obowiązkowe szkolenia e-learning co rok, to podstawowy KPI to % pracowników, którzy ukończyli szkolenie na czas. Dane z systemu LMS (Learning Management System) albo z list obecności na warsztatach. Drugi aspekt: czy coś z tego wiedzą? To można mierzyć poprzez quizy/egzaminy – np. średni wynik testu końcowego (w % poprawnych odpowiedzi) lub % osób, które zdały powyżej ustalonego progu (np. 80%). Jeszcze innym wskaźnikiem może być liczba incydentów spowodowanych błędem pracownika – im mniejsza, tym skuteczniejsze szkolenia, ale to już trudniej przypisać wprost. Skupmy się na twardych danych: uczestnictwo i wyniki.
    Interpretacja: Chcemy, by wszyscy pracownicy byli przeszkoleni (100% ukończenia szkolenia) i żeby wiedza została zrozumiana (np. średni wynik testu >90%). jeżeli widzimy, iż tylko 60% zaliczyło szkolenie, to znak, iż reszta wymaga dopilnowania – bo nieświadomy pracownik to potencjalna ofiara ataku. Słabe wyniki testów mówią, iż materiał był niezrozumiały lub niewystarczający – może trzeba zmienić formę szkolenia albo częściej je powtarzać. Ten KPI jest często wymagany przez compliance (np. normy typu ISO 27001 pytają o szkolenia), a także istotny po incydentach: jeżeli zdarzył się incydent z winy pracownika, zarząd na pewno zapyta „czy my ich w ogóle szkoliliśmy?”. Mając liczby, możemy wykazać, iż tak, 95% przeszkolonych, ale i tak znaleźli się tacy, co kliknęli – wtedy decyzja może być, by np. zwiększyć częstotliwość szkoleń albo skierować dodatkowe treningi do grupy bardziej ryzykownej. Dobrą praktyką jest utrzymywanie bazy pytań i wyników, by zidentyfikować, które tematy są najsłabiej rozumiane (np. wszyscy mylą pojęcia phishing vs malware – poprawmy to w następnym szkoleniu). Sumarycznie: ten wskaźnik to papierek lakmusowy naszej kultury bezpieczeństwa w firmie.

Wskaźniki podatności i łatania (Vulnerability & Patch Management)

Cel: zmierzenie, jak dobrze organizacja radzi sobie z lukami w oprogramowaniu – od momentu wykrycia podatności do załatania systemów. W tej kategorii patrzymy na to, jak gwałtownie i skutecznie zamykamy dziury, zanim wykorzystają je przestępcy.

11. Średni czas łatania podatności (Patch Time)
    Co mierzy: średnią liczbę dni (lub godzin) potrzebnych na wdrożenie poprawek bezpieczeństwa od chwili ich wydania lub wykrycia podatności. Nazywa się to też vulnerability patching rate lub patch latency. Innymi słowy: ile czasu nasze systemy pozostają podatne od momentu, gdy wiadomo, iż trzeba wgrać łatkę.
    Jak liczyć: potrzebne są dwa momenty w czasie: (a) kiedy dana podatność została zidentyfikowana lub patch wydany (np. data publikacji CVE lub data wydania patcha przez dostawcę), oraz (b) kiedy u nas zaaplikowano poprawkę na wszystkich wymagających tego systemach. Różnica to czas podatności. W praktyce liczymy to dla wielu podatności i uśredniamy, albo wybieramy medianę. Często dzieli się na kategorie wg krytyczności: np. czas łatania krytycznych podatności. Przykład: 1 stycznia pojawia się patch na krytyczny błąd Windows, u nas wszystkie serwery mają go zainstalowanego 10 stycznia – czas łatania = 9 dni. Podobnie dla innych aktualizacji w miesiącu, potem średnia. Źródła danych: system zarządzania poprawkami (WSUS, WSUS-u podobne, czy skaner podatności) powie, kiedy dany host przestał zgłaszać daną lukę. Można też manualnie logować daty instalacji łatki.
    Interpretacja: Im krócej, tym lepiej. Cyberprzestępcy często wykorzystują okno między wydaniem patcha a jego zaaplikowaniem ofiarom – im to okno mniejsze, tym mniejsza szansa, iż zostaniemy trafieni znaną podatnością. W roku 2026 oczekuje się, iż krytyczne poprawki są wdrażane w ciągu kilkudziesięciu godzin, góra kilku dni. jeżeli nasz średni czas łatania to np. 30 dni – zdecydowanie za długo, to zaproszenie dla atakujących (mają miesiąc na exploit!). Tę metrykę często monitoruje się pod kątem zgodności z polityką – np. polityka mówi: krytyczne łatki w 7 dni, ważne w 30 dni itd. Wtedy KPI pokazuje procent spełnienia (np. „80% krytycznych łat załataliśmy w ciągu tygodnia, reszta przekroczyła termin”). Kiedy średni czas rośnie, musimy szukać przyczyny: może zbyt rzadkie okna serwisowe, może brak automatyzacji, albo dużo błędów przy testach poprawek. Ważne, by mierzyć to regularnie i patrzeć trend – spadek średniego czasu łatania to znak, iż nasz proces patch management się poprawia (np. wprowadziliśmy cotygodniowe aktualizacje zamiast comiesięcznych). Z kolei wzrost może być sygnałem, iż zespół nie wyrabia z liczbą poprawek (tu przyda się priorytetyzacja). Dla biznesu ta liczba przekłada się na zmniejszenie ryzyka incydentów: szybkie łatki = mniej incydentów z exploitów.
12. Wskaźnik zgodności z aktualizacjami (Patch Compliance)
    Co mierzy: procent systemów lub aplikacji, które posiadają zainstalowane najnowsze krytyczne poprawki. Inaczej: odsetek środowiska zgodny z bieżącym poziomem poprawek bezpieczeństwa. To komplementarne do czasu łatania – pokazuje pokrycie naszego procesu aktualizacji.
    Jak liczyć: skanery podatności albo systemy zarządzania łatkami mogą wygenerować taki raport. Np. jeżeli na 100 serwerów 90 nie zgłasza żadnych brakujących krytycznych patchy, a 10 ma zaległe, to wskaźnik = 90%. Można liczyć osobno dla stacji roboczych, serwerów, urządzeń sieciowych. Dane z narzędzi jak Microsoft WSUS/SCCM: ile % komputerów jest w pełni „patch compliant” według definicji (tj. ma wszystko zainstalowane co ważne). Innym sposobem jest posiadanie bazy softu i wersji, i sprawdzanie, czy wersje są >= najnowsze dostępne (ale to żmudne). Zautomatyzowane skanery robią to za nas – często w raporcie bezpieczeństwa jest coś typu „Patch compliance: 85%”.
    Interpretacja: Dążymy do 100% – choć w praktyce zawsze będzie parę odstających maszyn (np. testowych, odłączonych od sieci, itp.). Wysoki wskaźnik oznacza, iż większość naszych systemów jest na bieżąco z poprawkami, co znacząco zmniejsza ryzyko udanych ataków przez znane luki. Niski wskaźnik (np. 60%) to czerwony alarm: niemal połowa infrastruktury jest podatna bo nie ma aktualizacji! Przy analizie warto wgryźć się w szczegóły: może pewna pula systemów nie jest aktualizowana (np. zapomniane serwery w oddziale, albo urządzenia IoT bez patchy). To też pomaga namierzyć „plamy” w pokryciu procesu patchowania – np. super, iż Windowsy łatamy, ale co z routerami albo bazami danych? Ten KPI jest często raportowany do kierownictwa jako prosty procent – działa na wyobraźnię (łatwiej zrozumieć 90% maszyn załatanych niż szczegóły typu CVE-2026-XYZ). jeżeli stoi w miejscu lub maleje, trzeba podjąć działania: np. dedykować więcej zasobów na łatki, przeszkolić administratorów aplikacji do stosowania patchy, itp. Reguły compliance (np. wymagania audytowe) często narzucają konkretny poziom, np. >95%. Nie bez powodu – wysoka zgodność z patchami to jeden z fundamentów dobrego bezpieczeństwa.
13. Liczba krytycznych podatności nierozwiązanych
    Co mierzy: ile mamy aktualnie otwartych, niezałatanych podatności o krytycznym poziomie ważności. To taki wskaźnik typu backlog bezpieczeństwa – pokazuje nam, jak duża jest „kupka” poważnych dziur czekających na załatanie.
    Jak liczyć: wykorzystujemy system skanowania podatności lub rejestr podatności. zwykle każda znaleziona podatność ma przyznany poziom ważności (np. CVSS 8-10 to krytyczne). Liczba krytycznych otwartych to po prostu zliczenie wszystkich unikatowych przypadków (np. „Windows Server X podatny na CVE-2026-1234”) o statusie nierozwiązane. Można też liczyć liczbę systemów z krytycznymi lukami. Raporty Vulnerability Management narzędzi (np. Nessus, Qualys) wprost dają liczbę krytycznych findings. jeżeli nie mamy takiego narzędzia, trzeba utrzymywać listę manualnie, co jest trudne – zainwestujmy lepiej w skaner .
    Interpretacja: idealnie dążymy do zera – żadna krytyczna podatność nie powinna zostać pozostawiona bez rozwiązania w rozsądnym czasie. jeżeli wskaźnik rośnie lub utrzymuje się >0 przez długi czas, oznacza to, iż gdzieś tkwi wielka dziura bezpieczeństwa. Często bywa, iż jakaś poprawka nie może być zastosowana (bo np. system legacy by padł) – wtedy ta podatność „wisi”. Warto monitorować trend: malejąca liczba krytycznych luk = robimy postępy, rosnąca = być może odkrywamy nowe szybciej niż łatamy stare (zły znak) albo zaniedbaliśmy jakiś obszar. Ten wskaźnik bywa używany jako KRI (Key Risk Indicator) dla zarządu: np. „Mamy 2 krytyczne luki w systemie produkcyjnym – czy akceptujemy to ryzyko?”. jeżeli miesiąc do miesiąca te same 2 wiszą, to pytanie dlaczego nic z tym nie zrobiono. Można też liczyć średni „wiek” otwartych podatności krytycznych (ile dni minęło od wykrycia) – to już zaawansowane, ale daje obraz, czy problemy leżą miesiącami, czy raczej dniami. Podsumowując: ta metryka pilnuje, by najważniejsze dziury były traktowane priorytetowo i żeby nigdzie nie zalegała bomba zegarowa czekająca na exploita.

Wskaźniki incydentów i wpływu na biznes (Incidents & Business Impact)

Cel: tu mierzymy ilość incydentów oraz ich konsekwencje finansowe i operacyjne. Chodzi o to, by rozumieć, jak często mamy problemy i ile nas one kosztują – bo to przekłada się na decyzje strategiczne i budżety.

14. Liczba incydentów bezpieczeństwa (w ujęciu miesięcznym/rocznym)
    Co mierzy: totalną liczbę zarejestrowanych incydentów bezpieczeństwa w danym okresie (miesiąc, kwartał, rok). Incydent definiujemy tu jako wykryte zdarzenie naruszające bezpieczeństwo, które wymagało reakcji (np. malware na stacji, próba włamania, wyciek danych, atak DDoS skuteczny itp.). Można dodatkowo rozróżniać kategorie incydentów (np. ile malware, ile phishingów, ile błędów konfiguracyjnych) – to też cenny podgląd trendów.
    Jak liczyć: większość zespołów bezpieczeństwa prowadzi rejestr incydentów – choćby w Excelu, systemie ticketowym lub dedykowanym narzędziu IR. Wystarczy zliczyć wpisy z danego okresu. jeżeli brak formalnego rejestru, warto zacząć go prowadzić! Na potrzeby doraźne, można przeszukać logi w SIEM pod kątem pewnych słów kluczowych, ale najlepiej mieć oficjalną listę incydentów (również ze względów zgodności z np. RODO/NIS2). Załóżmy, iż w Q1 było 5 incydentów (3 malware, 1 phishing, 1 błąd ludzki), w Q2 – 8 incydentów itd. Taki trend prezentujemy.
    Interpretacja: pozornie mniej incydentów = lepiej, bo spokojniej. Ale uwaga: zbyt niska liczba może też znaczyć, iż nie wykrywamy wszystkiego (dużo incydentów może przechodzić niezauważonych). Ważne jest zrozumienie kontekstu. Na przykład, jeżeli wdrożyliśmy nowe systemy monitoringu, liczba wykrytych incydentów może wzrosnąć – i to dobrze, bo wcześniej byliśmy ślepi. Ogólnie jednak, spadek liczby incydentów rok do roku przy niezmienionych metodach detekcji to pozytywny trend (mniej problemów, lepsza prewencja). Wzrost liczby incydentów bywa argumentem za tym, by zwiększyć nakłady na bezpieczeństwo (skoro ataków jest więcej, musimy się wzmocnić) albo by zatrudnić dodatkowych analityków, bo obecni się nie wyrabiają z rosnącą liczbą spraw. Ten wskaźnik dobrze jest skorelować z typem incydentów: np. 5 incydentów phishingowych miesięcznie może być nową normą – wtedy cel to zmniejszyć skuteczność phishingu (poprzez treningi lub lepszy filtr). Ważne: zawsze definjujmy, co liczymy jako incydent. Niektóre organizacje raportują tylko poważne incydenty, inne drobne też. Dla przejrzystości można mieć kategorie: np. incydenty krytyczne – takie, które spowodowały widoczny wpływ na biznes, incydenty pomniejsze – obsłużone rutynowo. Wtedy KPI „liczba incydentów” można rozbić na te kategorie. Przykład interpretacji: „W 2025 mieliśmy 2 poważne incydenty i 25 pomniejszych, w 2026 póki co 0 poważnych i 30 pomniejszych” – co wskazuje, iż może ataków więcej, ale dobrze je neutralizujemy zanim urosną do poważnych.
15. Średni koszt incydentu
    Co mierzy: Cost per Incident – średni bezpośredni koszt finansowy jednego incydentu. Wlicza się w to wszystkie koszty związane z obsługą i skutkami incydentu: czas pracy zespołu (nadgodziny), koszty zewnętrznych ekspertów, straty związane z przestojem systemów, potencjalne kary (np. za wyciek danych), koszty powiadomień klientów, utratę przychodu podczas awarii itp. W dużym uproszczeniu: sumujemy $$$ za wszystkie incydenty i dzielimy przez ich liczbę. Można liczyć osobno dla różnych typów incydentów, bo np. koszt ransomware (z zaszyfrowaną infrastrukturą) będzie drastycznie inny niż koszt pojedynczego zainfekowanego laptopa pracownika.
    Jak liczyć: to trudne, bo wymaga danych z różnych źródeł – nie jest to już proste zliczenie logów, a raczej kalkulacja finansowa. Najlepiej, jeżeli organizacja ma proces post-mortem incydentu, gdzie szacuje się koszty (czas pracy * stawka, koszty materialne, czas przestoju * utracony zysk itp.). jeżeli takie dane istnieją dla wszystkich incydentu, to wystarczy uśrednić. Przykład: w roku były 3 incydenty, ich oszacowane koszty to 10k, 50k, 5k PLN – średni koszt = ~21,6k PLN. Często jednak dokładne kwoty są trudne do uzyskania (lub poufne). Można wtedy wyliczyć tylko na podstawie czasu reakcji i ewentualnych przestojów. Ewentualnie posiłkować się badaniami rynkowymi: np. przeciętny koszt wycieku danych to X zł na rekord. Mimo trudności, warto próbować to estymować – dla zarządu to najbardziej przemawiający wskaźnik (język strat finansowych).
    Interpretacja: Niższy średni koszt = lepsza skuteczność i mniejsze straty. jeżeli rok temu średnio incydent kosztował 100k, a w tym roku 50k, to prawdopodobnie szybciej reagujemy i ograniczamy skutki (albo mieliśmy szczęście, bo nie było dużego incydentu). Pojedynczy koszt może skakać (jeden duży incydent zawyży średnią), więc patrzmy też na mediankę albo przedstawiajmy rozkład. Ten wskaźnik jest świetny do uzasadniania inwestycji: np. “Wdrożenie systemu X za 200k zł zwróciło się, bo średni koszt incydentu spadł o 30% dzięki szybszej reakcji”. Takie rzeczy robią wrażenie na decydentach. Można też liczyć łączny koszt incydentów w skali roku – i np. porównywać z budżetem bezpieczeństwa. jeżeli koszt incydentów przekracza budżet na zabezpieczenia, to znak, iż może lepiej więcej wydać na prewencję niż tracić na skutkach. Warto też rozbijać koszt na składniki, bo to pokazuje, gdzie incydenty bolą najbardziej – czy tracimy dużo przez przestoje (może zainwestować w zapasowe systemy), czy płacimy kary (poprawić ochronę danych osobowych), czy np. ogrom czasu idzie na dochodzenia (zautomatyzować pewne czynności). Reasumując, średni koszt incydentu to KPI, który łączy świat IT z językiem biznesu i pokazuje cyberbezpieczeństwo jako aspekt finansowy, nie tylko techniczny.
16. Średni czas przestoju usług na incydent
    Co mierzy: przeciętny czas, przez który najważniejsze systemy/usługi były niedostępne wskutek incydentu. Jest to adekwatnie składowa kosztu, ale warta osobnego wyróżnienia – szczególnie tam, gdzie ciągłość działania jest krytyczna. Pokazuje, ile czasu (średnio) firma była „w dół” z powodu problemów bezpieczeństwa.
    Jak liczyć: dla wszystkich poważniejszego incydentu notujemy, czy spowodował on przestój (np. wyłączenie systemu ERP, odcięcie segmentu sieci, wyłączenie serwisu www) i jak długo trwała ta niedostępność. Potem uśredniamy. jeżeli większość incydentów nie powoduje przestojów, a tylko pojedyncze tak, to można liczyć średnią tylko z incydentów z przestojem lub uznać, iż incydenty bez wpływu na dostępność mają 0 godzin przestoju (co zaniży średnią, ale da ogólny obraz). Źródła danych: raporty incydentów (tam powinno być odnotowane, czy był downtime), systemy monitoringu dostępności (odnotują awarie), korespondencja do klientów o niedostępności, itp. Przykład: ransomware szyfrował serwery, produkcja stała 8 godzin – to nasz downtime.
    Interpretacja: wiadomo – im mniej przestoju, tym lepiej. Idealnie zero, ale życie pokazuje, iż poważne incydenty często idą w parze z jakimś downtime (choćby planowym, gdy wyłączamy coś celowo, by usunąć zagrożenie). Ten wskaźnik pomaga ocenić odporność operacyjną na incydenty. jeżeli średnio każda większa awaria bezpieczeństwa kładzie nas na 2 dni, to fatalnie – mogą uciekać klienci, łamiemy SLA, tracimy kasę. Dążymy do minimalizacji: godziny, minuty. Co wpływa na skrócenie? Dobre plany awaryjne, ćwiczenia DR (Disaster Recovery), duża automatyzacja przywracania systemów. Często ten wskaźnik analizuje się z perspektywy które systemy padły – np. czy downtime dotyczył systemów krytycznych czy peryferyjnych. W raporcie można wtedy powiedzieć: „Średni przestój krytycznych usług na incydent wyniósł 4h, co oznacza stratę ~X PLN na godzinę. Wdrożenie redundancji mogłoby zmniejszyć ten czas o 50%”. To przekonuje do inwestycji w zapasowe systemy czy mechanizmy ciągłości działania. Ponadto, monitorując ten KPI, organizacja może śledzić, czy poprawia się jej odporność – np. w 2024 średni downtime na incydent: 6h, w 2025: 3h, w 2026: 1h. Taki trend cieszy każdego (poza hackerami).

Wskaźniki infrastruktury i monitorowania (Infrastructure & Monitoring)

Cel: uchwycenie, jak dobrze mamy pod kontrolą inwentarz i infrastrukturę, oraz ile ataków do nas puka. Metryki w tej sekcji dotyczą bezpośrednio systemów i sieci: wykrytych ataków, nieznanych urządzeń, malware i skuteczności naszych narzędzi ochronnych.

17. Liczba zablokowanych prób włamania / ataków
    Co mierzy: ile razy w danym okresie nasze mechanizmy bezpieczeństwa zidentyfikowały i zablokowały próby ataku. Może to obejmować np. włamania sieciowe zatrzymane przez firewall/IDS, ataki webowe zablokowane przez WAF, próby exploitów powstrzymane przez systemy endpoint (EDR). To wskaźnik obrazujący skalę zagrożeń kierowanych przeciwko nam, choćby jeżeli nie zakończyły się incydentem. Często nazywa się to liczba intrusion attempts albo blocked attacks.
    Jak liczyć: sumujemy zdarzenia z systemów bezpieczeństwa, które oznaczają udaremniony atak. Np. firewall loguje „Attack drop, signature XYZ” – zliczamy takie komunikaty. IPS/IDS liczy incydenty, WAF ma statystyki zablokowanych requestów, EDR raportuje zneutralizowane malware itd. Można zebrać te dane w SIEM: np. ilość alertów o wysokiej krytyczności, które zostały automatycznie zablokowane. Przykład: IDS wykrył i zablokował 50 exploitów w ciągu miesiąca, WAF odfiltrował 200 prób SQLi – łącznie 250 zablokowanych ataków. W KPI można też rozdzielić na kategorie (sieć, aplikacje, itp.).
    Interpretacja: ta liczba pokazuje presję ataków na naszą organizację. Często ku zaskoczeniu zarządu, takich prób są setki czy tysiące miesięcznie – a jednak dzięki zabezpieczeniom nie doszło do incydentu. To pomaga uświadomić decydentom, iż „dzieje się”, choćby jeżeli gazet nie obiegła wiadomość o włamaniu do nas. Trend wzrostowy może wynikać z faktycznie większej aktywności atakujących albo z lepszej detekcji (albo nowych systemów, np. uruchomiliśmy nowy sensor i stąd więcej wykrywa). jeżeli widzimy znaczny skok – warto przyjrzeć się kto i jak nas atakuje (może jakaś konkretna grupa wzięła nas na cel?). Wskaźnik ten motywuje do utrzymania i rozwoju ochrony: np. „W tym kwartale zapobiegliśmy 500 atakom sieciowym – wyobraźmy sobie, co by było, gdyby IPS nie działał”. Porównywanie zablokowanych prób do faktycznych incydentów daje też obraz, jak skuteczna jest nasza pierwsza linia obrony. Np. jeżeli z 1000 prób żadna nie przeszła, gratulacje dla firewalli. jeżeli widać, iż mimo blokad pewien typ ataku i tak się przedziera (bo liczba incydentów np. phishingowych rośnie mimo filtrów) – znak, iż trzeba tam wzmocnić ochronę. Podsumowując: wysoka liczba zablokowanych ataków to z jednej strony dobrze (bo zablokowane), z drugiej – przypomnienie, iż zagrożenie jest realne i ciągłe. Śledźmy to, by nie usnąć w samozadowoleniu.
18. Nieznane / nieautoryzowane urządzenia w sieci
    Co mierzy: liczbę urządzeń podłączonych do naszej sieci, których nie rozpoznajemy lub które nie są autoryzowane. Przykładowo, pracownik przynosi własny router, podłącza do sieci – to urządzenie spoza ewidencji. Albo pojawia się nowy sprzęt IoT, o którym nikt nie wie. Ten wskaźnik to miara naszego panowania nad infrastrukturą i shadow IT.
    Jak liczyć: najpierw musimy wiedzieć, co powinniśmy mieć – aktualna inwentaryzacja urządzeń (adresy MAC, IP, nazwy hostów itp.). Potem regularnie skanujemy sieć (np. ARP scan, DHCP logs, skan IP) i wykrywamy adresy/MAC, których nie ma w spisie. To są potencjalnie „nieznane” urządzenia. Liczba może być np. „średnio 5 nierozpoznanych urządzeń tygodniowo pojawia się w sieci”. Można też prowadzić wskaźnik typu: czas wykrycia nowego urządzenia – ale trzymajmy się prostego: ile urządzeń spoza rejestru zostało wykrytych. Źródła: logi serwerów DHCP (wydzierżawione IP dla nowych MAC), systemy NAC (Network Access Control) które wręcz blokują/zgłaszają obce urządzenia, skany sieciowe nmap’em itp.
    Interpretacja: Najlepiej zero – cała infrastruktura jest znana i monitorowana. jeżeli pojawiają się nieautoryzowane urządzenia, jest ryzyko. Może to być luka w polityce (pracownicy podłączają własne urządzenia wbrew zasadom), może urządzenie gościa (czy mamy sieć dla gości izolowaną?), a może choćby intruz wpiął swój sprzęt (np. złośliwy access point ukryty pod biurkiem). Wysoki wskaźnik (np. co dzień coś nowego) wskazuje, iż nie kontrolujemy porządnie sieci lokalnej. Działania naprawcze to: wdrożyć NAC, lepiej prowadzić inwentaryzację, edukować pracowników. Z kolei zerowy wskaźnik długoterminowo daje pewność, iż nic się nie pałęta bez naszej wiedzy (choć warto okresowo to weryfikować, bo 0 może też oznaczać, że… nie szukamy ). Trend spadkowy jest dobry: np. po wprowadzeniu NAC z 10 nieznanych urządzeń na miesiąc spadło do 1 – widać poprawę. Ten KPI ma też wymiar zgodności (np. ISO 27001 wymaga kontroli nad zasobami) – pokazujemy audytorowi: „Monitorujemy sieć, wykryliśmy i usunęliśmy w tym roku 3 nieautoryzowane urządzenia”. Ogólnie: to miara porządku w naszej sieci. Brak nieznanych sprzętów = mniejsze ryzyko, iż ktoś ominął nasze zabezpieczenia stawiając swój „backdoor” sprzętowy.
19. Wskaźnik infekcji malware / wirusów
    Co mierzy: częstość występowania infekcji złośliwym oprogramowaniem w naszej infrastrukturze. Na przykład, ile incydentów związanych z malware odnotowujemy na 1000 urządzeń, albo ile stacji/serwerów miesięcznie łapie wirusa, który wymaga interwencji. To pokazuje, jak dobrze działają nasze antywirusy/EDR i na ile użytkownicy narażają systemy (np. wkładając zainfekowane pendrive’y, ściągając coś z sieci).
    Jak liczyć: zliczamy wykrycia malware w logach systemów ochronnych. Np. antywirus na stacjach roboczych raportuje incydenty (wyleczone infekcje, usunięte wirusy), EDR podobnie. Można tu liczyć samo wykrycie (co jeżeli AV od razu usunął? Też się liczy jako incydent potencjalny). Sposób prezentacji: np. „5 maszyn zainfekowanych malware w ciągu kwartału” albo wskaźnik przeliczony na 1000 urządzeń (żeby normalizować w większych organizacjach). Źródło: konsola centralna antywirusa, która zwykle ma statystyki typu „viruses detected”. Te liczby bywają wysokie (bo każdy zablokowany wirus to też wykrycie), więc można skupić się na tych, które wymagały manualnej interwencji.
    Interpretacja: tu mniej znaczy lepiej – idealnie zero poważnych infekcji. jeżeli jednak wskaźnik wynosi np. 10 infekcji miesięcznie na 1000 komputerów, to znak, iż coś przechodzi przez zabezpieczenia lub użytkownicy robią ryzykowne rzeczy. Trzeba patrzeć też na typy malware: czy to masowe robaki (co może sugerować brak jakiejś poprawki, przez którą się to rozprzestrzenia), czy np. adware od instalowania dziwnych programów przez userów. Trend rosnący sygnalizuje problem – być może skuteczność antywirusa spada w obliczu nowych zagrożeń (czas pomyśleć o innym rozwiązaniu lub dodatkowych warstwach ochrony). Warto też monitorować czas reakcji na infekcję (to już inne KPI powiązane z MTTR). jeżeli wskaźnik infekcji jest wysoki, można to przekładać na ryzyko: „Mamy średnio 5 zainfekowanych komputerów miesięcznie – każdy to potencjalne zagrożenie rozprzestrzenienia się ransomware”. To argument, by np. zwiększyć restrykcyjność polityk (ograniczyć uprawnienia admina lokalnego u użytkowników, zablokować wykonywanie nieznanych plików itp.). Z drugiej strony, bardzo niski wskaźnik (bliski 0) może sugerować, iż nasze kontrole działają skutecznie lub… iż nic nie wykrywają (fałszywe poczucie bezpieczeństwa). Dlatego zawsze interpretujemy to w kontekście posiadanych mechanizmów: jak dobry mamy EDR? czy na pewno by wykrył? jeżeli tak – brawo. jeżeli nie jesteśmy pewni – może infekcje są, tylko niewykryte. Wniosek: monitorujmy i dążmy do minimalizacji wykrytych infekcji, ale jednocześnie dbajmy o skuteczność detekcji, bo lepiej wykryć i liczyć incydent, niż żyć w nieświadomości.
20. Skuteczność ochrony danych (DLP) i zapobiegania wyciekom
    Co mierzy: jak efektywnie nasze mechanizmy DLP (Data Loss Prevention) chronią przed nieautoryzowanym wyniesieniem danych. Można go wyrazić np. jako stosunek udaremnionych prób wycieku danych do wszystkich prób (wykrytych), albo liczbę incydentów wycieku w porównaniu do incydentów zablokowanych. W skrócie: ile potencjalnych wycieków udało się zatrzymać.
    Jak liczyć: systemy DLP (czy to na stacjach, czy na bramkach pocztowych/web) zwykle rejestrują zdarzenia: np. „zablokowano skopiowanie poufnego pliku na pendrive” albo „zaszyfrowano poufny e-mail”. Liczymy ile takich zablokowanych zdarzeń było i (jeśli się da) ile zdarzeń wycieku jednak nastąpiło. To drugie trudniejsze, bo jeżeli DLP nie zadziałało to może się dowiemy dopiero po czasie… Ewentualnie można przyjąć, iż każda udaremniona próba to potencjalny incydent który się nie wydarzył. Wtedy wskaźnik typu „DLP effectiveness” = (zablokowane incydenty DLP / zablokowane + udane incydenty wycieku) * 100%. jeżeli nie mamy danych o udanych wyciekach (bo oby ich nie było), można raportować po prostu liczbę zablokowanych. Np. „DLP zablokowało 15 prób wysłania poufnych danych na zewnątrz w kwartale; faktycznych wycieków: 1”.
    Interpretacja: ta miara daje wgląd w to, czy nasze zabezpieczenia danych spełniają swoją rolę. jeżeli widzimy dużo zablokowanych prób, to z jednej strony dobrze (system działa, ludzie próbowali lub malware próbowało, ale nie wyszło), z drugiej – dlaczego tyle prób? Trzeba przyjrzeć się co ludzie próbują wynosić i czemu. Może potrzebne szkolenie z polityki ochrony danych lub lepsze klasyfikowanie informacji (by pracownicy wiedzieli, co jest poufne). Jeden udany wyciek to już za dużo, ale jeżeli się zdarzył – analizujemy czemu DLP go nie wychwyciło (np. dane nie były oznaczone, użyto kanału, którego nie monitorujemy). Sam wysoki odsetek udaremnień (np. DLP zatrzymało 95% prób) świadczy o skuteczności technicznej systemu, ale ten brakujący 5% może być bardzo bolesny, jeżeli tam uciekły dane. Ważne jest zatem dążenie do minimalizacji udanych wycieków – idealnie zero, i jednocześnie zrozumienie, czy niski poziom zablokowanych prób oznacza brak prób czy brak detekcji. W 2026, z rosnącymi wymaganiami ochrony danych (patrz RODO i ciągłe wycieki na nagłówkach gazet), KPI związane z DLP są często raportowane na poziomie zarządu. Np. „W tym roku nie odnotowaliśmy żadnego wycieku danych osobowych; systemy DLP zadziałały w 20 przypadkach potencjalnego naruszenia”. To buduje zaufanie, iż mamy kontrolę nad wrażliwymi informacjami. jeżeli jest odwrotnie – czas wzmocnić polityki DLP, może wdrożyć szyfrowanie wrażliwych plików, ograniczyć dostępy. Ogólnie, skuteczność DLP trudno wyrazić jednym procentem, ale jakiekolwiek mierzalne dowody działania są lepsze niż nic. Ten wskaźnik uświadamia, iż bezpieczeństwo to nie tylko obrona przed hakerami, ale też pilnowanie własnych danych przed wypłynięciem.

Checklista końcowa

Powyżej zasypaliśmy Cię dwudziestoma metrykami – pora złapać oddech i zastanowić się, jak to ugryźć w praktyce. Oto krótka lista kontrolna, która pomoże wprowadzić te wskaźniki do codziennej pracy:

• Zdefiniuj swoje KPI: Nie musisz od razu mierzyć wszystkich 20. Wybierz te wskaźniki, które najlepiej pasują do Twojego środowiska i ryzyk, np. jeżeli nie masz rozbudowanej sieci wewnętrznej, fokus na MTTD/MTTR i phishing może być ważniejszy niż „nieznane urządzenia”. Z czasem możesz rozszerzać zestaw mierników.
• Sprawdź źródła danych: Upewnij się, iż logujesz zdarzenia potrzebne do wyliczenia KPI. Bez logów z uwierzytelnienia nie policzysz nieudanych logowań; bez skanera podatności nie poznasz liczby luk. Zidentyfikuj luki w telemetryce i dodaj odpowiednie logowanie/monitoring tam, gdzie brakuje (syslog, API systemów bezpieczeństwa, raporty z narzędzi).
• Automatyzuj zbieranie metryk: manualne liczenie na palcach gwałtownie się znudzi. Napisz skrypty (bash, Python) albo wykorzystaj istniejące narzędzia (SIEM, dashboardy) do automatycznego wyliczania wskaźników. Może to być choćby cron co miesiąc generujący raport z najważniejszymi liczbami. Ważne, by dane były aktualne i wiarygodne.
• Ustal punkt odniesienia (baseline): Zanim zaczniesz gonić za poprawą, zmierz swoje obecne wartości KPI jako linię bazową. Np. w tym kwartale MTTD = 4h, phishing click rate = 10%, koszt incydentu ~20k zł. Mając punkt startowy, łatwiej wyznaczysz cele (OK, za kwartał chcemy MTTD < 2h).
• Monitoruj trendy i odchylenia: Same liczby z jednego okresu to za mało. Śledź trend: rysuj wykresy miesięczne, kwartalne. Zwracaj uwagę na skoki i spadki. o ile jakiś wskaźnik nagle odbiega od normy – drąż temat. Może to efekt nowego projektu, zmiany konfiguracji, albo sygnał incydentu, który umknął?
• Raportuj w dwóch językach: Jedne dane – dwa przekazy. Technicznie dla zespołu (szczegóły, logi, wykresy) i biznesowo dla kierownictwa (esencja, ryzyka, $$$). Naucz się przedstawiać KPI tak, by każdy zrozumiał: np. zamiast zanudzać formułami MTTD, powiedz: „Wykrywamy ataki średnio w 15 minut, to dwa razy szybciej niż rok temu – intruzi mają mało czasu w wyrządzenie szkód”.
• Przełącz na tryb “ciągłe doskonalenie”: KPI to nie ozdoba na prezentacji, tylko narzędzie do podejmowania akcji. Wykryłeś słaby punkt (np. wolne łatanie)? – zaplanuj ulepszenia (automatyzacja patchy, dodatkowy etat). Potem patrz, czy wskaźnik się poprawia. Traktuj metryki jak termometr: jeżeli temperatura rośnie, reaguj, zamiast tylko patrzeć.
• Waliduj jakość KPI: Regularnie oceniaj, czy dane wskaźniki faktycznie coś wnoszą. Może któryś KPI stał się zbędny albo źle mierzony? Np. liczba incydentów sama w sobie rośnie, bo lepiej wykrywamy – może trzeba dodać wskaźnik “% incydentów poważnych” by mieć pełniejszy obraz. Koryguj definicje metryk, gdy zmienia się środowisko lub cele firmy.
• Unikaj „paraliżu metrycznego”: Lepiej mieć kilkanaście dobrze zrozumianych wskaźników niż dziesiątki mętnych liczb. Każdy KPI powinien mieć jasno określoną akcję lub decyzję, którą wspiera. jeżeli masz metrykę, na którą nikt nie reaguje i nic z niej nie wynika – usuń ją lub zastąp inną. KPI mają służyć Tobie, nie Ty KPI .

Podsumowanie i następne kroki (CTA)

Metryki i KPI w cyberbezpieczeństwie to potężne narzędzia – dają przejrzystość w świecie pełnym zagrożeń i pozwalają podejmować decyzje oparte na faktach, a nie przeczuciach. Pamiętaj jednak, iż same liczby nie poprawią bezpieczeństwa, to ich analiza i wynikające z nich działania przynoszą zmianę. Dlatego jako praktyk bezpieczeństwa zrób dziś mały krok: sprawdź, co już logujesz i które z opisanych wskaźników możesz od razu wyliczyć z dostępnych danych. Następnie przetestuj swoje alerty i procedury – czy na pewno złapią incydent na czas, by MTTD/MTTR nie poszybowały w górę? Wreszcie, zintegrowuj monitorowanie tych wskaźników na dashboardach i w raportach dla zespołu oraz zarządu. Cyberbezpieczeństwo to ciągły proces – wyposażony w odpowiednie KPI, będziesz mógł nim sterować jak dobrze naoliwioną maszyną, zamiast reagować dopiero, gdy coś się zepsuje. Powodzenia, mierzymy i działamy!

Bibliografia