Wypalenie CISO: dlaczego same podwyżki nie wystarczą

W badaniu IANS/Artico 34% specjalistów od bezpieczeństwa planuje zostać u obecnego pracodawcy. Sprawdź, co badania mówią o płacach, obciążeniu i wsparciu zespołów.

Ernest Bursa

Ernest Bursa

Founder · · 17 min czytania
Two security leads at a whiteboard on a plant-filled co-working mezzanine, reviewing hand-drawn severity queue rows labeled critical 72h, high 7d and medium 14d in morning light

Rosnące obciążenie operacyjne i ograniczone zasoby to częste problemy CISO. Cztery obserwacje z badań: budżety na bezpieczeństwo urosły w 2025 roku raptem o 4%, najwolniej od pięciu lat, a tylko 11% CISO uważa swoje zespoły za wystarczająco obsadzone; 46% liderów bezpieczeństwa poświęca więcej czasu na utrzymanie narzędzi niż na obronę organizacji; 52% CISO mówi, że ich zakres obowiązków przestał być w pełni do opanowania; wypalenie sięga 63% w organizacjach, które nie widzą całości swojej pracy, i 44% tam, gdzie tę widoczność zbudowano. Same dane o wynagrodzeniu nie wyjaśniają więc sytuacji zespołu.

W ostatniej parze wyników różnica wynosi 19 punktów procentowych. To związek między widocznością pracy a wypaleniem, a nie dowód, że sam pomiar usuwa przyczyny wypalenia.

Wysokie płace nie wystarczają, by zatrzymać pracowników

W bezpieczeństwie płaci się dobrze i coraz lepiej, a ludzie i tak odchodzą. Od tej sprzeczności trzeba zacząć każdą sensowną rozmowę o zatrzymaniu ludzi w zespole.

IANS Research i Artico Search przepytały ponad 500 specjalistów od bezpieczeństwa na potrzeby 2026 Cybersecurity Talent Report, opublikowanego w kwietniu 2026 roku. Główny wniosek: tylko 34% zamierza zostać u obecnego pracodawcy.

To samo badanie podaje medianę wynagrodzenia analityka bezpieczeństwa na poziomie 113 000 dolarów, architekta bezpieczeństwa na około 188 000, a lidera funkcji bezpieczeństwa na 256 000, przy czym duże korporacje płacą 18–20% powyżej średniej (dane IANS/Artico za Security Boulevard, bo sam raport jest płatny). Około dwie trzecie respondentów nie zadeklarowało pozostania w obecnej roli.

Wysokie płace same nie wystarczają, by zatrzymać ludzi.

Co naprawdę zmierzyły badania o wypaleniu

Dane o wypaleniu cytuje się zwykle jako jeden przedział. Niesłusznie. Cztery badania z lat 2025–2026 objęły cztery różne populacje i zadały cztery różnie sformułowane pytania. Nie można więc połączyć ich wyników w jeden odsetek wypalonych CISO.

Źródło Kogo pytano Próba Wynik
Proofpoint, 2025 Voice of the CISO CISO w organizacjach 1000+ osób, 16 krajów 1600 63% doświadczyło wypalenia lub było jego świadkiem w ostatnim roku
Splunk, CISO Report 2026 CISO wypowiadający się o swoich zespołach 650 blisko dwie trzecie zespołów bezpieczeństwa na poziomie umiarkowanego lub silnego wypalenia
Sophos, The Human Cost of Vigilance specjaliści IT i cyberbezpieczeństwa, 17 krajów 5000 76% wypalonych „stale, często lub od czasu do czasu”
Bitsight, State of Cyber Risk and Exposure 2025 liderzy ryzyka i bezpieczeństwa, organizacje 500+ 1000 47% zgłasza wyczerpanie

W 63% Proofpointa mieszczą się ludzie, którzy wypalenie tylko obserwowali u innych. Sophos pytał szerszą populację IT i policzył odpowiedź „od czasu do czasu”. Liczba Splunka dotyczy zespołów, a relacjonują ją ich szefowie. Bitsight zapytał ten sam szczebel co Proofpoint i dostał 47%.

Badania wskazują na częste wyczerpanie i wypalenie. Konkretny odsetek zależy od badanej grupy, pytania i definicji, więc przy podawaniu wyniku zachowaj te informacje.

Podwyżka nie zastępuje wsparcia w pracy

Podwyżki działają. Po prostu nie tak, jak zakłada większość planów zatrzymania ludzi, a najmocniejszy dowód pochodzi od samych badaczy wynagrodzeń. IANS i Artico piszą to wprost we własnym raporcie: „Wynagrodzenie pozostaje ważne, ale nie jest głównym czynnikiem decydującym o pozostaniu w firmie”. Wyjaśniają to dwa wyniki.

Wzrost płacy liczy się bardziej niż jej poziom. Pracownicy, którzy dostają nawet skromne podwyżki, deklarują wyraźnie wyższą satysfakcję i częściej zostają niż ci z zamrożonym wynagrodzeniem. Podwyżka działa jak sygnał, że ktoś zauważył. Sama kwota waży mniej niż fakt, że coś drgnęło.

Poczucie wsparcia organizacji przebija wszystko inne. Wśród osób z bezpieczeństwa, które widzą, że firma traktuje bezpieczeństwo priorytetowo, 73% jest zadowolonych ze swojej ścieżki zawodowej. Wśród tych, które nie czują żadnego wsparcia organizacji, zadowolonych jest 19%. To różnica 54 punktów procentowych. Badanie nie wycenia jednak kosztu zapewnienia takiego wsparcia.

Więc nie, nie przestawaj dawać podwyżek. Niedopłacanie to najszybszy sposób, żeby stracić ludzi z powodu, który w pełni kontrolujesz. Pamiętaj jednak o ograniczeniu: podwyżka zamienia sfrustrowanego inżyniera w nieco lepiej opłacanego sfrustrowanego inżyniera, jeżeli kolejka nadal nie ma dna. To, co dzieli 73% od 19%, sprowadza się do tego, czy widać, że organizacja traktuje bezpieczeństwo poważnie. Zespół potrzebuje widocznego wsparcia w codziennej pracy.

Na co naprawdę schodzą godziny

Zakres obowiązków rośnie, a wzrost budżetów i zatrudnienia zwalnia.

Budżety rosną wolniej. Security Budget Benchmark firm IANS i Artico, prowadzony od kwietnia 2025 roku wśród 587 CISO, pokazał, że wzrost budżetów na bezpieczeństwo wyhamował do 4% rok do roku, najniżej od pięciu lat, wobec 8% w 2024. Udział bezpieczeństwa w wydatkach IT spadł z 11,9% do 10,9%, przerywając pięcioletni trend wzrostowy. Wzrost zatrudnienia osiągnął czteroletnie minimum 7%, a tylko 11% CISO uznaje swoje zespoły za wystarczająco obsadzone.

Zakres obowiązków rośnie dalej. 2026 State of the CISO Benchmark tych samych firm (662 CISO, badanie od kwietnia do listopada 2025) pokazał, że 52% uważa swój zakres za niemożliwy do pełnego opanowania, a blisko siedmiu na dziesięciu jest otwartych na zmianę pracy w ciągu najbliższego roku. Splunk w CISO Report 2026 pokazuje mechanizm: prawie wszyscy CISO odpowiadają dziś za nadzór nad AI i związane z nią ryzyko, czterech na pięciu nadzoruje DevSecOps, a blisko trzech na czterech mówi, że rola stała się znacząco bardziej złożona.

Utrzymanie narzędzi pochłania czas. Splunk w State of Security 2025 przepytał wspólnie z Oxford Economics 2058 liderów bezpieczeństwa w dziewięciu krajach. Wyniki pokazują obciążenie pracą operacyjną:

  • 46% poświęca więcej czasu na utrzymanie narzędzi niż na obronę organizacji
  • 59% wskazuje utrzymanie narzędzi jako główne źródło nieefektywności
  • 57% traci czas na śledztwa przez luki w zarządzaniu danymi
  • 59% mierzy się z nadmiarem alertów, 55% z nadmiarem fałszywych alarmów
  • 52% mówi, że ich zespół jest przeciążony
  • 52% przyznaje, że stres w pracy skłonił ich do rozważenia odejścia z cyberbezpieczeństwa w ogóle

Badanie Sapio Research na 300 liderach bezpieczeństwa i IT, opisane przez Help Net Security w marcu 2026, dokłada do tego godziny: średnio 10,8 dodatkowej godziny tygodniowo ponad umowny wymiar, przy czym blisko połowa notuje 11 lub więcej. Prawie połowa mówi, że praca częściej wyczerpuje emocjonalnie, niż daje satysfakcję, i najmocniej dotyczy to szczebla dyrektorskiego. A mimo to 94% wybrałoby cyberbezpieczeństwo ponownie.

Te wyniki rozróżniają zadowolenie z zawodu i warunki u konkretnego pracodawcy. Chęć pozostania w cyberbezpieczeństwie nie oznacza chęci pozostania w tej samej firmie.

Najczytelniejsze studium przypadku: siedem osób i skrzynka bug bounty

Ankiety mówią, jak ludzie się czują. O tym, jak obciążenie realnie narasta, najlepiej mówią dane z pierwszej ręki, w dodatku publiczne. Wpis Daniela Stenberga z lipca 2025 roku, „Death by a thousand slops”, opisuje przyjmowanie zgłoszeń bezpieczeństwa w curl z operacyjną dokładnością. Liczby za 2025 rok:

  • około dwóch zgłoszeń bezpieczeństwa tygodniowo
  • tylko jakieś 5% okazywało się prawdziwymi podatnościami, wobec historycznych ponad 15%
  • z grubsza 20% wszystkich zgłoszeń pochodziło z AI
  • nad jednym zgłoszeniem pracują trzy do czterech osób
  • każde zgłoszenie kosztuje „30 minut, czasem godzinę albo trzy. Każde.”
  • zespół bezpieczeństwa liczy siedem osób, a kilka z nich ma na curl tylko trzy godziny tygodniowo

Można oszacować łączny czas na podstawie tych danych. Dwa zgłoszenia tygodniowo razy około 3,5 osoby zaangażowanej razy mniej więcej 1,5 godziny daje około 10 osobogodzin tygodniowo pochłanianych przez samo przyjmowanie zgłoszeń. Członkowie zespołu mają na to zarezerwowane po trzy godziny. Wynik to około jedna prawdziwa podatność na dziesięć tygodni.

Zwiększenie zespołu nie zmieni samo w sobie odsetka prawdziwych podatności. Do planowania potrzebne są także dane o liczbie zgłoszeń i czasie ich obsługi. Stronę wolumenową opisaliśmy w tekście śmieci AI zalewają triaż bug bounty, a rachunek ekonomiczny w błąd za 25 dolarów wart pół miliona. To jest strona kosztu pracy tej samej zmiany.

W firmie na 200 osób można sprawdzić te same wielkości: liczbę zgłoszeń, czas obsługi i liczbę dostępnych osób.

Gdy zespół ogranicza przyjmowanie zgłoszeń

W ciągu pół roku kilka programów bezpieczeństwa open source ograniczyło przyjmowanie zgłoszeń lub wypłacanie nagród.

Styczeń 2026: curl zamknął swój program bug bounty. Zgłoszenia przez HackerOne przyjmował do 31 stycznia, a od 1 lutego przeniósł je bezpośrednio na GitHuba. Uzasadnienie Stenberga, cytowane przez The Register, mówiło wprost o obciążeniu: „Obecny potok zgłoszeń mocno obciąża zespół bezpieczeństwa curl i to jest próba ograniczenia szumu”.

Marzec 2026: Internet Bug Bounty wstrzymał przyjmowanie nowych zgłoszeń z dniem 27 marca, wypłaciwszy od 2012 roku ponad 1,5 miliona dolarów. Wyjaśnienie HackerOne to najważniejsze zdanie w całej tej historii: „Badania wspierane przez AI poszerzają wykrywanie podatności w całym ekosystemie, zwiększając zarówno pokrycie, jak i tempo. Równowaga między liczbą znalezisk a zdolnością do ich naprawy w open source istotnie się przesunęła”. W tym samym okresie Node.js przeszedł na przyjmowanie zgłoszeń bez wypłacania nagród, a Google w swoim OSS VRP wstrzymał przyjmowanie zgłoszeń generowanych przez AI.

Lipiec 2026: curl ogłosił „summer of bliss”, czyli lato spokoju. Kanał zgłoszeń na HackerOne i skrzynka bezpieczeństwa zamilkły od 1 lipca do 3 sierpnia. Projekt był „pod ogromną presją przez ostatnie jakieś cztery miesiące. Teraz potrzebujemy odpoczynku”, napisał Stenberg, dodając znacząco: „Nie spodziewamy się, że ten zalew się skończy”.

Przy zlecaniu triażu na zewnątrz warto sprawdzić, jak dostawca radzi sobie ze wzrostem liczby zgłoszeń i gdzie kończy się jego odpowiedzialność za naprawę.

W przytoczonych przypadkach organizacje zmieniły zasady programów zamiast tylko zwiększać obsadę. Ograniczenie przyjmowania zgłoszeń wpływa również na badaczy i dostępność kanału kontaktu.

Dlaczego 11 września „po prostu to wyłączmy” przestaje być opcją

Komercyjne zespoły bezpieczeństwa nie mają wyjścia, które miał curl, a termin liczy się już w tygodniach.

Od 11 września 2026 roku unijne rozporządzenie Cyber Resilience Act wymaga od producentów wprowadzających produkty na rynek UE wczesnego ostrzeżenia do ENISA w ciągu 24 godzin od momentu powzięcia wiedzy o aktywnie wykorzystywanej podatności, pełnego zgłoszenia w ciągu 72 godzin oraz raportu końcowego w ciągu 14 dni. Obowiązuje niezależnie od tego, gdzie firma ma siedzibę. Kary sięgają 15 milionów euro albo alternatywnej stawki powiązanej z przychodem. Cały zestaw obowiązków rozpisaliśmy w tekście co Cyber Resilience Act oznacza dla ujawniania podatności.

W tym samym czasie nakłada się kilka obciążeń. Liczba zgłoszeń rośnie. Odsetek trafnych spada. Wzrost budżetu na pięcioletnim minimum. Etaty w miejscu. A za sześć tygodni wchodzi ustawowy zegar 24-godzinny.

Na regulacyjny zegar nie odpowiesz skrzynką mailową i dobrymi chęciami. „Powzięcie wiedzy” to konkretny znacznik czasu i regulator poprosi cię o jego przedstawienie. To wymaga SLA na potwierdzenie zgłoszenia, które biegnie automatycznie, ścieżki eskalacji wywołującej konkretną osobę oraz zapisu, który da się obronić: kiedy dowiedzieliście się czego. Przygotowanie tych zasad wymaga czasu zespołu i przypisania odpowiedzialności. Ten scenariusz opisaliśmy już w tekście co się dzieje, gdy zegar ujawnienia zostaje zignorowany.

Czy CISO naprawdę zmieniają pracę co 18 miesięcy?

Raczej nie. To fragment narracji najbardziej podatny na błąd, a przy tym powtarzany bezkrytycznie w niemal każdym tekście na ten temat.

Alarmistyczna liczba pochodzi z 2026 CISO Report firmy Cybersecurity Ventures, przygotowanego z Sophosem, który podaje staż CISO w dużych korporacjach na 18 do 26 miesięcy wobec blisko pięciu lat dla pozostałych ról w zarządzie. Dwa inne zbiory danych mówią co innego. 2026 State of the CISO Benchmark firm IANS i Artico, na próbie 662 CISO, raportuje średni staż na stanowisku wynoszący dziewięć lat. Analiza Rossa Haleliuka z Venture in Security, obejmująca 526 spółek z listy Fortune 500, wskazała u CISO średnio 4,5 roku na stanowisku przy medianie 3,6 roku, czyli na poziomie CMO (3,5) i CHRO (3,7) albo wyżej. Spośród 36 odchodzących CISO z Fortune 500, których śledził, 18 objęło inne stanowisko kierownicze w bezpieczeństwie, a tylko 2 przeszły do doradztwa. Szeroko cytowana prognoza Gartnera z lutego 2023 roku, że do 2025 roku połowa liderów cyberbezpieczeństwa zmieni pracę, dotyczy roku, który już minął, i nie doczekała się opublikowanej weryfikacji.

CISO nie uciekają z zawodu. Krążą między pracodawcami. Dokładnie to opisują „blisko siedmiu na dziesięciu otwartych na zmianę w ciągu roku” i „tylko 34% zamierza zostać”, i dokładnie to pasuje do 94%, które wybrałyby cyberbezpieczeństwo ponownie.

I dla ciebie to wiadomość gorsza, bo odchodzący nie odrzucają tej pracy. Odrzucają sposób, w jaki jest u nich prowadzona, i biorą tę samą rolę w firmie, która prowadzi ją lepiej. Nie licz też na to, że uratuje cię rynek: Cybersecurity Ventures szacuje liczbę zatrudnionych CISO na świecie w 2026 roku na 35 000 wobec 32 000 w 2023, przy około 359 milionach firm globalnie. Szacunek powstał we współpracy z dostawcą i bez ujawnionej metodologii, więc traktuj go kierunkowo. W tym szacunku przybyło 3000 liderów netto w trzy lata. Jedyna zmienna poruszająca się w tempie problemu to ilość obciążenia, którą pochłania każdy z już pracujących liderów.

Oprócz wynagrodzeń sprawdź obciążenie pracą

Przytoczone badania pokazują dwie różnice: 19 punktów różnicy w wypaleniu u Bitsighta w zależności od widoczności pracy i 54 punkty różnicy w satysfakcji u IANS w zależności od poczucia wsparcia organizacji. Żadne z tych badań nie dowodzi samodzielnie przyczyny wypalenia. Warto jednak sprawdzić pięć elementów organizacji pracy:

  1. Ogłoś SLA na potwierdzenie zgłoszenia i podepnij pod nie zegar. Jedna liczba, publiczna, egzekwowana automatycznie. Wartością nie jest obietnica dana badaczom. Wartością jest to, że „czy ktoś na to w ogóle odpowiedział?” przestaje być pytaniem, na które twój lider bezpieczeństwa odpowiada z pamięci o 23:00.
  2. Ustal cele naprawy dla każdego poziomu ważności i pokaż je publicznie. Znalezisko krytyczne i informacyjne nie mogą mieć wspólnego terminu. Opublikowanie tej macierzy zamienia zobowiązanie bez granic w zobowiązanie ograniczone i dające się obronić, a dokładnie o to poprosi unijny regulator.
  3. Eskaluj według harmonogramu do konkretnej osoby na dyżurze, z okresami wyciszenia. Eskalacja bez rotacji budzi wciąż tę samą wyczerpaną osobę. Eskalacja bez wyciszeń nasila zmęczenie alertami, na które skarży się już 98% CISO w badaniu Splunka. Potrzebne są obie połowy.
  4. Zapisuj w księdze finansowej każdą decyzję o nagrodzie i każdą wypłatę. Stan wypłat powinno dać się sprawdzić w rejestrze. „Czy my w ogóle zapłaciliśmy temu badaczowi?” to powracające źródło i lęku lidera, i furii badacza. Zasady sprawiedliwego rozliczania opisujemy w tekście spory o wypłaty w bug bounty.
  5. Raportuj zarządowi MTTA, MTTR i zgodność z SLA co miesiąc. Wykorzystaj te dane do rozmowy o obciążeniu, zaległościach i potrzebnym wsparciu. Sam raport nie dowodzi, że zespół otrzymał wystarczające zasoby.

Nic z tego nie wymaga konkretnego dostawcy. Zasady i terminy trzeba zapisać, żeby nie zależały wyłącznie od pamięci jednej osoby. Jeśli zaczynasz od zera, jak uruchomić program ujawniania podatności opisuje podstawową konfigurację.

Jak realizuje to moduł CSIRT w Kit

Moduł CSIRT w Kit służy do prowadzenia procesu ujawniania podatności. Pokazuje obciążenie, terminy i osoby odpowiedzialne. Nie ma tu badania, które pozwalałoby przypisać jego wdrożeniu różnicę między 44% a 63% wypalenia.

Terminy i statusy SLA. Ustalasz jeden termin na potwierdzenie zgłoszenia dla całego programu, domyślnie 72 godziny, oraz cel naprawy dla każdego poziomu ważności: Superkrytyczny 24 h, Krytyczny 72 h, Wysoki 7 dni, Średni 14 dni, Niski i Informacyjny 30 dni. Każde zgłoszenie ma potem własny status na bieżąco: „na czas”, „zagrożone” albo „przekroczone”, a na „zagrożone” przechodzi po zużyciu trzech czwartych swojego czasu. Kolejka układa się według tego, co najbliżej granicy.

Eskalacja, która budzi konkretną osobę, zaprojektowana przeciw zmęczeniu alertami. Kiedy zgłoszeniu kończy się czas, Kit powiadamia osobę na dyżurze, wrzuca kartę naruszenia na Slacka i otwiera incydent w PagerDuty. Sześciogodzinne wyciszenie na zgłoszenie sprawia, że jedna zablokowana sprawa nie budzi ludzi przez cały wieczór, a znaleziska ocenione przez zespół jako informacyjne są śledzone jako naruszenia, ale nikogo nie wybudzają.

Rotacja dyżurów i wskazanie osoby odpowiedzialnej. Możesz przypisywać ręcznie, włączyć automatyczną rotację dzienną albo tygodniową z wybranym dniem i godziną przekazania, albo zsynchronizować się z grafikiem, który już prowadzisz w PagerDuty. Nowe zgłoszenia trafiają do osoby na zmianie, a przekazania i zmiany dyżuru są ogłaszane. Kit informuje także o lukach w grafiku.

Księga finansowa zamiast arkusza kalkulacyjnego. Każda decyzja o nagrodzie i każda wypłata trafiają do księgi, do której da się tylko dopisywać: zatwierdzenia, korekty, wypłaty zainicjowane, zakończone i nieudane, dokumenty podatkowe złożone, zweryfikowane i odrzucone, cofnięcia nagród. Wpisu nie da się później zmienić, wrażliwe dane są szyfrowane, a Kit cyklicznie sprawdza spójność ksiąg. „Czy my w ogóle zapłaciliśmy temu badaczowi?” sprawdzasz w księdze, zamiast odtwarzać z pamięci.

Wskaźniki do raportowania. MTTA, MTTR, procent zgodności z SLA, suma wypłaconych nagród, liczba zgłoszeń w czasie i podział zgłoszeń według poziomu ważności, przy czym każdy widzi tylko te zgłoszenia, na które pozwalają mu uprawnienia. A ponieważ cele naprawy konfiguruje się raz i publikuje na twojej publicznej stronie polityki, zaczynając od najwyższego poziomu ważności, obietnica, którą czyta badacz, jest tym samym zobowiązaniem, na którym pracuje eskalacja.

Kit pokazuje terminy, przypisania i stan pracy. Zespół nadal musi ocenić zgłoszenia, zaplanować naprawy i ustalić potrzebną obsadę.

Co uwzględnić w planie zatrzymania pracowników

Płać stawkę rynkową i daj tę skromną podwyżkę. Niedopłacanie kosztuje cię ludzi z powodu, który w pełni kontrolujesz, a podwyżka działa jako sygnał, że ktoś patrzy.

Osobno przeznacz czas i środki na pomiar oraz ograniczanie obciążenia pracą.

Odchodzący nie odrzucają tej pracy. Dziewięćdziesiąt cztery procent z nich wybrałoby ten zawód ponownie. Odrzucają etat, w którym kolejka nie ma dna, żadna sprawa nie ma widocznego zegara i nie ma jak nikomu pokazać, że praca ma granice. Zacznij od ustalenia terminów, odpowiedzialności i sposobu mierzenia obciążenia. Jeśli równolegle odbudowujesz zespół, co wyniki w CTF naprawdę mówią o inżynierach bezpieczeństwa opisuje rekrutacyjną stronę tego samego problemu.

Powiązane artykuły

Zacznij pierwszą rekrutację.

Zacznij za darmo na 30 dni. Zrezygnuj przed końcem, a nie zapłacisz ani grosza. Skonfiguruj swój pierwszy pipeline rekrutacyjny w kilka minut.

Zacznij za darmo