Konflikt kompetencyjny: kiedy CISO ma rację, a zarząd i tak podejmuje inną decyzję
Kontekst: wiedzieć więcej nie zawsze znaczy decydować
Znowelizowana ustawa o Krajowym Systemie Cyberbezpieczeństwa (KSC), wdrażająca dyrektywę NIS2, wymaga od podmiotów kluczowych i ważnych wyznaczenia osoby odpowiedzialnej za cyberbezpieczeństwo oraz zapewnienia jej odpowiednich zasobów i możliwości realnego wykonywania zadań. W praktyce oznacza to, że organizacja powinna mieć kogoś, kto rozumie ryzyko techniczne na tyle dobrze, by formułować rekomendacje – i strukturę decyzyjną, która pozwala te rekomendacje realnie uwzględnić w decyzjach biznesowych.
Przepis dobrze opisuje, kto ma dostarczać wiedzę. Znacznie słabiej reguluje to, co dzieje się w momencie, gdy wiedza techniczna zderza się z decyzją biznesową podjętą przez osoby, które formalnie mają prawo tę decyzję podjąć, nawet wbrew rekomendacji specjalisty. CISO czy kierownik działu bezpieczeństwa może mieć rację merytoryczną i nie mieć żadnego formalnego mandatu, by tę rację przełożyć na wstrzymanie projektu. Zarząd może mieć pełną świadomość ryzyka i mimo to zdecydować inaczej, bo waży je względem innych czynników – terminu, kosztu, presji konkurencyjnej.
To nie jest wyłącznie spór o to, kto ma słuszność. To konflikt o zupełnie innej naturze: spór o rodzaj władzy, jaką dysponuje każda ze stron, oraz o to, czy organizacja w ogóle przewidziała sytuację, w której te dwa rodzaje władzy się ze sobą zderzają. Ten artykuł pokazuje, skąd bierze się ten konflikt, dlaczego eskaluje się on częściej, niż mogłoby się wydawać, oraz jak budować mandat CISO tak, by rekomendacja techniczna miała realną szansę powstrzymać decyzję biznesową generującą nieakceptowalne ryzyko.
Mechanizm: dwa rodzaje władzy, które rzadko są sobie równe
Pięć źródeł władzy według Frencha i Ravena. Klasyczna koncepcja z psychologii organizacji, opracowana przez Johna Frencha i Bertrama Ravena, rozróżnia kilka niezależnych źródeł wpływu, jakim dysponują ludzie w organizacji. Władza legitymizowana wynika z formalnej pozycji w hierarchii – członek zarządu ma ją z definicji, niezależnie od poziomu wiedzy technicznej. Władza nagradzania i władza przymusu wiążą się z możliwością wpływania na wynagrodzenie, awans czy warunki pracy innej osoby. Władza ekspercka wynika z realnej wiedzy i umiejętności, których inni nie posiadają. Władza odniesienia opiera się na szacunku i chęci naśladowania. CISO w typowej organizacji dysponuje przede wszystkim władzą ekspercką – silną merytorycznie, ale słabą strukturalnie, jeśli nie jest wsparta formalnym umocowaniem. Zarząd dysponuje władzą legitymizowaną, nagradzania i przymusu niemal automatycznie, z racji samej pozycji. Konflikt kompetencyjny bardzo często jest w istocie starciem władzy eksperckiej z władzą legitymizowaną – i bez świadomej interwencji organizacyjnej to druga zwykle wygrywa, niezależnie od jakości argumentów merytorycznych.
Niezgodność statusu. Zjawisko opisywane w socjologii organizacji jako niezgodność statusu (ang. status incongruence) pojawia się wtedy, gdy osoba o wysokim statusie w jednym wymiarze – np. wiedzy eksperckiej – ma niski status w innym wymiarze, np. w hierarchii formalnej czy stażu w organizacji. CISO, często stosunkowo młody stażem lub zatrudniony z zewnątrz specjalnie pod kątem zgodności z NIS2, może mieć więcej wiedzy technicznej niż ktokolwiek inny w firmie, a jednocześnie najniższą pozycję w nieformalnej hierarchii wpływu. Ta niezgodność sama w sobie generuje napięcie, niezależnie od merytorycznej jakości rekomendacji – otoczenie organizacyjne intuicyjnie „waży" opinię również przez pryzmat pozycji osoby, która ją wygłasza.
Naiwny realizm. Koncepcja z psychologii społecznej opisuje skłonność każdej ze stron sporu do przekonania, że to właśnie jej ocena sytuacji jest obiektywna, neutralna i oczywista dla każdego racjonalnego obserwatora, podczas gdy odmienne stanowisko drugiej strony musi wynikać z niewiedzy, stronniczości albo ukrytego interesu. Specjalista ds. bezpieczeństwa patrzy na ryzyko przez pryzmat scenariuszy ataku i jest szczerze zdziwiony, że ktokolwiek może je zbagatelizować. Członek zarządu patrzy na to samo ryzyko przez pryzmat konsekwencji biznesowych opóźnienia i jest równie szczerze przekonany, że to on widzi pełny obraz, a specjalista przecenia zagrożenie, bo z natury swojej roli patrzy na świat przez pryzmat najgorszego scenariusza. Obie strony rzadko traktują to jako uzasadnioną różnicę perspektyw zawodowych – częściej jako dowód, że druga strona się myli.
Konflikt i niejednoznaczność roli. Teoria roli organizacyjnej, rozwijana między innymi przez Roberta Kahna, opisuje sytuację, w której od jednej osoby oczekuje się sprzecznych rzeczy jednocześnie – w tym przypadku od CISO oczekuje się zarówno ochrony organizacji przed ryzykiem, jak i niehamowania tempa biznesu. Kiedy te dwa oczekiwania się rozjeżdżają, a organizacja nie zdefiniowała jasno, które z nich ma pierwszeństwo w sytuacji konfliktu, CISO funkcjonuje w chronicznym napięciu roli – i to niezależnie od tego, jak dobrze wykonuje swoją pracę techniczną.
Bardzo często słyszę od osób odpowiedzialnych za bezpieczeństwo w mniejszych firmach, że czują się jak „ten, kto zawsze mówi nie". To sygnał, że organizacja nie zdefiniowała, w jakich sytuacjach rekomendacja bezpieczeństwa ma charakter wiążący, a w jakich jest tylko jedną z opinii branych pod uwagę. Bez tej granicy CISO codziennie musi na nowo negocjować swój autorytet, zamiast po prostu wykonywać swoją rolę.
Kamil Ciaś, współzałożyciel betternow.group | Chief Information Security Officer | Dyrektor ds. Bezpieczeństwa Informacji / Dyrektor ds. Cyberbezpieczeństwa
Jak konflikt kompetencyjny wygląda w praktyce organizacyjnej
Z naszego doświadczenia we współpracy z zarządami i działami bezpieczeństwa firm różnej wielkości konflikt kompetencyjny rzadko przybiera formę jawnej kłótni na spotkaniu. Znacznie częściej ujawnia się jako powtarzalny, cichy wzorzec relacji między CISO a zarządem.
Pierwszy wzorzec to rekomendacja przekształcona w sugestię do rozważenia. CISO formalnie zgłasza ryzyko, ale sposób, w jaki komunikat trafia do zarządu – zwykle jako punkt informacyjny w mailu lub krótka wzmianka na koniec spotkania – sprawia, że nie ma on statusu decyzji wymagającej rozstrzygnięcia, tylko informacji do wiadomości. Zarząd nie odrzuca rekomendacji świadomie; ona po prostu nigdy nie zostaje potraktowana jako coś, co wymaga formalnej odpowiedzi.
Drugi wzorzec to przewaga języka biznesowego nad językiem technicznym w procesie decyzyjnym. Rekomendacja CISO sformułowana w kategoriach technicznych – rodzaj podatności, wektor ataku, prawdopodobieństwo eksploatacji – przegrywa w starciu z argumentem sformułowanym w kategoriach, które zarząd rozumie natychmiast i intuicyjnie: utracony przychód, opóźniony termin, niezadowolony klient. Nie dlatego, że argument biznesowy jest silniejszy merytorycznie, lecz dlatego, że jest łatwiejszy do przetworzenia poznawczo przez osoby niebędące specjalistami technicznymi.
Trzeci wzorzec, szczególnie częsty w organizacjach, które niedawno zatrudniły CISO w odpowiedzi na wymogi NIS2/KSC, to testowanie nowego autorytetu przez pomijanie go w kluczowych decyzjach. Zarząd formalnie akceptuje istnienie roli CISO, ale w praktyce nadal podejmuje decyzje dotyczące ryzyka technicznego na poziomie operacyjnym, konsultując je z CISO post factum albo wcale – nie z premedytacją, lecz dlatego, że stare nawyki decyzyjne, ukształtowane przed wprowadzeniem tej roli, nie zmieniają się automatycznie wraz z nowym stanowiskiem w schemacie organizacyjnym.
Czwarty wzorzec to eskalacja przez wycofanie, czyli reakcja CISO na powtarzające się pomijanie jego rekomendacji. Zamiast konfrontować zarząd wprost, specjalista zaczyna zgłaszać ryzyko coraz rzadziej, coraz bardziej ogólnikowo albo wyłącznie w formie pisemnej „dla bezpieczeństwa własnego", bez realnej próby przekonania decydentów. To strategia chroniąca CISO przed powtarzającą się frustracją, ale kosztem realnego wpływu na bezpieczeństwo organizacji – i sygnał, że konflikt kompetencyjny nie został rozwiązany, tylko przestał być widoczny.
Jak budować realny mandat CISO w praktyce
Jasne, spisane z góry progi eskalacji i wstrzymania. Zamiast liczyć na to, że autorytet CISO wystarczy do przekonania zarządu w każdej pojedynczej sytuacji, warto z góry ustalić kategorie ryzyka, przy których rekomendacja CISO ma charakter wiążący, a nie doradczy – na przykład: żaden system z bezpośrednim dostępem do danych klientów nie trafia na produkcję bez formalnego zamknięcia krytycznych podatności, niezależnie od presji terminowej. Taki próg, ustalony w spokojnym momencie, zanim pojawi się konkretna presja biznesowa, jest znacznie trudniejszy do podważenia niż argument przedstawiany w środku kryzysu decyzyjnego.
Formalne prawo do zgłoszenia zastrzeżenia z określonymi konsekwencjami proceduralnymi. Nawet jeśli CISO nie ma pełnego prawa weta, warto wprowadzić mechanizm, w którym formalnie zgłoszone zastrzeżenie – z jasnym opisem ryzyka i rekomendowanym działaniem – wymaga udokumentowanej decyzji zarządu o akceptacji ryzyka, a nie tylko milczącego pominięcia. Sama konieczność podpisania się pod świadomym przyjęciem ryzyka zmienia dynamikę rozmowy: decyzja przestaje być domyślna, a staje się aktem wymagającym odpowiedzialności.
Tłumaczenie ryzyka technicznego na język konsekwencji biznesowych, nie odwrotnie. Zamiast oczekiwać, że zarząd nauczy się myśleć kategoriami technicznymi, skuteczniejsze jest przełożenie rekomendacji na te same kategorie, w których zarząd podejmuje inne decyzje: prawdopodobny koszt incydentu, czas przestoju, ryzyko utraty konkretnego kontraktu, konsekwencje regulacyjne. To nie jest spłaszczanie problemu – to komunikacja dostosowana do odbiorcy, bez której nawet trafna ocena ryzyka pozostaje niezrozumiała dla osób podejmujących ostateczną decyzję.
Regularna, zaplanowana obecność w procesie decyzyjnym, nie tylko doraźne konsultacje. CISO włączony do wczesnego etapu planowania projektów biznesowych – a nie proszony o opinię tuż przed wdrożeniem, gdy większość decyzji jest już faktycznie podjęta – ma znacznie większy realny wpływ niż osoba formalnie uprawniona do zgłaszania uwag, ale konsultowana zbyt późno, by cokolwiek zmienić bez kosztownego cofania się.
Świadome zarządzanie różnicą perspektyw, a nie udawanie, że jej nie ma. Zarówno CISO, jak i zarząd korzystają na tym, gdy różnica w sposobie oceny ryzyka zostaje nazwana wprost jako naturalna konsekwencja różnych ról, a nie jako spór o to, kto ma rację. Pytanie „jak inaczej widzimy tę sytuację i dlaczego" prowadzi do bardziej produktywnej rozmowy niż założenie, że jedna ze stron musi ustąpić, bo się myli.
Zarządy, które dobrze radzą sobie z tym konfliktem, nie traktują CISO jako osoby, która ma ich przekonać za każdym razem od nowa. Traktują wcześniej ustalone progi ryzyka jako część własnych zasad gry, tak samo jak limity budżetowe czy zasady akceptacji dużych kontraktów. Wtedy spór przestaje być testem siły przekonywania, a staje się zwykłym stosowaniem reguły, którą sami wcześniej przyjęli.
Edyta Müller-Ciaś, współzałożycielka betternow.group | Chief Change & Culture Officer | dyrektorka ds. rozwoju organizacji | ekspertka ds. zarządzania zmianą i psychologii biznesu
Studium przypadku
Regionalny operator internetowy, świadczący usługi dostępu do sieci dla klientów indywidualnych i biznesowych w kilku powiatach, zatrudniający 68 osób, został zakwalifikowany jako podmiot kluczowy w sektorze infrastruktury cyfrowej w rozumieniu znowelizowanej ustawy o KSC. Firma zatrudniła sześć miesięcy wcześniej specjalistę ds. bezpieczeństwa informacji, który formalnie objął funkcję odpowiadającą wymogom nowych przepisów, dołączając do dziewięcioosobowego działu technicznego kierowanego przez dyrektora operacyjnego wchodzącego jednocześnie w skład dwuosobowego zarządu.
Firma przygotowywała się do uruchomienia nowego portalu samoobsługowego, który miał pozwolić klientom na samodzielną zmianę parametrów usługi, przeglądanie faktur i zgłaszanie awarii bez kontaktu z infolinią – projekt istotny wizerunkowo i konkurencyjnie, zapowiedziany klientom biznesowym na konkretny termin w komunikacji marketingowej. Podczas przeglądu bezpieczeństwa przed planowanym uruchomieniem specjalista ds. bezpieczeństwa zidentyfikował lukę w mechanizmie autoryzacji interfejsu API portalu, pozwalającą – przy odpowiednio skonstruowanym zapytaniu – na dostęp do danych innego klienta niż zalogowany użytkownik. Zgłosił to jako krytyczne ryzyko wymagające wstrzymania uruchomienia do czasu poprawki.
Dyrektor operacyjny, odpowiedzialny jednocześnie za relacje z kluczowymi klientami biznesowymi, ocenił ryzyko inaczej. Uznał, że prawdopodobieństwo wykorzystania luki przez kogokolwiek w krótkim okresie jest niskie, że termin uruchomienia był już wielokrotnie komunikowany klientom i przesuwanie go po raz kolejny zaszkodzi wiarygodności firmy bardziej niż teoretyczne ryzyko techniczne. Rekomendacja specjalisty została formalnie odnotowana w dokumentacji projektu, ale portal uruchomiono zgodnie z pierwotnym harmonogramem, z zastrzeżeniem, że poprawka zostanie wdrożona „w najbliższej możliwej aktualizacji".
Dwa tygodnie po uruchomieniu jeden z klientów biznesowych zgłosił, że w panelu widzi dane rozliczeniowe innej firmy. Analiza potwierdziła, że luka opisana wcześniej przez specjalistę ds. bezpieczeństwa została wykorzystana – prawdopodobnie nie w wyniku celowego ataku, lecz przypadkowego odkrycia podczas zwykłego korzystania z portalu przez ciekawskiego użytkownika, który zaczął modyfikować parametry zapytań w przeglądarce. Skala ujawnienia danych była ograniczona do kilkunastu kont, ale zdarzenie podlegało obowiązkowi zgłoszenia jako incydent bezpieczeństwa i wymagało poinformowania osób, których dane zostały ujawnione.
Analiza po incydencie nie wykazała, że dyrektor operacyjny zignorował rekomendację ze złej woli ani że specjalista ds. bezpieczeństwa źle wykonał swoją pracę – ocena ryzyka i rekomendacja były trafne i poprawnie udokumentowane. Ujawniła natomiast, że firma nie miała żadnego ustalonego wcześniej progu, przy którym rekomendacja bezpieczeństwa automatycznie wstrzymuje uruchomienie produktu, ani mechanizmu wymagającego, by decyzja o świadomym przyjęciu ryzyka technicznego była podejmowana kolegialnie przez cały zarząd, a nie jednoosobowo przez członka odpowiedzialnego za relacje biznesowe.
W efekcie firma wprowadziła zasadę, zgodnie z którą każde ryzyko sklasyfikowane przez dział bezpieczeństwa jako krytyczne w kategorii ochrony danych klientów automatycznie wstrzymuje wdrożenie do czasu decyzji podjętej przez cały zarząd, a nie pojedynczego jego członka, z obowiązkowym, pisemnym uzasadnieniem, jeśli decyzja miałaby być inna niż rekomendowana. Specjalistę ds. bezpieczeństwa włączono też formalnie do wcześniejszego etapu planowania nowych projektów, zamiast konsultować go dopiero na etapie przeglądu przedwdrożeniowego.
To nie był konflikt dwóch ludzi, którzy się nie lubili albo nie szanowali swojej wiedzy. To był konflikt dwóch rodzajów odpowiedzialności, które nigdy nie zostały ze sobą formalnie uzgodnione. Dyrektor operacyjny miał realną presję biznesową i realne prawo do podejmowania decyzji. Specjalista miał realną wiedzę techniczną i żadnego formalnego narzędzia, by tę wiedzę przełożyć na coś więcej niż rekomendację do rozważenia. Rozwiązaniem nie było danie CISO władzy weta nad każdą decyzją biznesową, tylko precyzyjne wskazanie, w których obszarach ryzyka głos techniczny musi mieć pierwszeństwo.
Kamil Ciaś, współzałożyciel betternow.group | Chief Information Security Officer | Dyrektor ds. Bezpieczeństwa Informacji / Dyrektor ds. Cyberbezpieczeństwa
Wnioski praktyczne
- Konflikt kompetencyjny między działem bezpieczeństwa a zarządem rzadko wynika z braku szacunku dla wiedzy technicznej – częściej z tego, że władza ekspercka i władza formalna w organizacji nie są sobie równe, a nikt wcześniej nie zdefiniował, która z nich rozstrzyga w sytuacji sporu.
- Rekomendacja bezpieczeństwa bez jasno określonego statusu decyzyjnego – wiążącego lub doradczego – w praktyce zbyt łatwo staje się informacją do wiadomości, a nie decyzją wymagającą formalnego rozstrzygnięcia.
- Obie strony konfliktu zwykle działają w dobrej wierze i patrzą na tę samą sytuację przez pryzmat odmiennych, uzasadnionych zawodowo priorytetów – warto nazwać tę różnicę wprost, zamiast traktować ją jako spór o to, kto ma rację.
- Z góry ustalone progi ryzyka, przy których rekomendacja techniczna automatycznie wstrzymuje decyzję biznesową, są skuteczniejsze niż poleganie na sile przekonywania CISO w każdej pojedynczej sytuacji.
- Włączenie specjalisty ds. bezpieczeństwa do wczesnego etapu planowania projektów, zamiast konsultowania go tuż przed wdrożeniem, realnie zwiększa jego wpływ na decyzje, które i tak później będzie musiał oceniać.
- Formalny obowiązek udokumentowanej, kolegialnej decyzji o świadomym przyjęciu ryzyka – zamiast milczącego pominięcia rekomendacji – zmienia dynamikę odpowiedzialności i skłania do poważniejszego potraktowania głosu eksperckiego.
Czy w Twojej organizacji rekomendacja działu bezpieczeństwa ma realną moc wstrzymania ryzykownej decyzji biznesowej, czy tylko trafia do dokumentacji projektu? BetterNow.Group łączy wiedzę techniczną z zakresu cyberbezpieczeństwa z doświadczeniem w projektowaniu struktur decyzyjnych, które nadają realny mandat osobom odpowiedzialnym za bezpieczeństwo informacji. Skontaktuj się z nami.