Komunikacja kryzysowa po incydencie: dlaczego 24 godziny to za mało czasu, żeby przestać się bać

Kontekst: zegar zaczyna tykać, zanim ktokolwiek zdąży zrozumieć, co się stało

Znowelizowana ustawa o Krajowym Systemie Cyberbezpieczeństwa (KSC), wdrażająca dyrektywę NIS2, wprowadza rygorystyczny reżim czasowy zgłaszania poważnych incydentów: wczesne ostrzeżenie do właściwego CSIRT w ciągu 24 godzin od wykrycia zdarzenia, pełniejsze zgłoszenie incydentu w ciągu 72 godzin, a następnie raport końcowy po zakończeniu obsługi zdarzenia. Na poziomie przepisu brzmi to jak zestaw terminów administracyjnych – trzy daty w kalendarzu, trzy dokumenty do wypełnienia. W praktyce oznacza jednak coś znacznie trudniejszego: organizacja musi w ciągu pierwszej doby podjąć decyzję o ujawnieniu zdarzenia, którego zakresu, przyczyny i konsekwencji jeszcze dobrze nie rozumie.

To zderzenie dwóch rzeczywistości. Prawo wymaga szybkiego, formalnego komunikatu. Ludzie, którzy mają go przygotować, znajdują się w tym momencie w stanie ostrego stresu, niepełnej wiedzy i – bardzo często – obawy przed konsekwencjami tego, co ujawnienie może za sobą pociągnąć. Wiele organizacji ma gotową procedurę zgłaszania incydentów na papierze, przetestowaną podczas audytu. Znacznie mniej ma przetestowaną zdolność zespołu do podjęcia decyzji o zgłoszeniu w warunkach realnego chaosu informacyjnego, presji czasu i strachu przed oceną.

Ten artykuł pokazuje, jakie mechanizmy psychologiczne utrudniają sprawną komunikację kryzysową w pierwszych godzinach po wykryciu incydentu oraz jak budować w organizacji zdolność do zgłaszania w terminie – nie tylko formalnie, ale i rzeczowo.

Mechanizm: dlaczego pod presją czasu myślimy gorzej, nie lepiej

Popularne przekonanie głosi, że w sytuacji kryzysowej człowiek mobilizuje się i działa skuteczniej. Badania nad funkcjonowaniem poznawczym pod ostrym stresem pokazują obraz bardziej złożony – i w kontekście zgłaszania incydentów, mniej optymistyczny.

Zawężenie poznawcze pod wpływem stresu. Ostry stres aktywuje reakcję „walcz, uciekaj albo zastygnij w bezruchu”, która ewolucyjnie służyła szybkiej reakcji na fizyczne zagrożenie, a nie analizie złożonego, wieloetapowego zdarzenia w środowisku IT. Jednym z udokumentowanych efektów tej reakcji jest zawężenie pola uwagi – umysł koncentruje się na jednym, pozornie najpilniejszym wątku, tracąc zdolność do jednoczesnego ogarnięcia szerszego obrazu sytuacji. W praktyce oznacza to, że osoba obsługująca pierwsze zgłoszenie incydentu może całą energię poświęcić na powstrzymanie ataku technicznie, tracąc z pola widzenia to, że równolegle biegnie termin ustawowy, o którym nikt jeszcze nie pomyślał.

Błąd normalności. Skłonność do niedoszacowania prawdopodobieństwa i skali zdarzenia, które nie mieści się w dotychczasowym doświadczeniu, jest dobrze opisanym zjawiskiem w psychologii reagowania na katastrofy i sytuacje wyjątkowe. W kontekście incydentu bezpieczeństwa przejawia się jako przekonanie „to na pewno nic poważnego, pewnie usterka albo błąd użytkownika” – utrzymywane nawet wtedy, gdy pojawiają się sygnały wskazujące na coś więcej. Błąd normalności działa najsilniej właśnie w pierwszych godzinach, kiedy dane są niepełne, a każda alternatywna, mniej groźna interpretacja wydaje się psychologicznie wygodniejsza niż uznanie, że doszło do poważnego naruszenia.

Sensemaking, czyli nadawanie sensu chaosowi. Koncepcja opisana przez badacza organizacji Karla Weicka pokazuje, że w sytuacji niepewności ludzie nie czekają biernie na pełne dane, zanim zaczną działać – aktywnie konstruują interpretację tego, co się dzieje, często na podstawie fragmentarycznych informacji, a następnie bronią tej interpretacji, nawet gdy napływają fakty jej przeczące. W zespole reagującym na incydent oznacza to ryzyko, że pierwsza robocza hipoteza – „to izolowany przypadek na jednej stacji roboczej” – zostanie przyjęta jako obowiązująca narracja, a kolejne sygnały wskazujące na szerszy zasięg ataku będą nieświadomie dopasowywane do tej narracji zamiast ją weryfikować.

Strach przed komunikatem, który okaże się przedwczesny lub przesadzony. Osoba odpowiedzialna za eskalację informacji w górę struktury organizacyjnej staje przed asymetrycznym ryzykiem: zgłoszenie zbyt wcześnie, na podstawie niepełnych danych, grozi wizerunkową kompromitacją, jeśli okaże się, że incydent był mniej poważny niż sądzono. Zgłoszenie zbyt późno grozi naruszeniem terminu ustawowego, ale – z perspektywy jednostki podejmującej decyzję w danym momencie – ta konsekwencja wydaje się bardziej odległa i mniej personalnie dotkliwa niż natychmiastowe ryzyko „zrobienia z siebie panikarza”. Ta asymetria w praktyce sprzyja zwlekaniu, nawet gdy formalnie wszyscy wiedzą, że przepisy wymagają szybkiego działania.

W pierwszych godzinach po wykryciu poważnego zdarzenia najczęstszym pytaniem, jakie słyszę od zespołów, nie jest „jak to zgłosić", tylko „czy na pewno musimy to już zgłaszać". To pytanie rzadko wynika z nieznajomości przepisów. Wynika z tego, że nikt nie chce być osobą, która uruchomiła formalną procedurę na podstawie informacji, które później okazały się niepełne. Problem w tym, że licznik 24 godzin biegnie niezależnie od tego, czy zespół czuje się gotowy podjąć tę decyzję.

Kamil Ciaś, współzałożyciel betternow.group | Chief Information Security Officer | Dyrektor ds. Bezpieczeństwa Informacji / Dyrektor ds. Cyberbezpieczeństwa

Jak wygląda to w praktyce wdrożeniowej

Z naszego doświadczenia we wspieraniu organizacji w obsłudze incydentów najczęstszym problemem nie jest brak wiedzy o obowiązku zgłoszenia w 24 i 72 godziny – ten fakt zna praktycznie każda osoba odpowiedzialna za bezpieczeństwo informacji. Problemem jest brak jasnej, przetestowanej ścieżki decyzyjnej, która pozwala tę wiedzę zastosować pod presją.

Pierwszy powtarzalny wzorzec to brak jednoznacznie wskazanej osoby uprawnionej do podjęcia decyzji o zgłoszeniu. W wielu organizacjach procedura opisuje, do kogo należy przekazać informację o incydencie, ale nie precyzuje, kto ostatecznie decyduje, że próg „poważnego incydentu” został przekroczony i termin zaczął biec. W efekcie informacja krąży między działem IT, bezpieczeństwem a zarządem, a każda z tych stron zakłada, że decyzję podejmie ktoś inny – co samo w sobie wydłuża czas reakcji, zanim jeszcze ktokolwiek zacznie pisać treść zgłoszenia.

Drugi wzorzec to mylenie zgłoszenia wstępnego z pełną diagnozą. Zespoły techniczne, przyzwyczajone do rzetelności i precyzji, odczuwają silny opór przed przekazaniem do CSIRT informacji, które nie są jeszcze w pełni zweryfikowane. Tymczasem zgłoszenie w ciągu 24 godzin z założenia ma charakter wczesnego ostrzeżenia, a nie kompletnej analizy przyczyn – jego celem jest uruchomienie mechanizmu wsparcia i wymiany informacji na poziomie systemowym, nie przedstawienie ostatecznych wniosków. Próba dopracowania zgłoszenia do stanu „w pełni pewnego” regularnie prowadzi do przekroczenia terminu.

Trzeci wzorzec to komunikacja wewnętrzna zaprojektowana pod uspokojenie, nie pod działanie. W chwili kryzysu naturalną reakcją menedżerów bywa ograniczanie krążącej informacji, by „nie siać paniki” – komunikaty do zarządu czy pracowników zostają złagodzone, uogólnione, pozbawione niewygodnych szczegółów. Skutkiem ubocznym takiego podejścia jest jednak to, że osoby decyzyjne otrzymują obraz sytuacji łagodniejszy niż rzeczywisty, co bezpośrednio utrudnia trafną ocenę, czy próg zgłoszenia ustawowego został przekroczony.

Czwarty wzorzec, widoczny zwłaszcza w organizacjach, w których wcześniej dominowała kultura unikania błędów, to milczenie osoby, która jako pierwsza zauważyła nieprawidłowość, z obawy przed przypisaniem jej odpowiedzialności za samo wystąpienie problemu, a nie tylko za jego zgłoszenie. Im silniejsze w organizacji przekonanie, że zgłaszający problem bywa utożsamiany z jego sprawcą, tym dłużej informacja o pierwszych sygnałach ataku pozostaje na najniższym szczeblu struktury, zanim dotrze do osób uprawnionych do podjęcia decyzji o zgłoszeniu.

Jak budować zdolność do zgłaszania w terminie

Jawne oddzielenie komunikatu wstępnego od ostatecznej oceny przyczyn i skali. Zespół powinien mieć jasność, że zgłoszenie wczesne z zastrzeżeniem „ocena wstępna, podlega weryfikacji” jest w pełni zgodne z duchem przepisów i nie naraża organizacji na zarzut nierzetelności, jeśli kolejne ustalenia zmienią obraz sytuacji. Ta jasność zmniejsza opór psychologiczny przed wysłaniem zgłoszenia, dopóki wiedza nie jest kompletna.

Regularne ćwiczenia symulacyjne obejmujące właśnie moment decyzji o zgłoszeniu, nie tylko obsługę techniczną. Symulacje incydentów prowadzone w organizacjach często kończą się w momencie opanowania zagrożenia technicznego. Warto świadomie włączyć do scenariusza etap podjęcia decyzji o zgłoszeniu do CSIRT i przygotowania treści komunikatu pod presją czasu, ponieważ to właśnie ten etap w realnych zdarzeniach bywa najsłabszym ogniwem, mimo że rzadko jest testowany.

Jasna, wcześniej ustalona hierarchia komunikacji wewnętrznej, obejmująca zarówno kanał techniczny (kto informuje kogo o postępie diagnozy), jak i kanał decyzyjny (kto ma prawo i obowiązek podjąć decyzję o eskalacji formalnej), pozwala uniknąć sytuacji, w której informacja krąży poziomo między działami, zamiast trafić pionowo do osoby uprawnionej do działania.

Kultura, w której zgłoszenie wątpliwości nie jest traktowane jako oskarżenie. Osoba, która pierwsza zauważa nieprawidłowość, powinna mieć pewność, że zgłoszenie tego faktu zostanie potraktowane jako wartościowy wkład w bezpieczeństwo organizacji, a nie jako przyznanie się do winy za samo wystąpienie problemu. Bez tego przekonania pierwsze, najcenniejsze minuty po wykryciu incydentu regularnie są tracone na wewnętrzne wahanie, zanim ktokolwiek zdecyduje się przekazać informację dalej.

Studium przypadku

Spółka wodociągowo-kanalizacyjna, zatrudniająca 41 osób i odpowiedzialna za zaopatrzenie w wodę pitną dla niewielkiej miejscowości oraz kilku okolicznych sołectw, została zakwalifikowana jako podmiot kluczowy w rozumieniu znowelizowanej ustawy o KSC – fakt, który zarząd spółki odkrył dopiero podczas konsultacji z urzędem gminy, będącym jej jedynym udziałowcem, mimo że spółka funkcjonowała w tym sektorze od dekad.

Systemy administracyjne spółki – poczta, dokumentacja finansowa, ewidencja odczytów liczników – działały odrębnie od systemu sterowania i monitoringu sieci wodociągowej (SCADA), fizycznie odseparowanego i uznawanego wewnętrznie za „bezpieczny, bo niepodłączony do internetu”. W praktyce jeden z serwerów administracyjnych miał jednak skonfigurowane, rzadko używane połączenie serwisowe do sieci przemysłowej, o którym pamiętał tylko jeden, od dawna niezatrudniony już zewnętrzny integrator.

W piątkowe popołudnie pracownica działu obsługi klienta zauważyła, że nie może zalogować się do systemu ewidencji odczytów, a program działa wyraźnie wolniej niż zwykle. Zgłosiła to jedynemu informatykowi zatrudnionemu w spółce na część etatu, który akurat kończył pracę i założył, że to typowa usterka po piątkowej aktualizacji – zjawisko, które zdarzało się już wcześniej i zwykle ustępowało samo. Informatyk odłożył sprawdzenie problemu do poniedziałku, nie informując nikogo w zarządzie.

W sobotę rano ten sam pracownik zauważył zdalnie, sprawdzając pocztę, że część plików na serwerze administracyjnym nosi nietypowe rozszerzenia, charakterystyczne dla ataku szyfrującego. Zamiast od razu poinformować prezesa spółki, spędził kilka godzin, próbując samodzielnie zdiagnozować zakres problemu – z obawy, że przedwczesny alarm o „poważnym incydencie cybernetycznym” w spółce komunalnej, która nigdy wcześniej nie miała podobnej sytuacji, zostanie odebrany jako przesada lub jako dowód jego niekompetencji. Dopiero w niedzielę, gdy odkrył ślady prób połączenia z segmentem sieci SCADA, przekazał informację prezesowi spółki – łącznie ponad 40 godzin od pierwszego zgłoszenia problemu przez pracownicę obsługi klienta.

Zarząd, dowiedziawszy się o zdarzeniu, spędził kolejnych kilka godzin na wewnętrznych ustaleniach, kto formalnie powinien podpisać zgłoszenie do CSIRT, ponieważ w spółce nigdy wcześniej nie doszło do sytuacji wymagającej takiego kroku, a nikt nie miał pewności, czy decyzję może podjąć prezes samodzielnie, czy wymaga to konsultacji z radą nadzorczą reprezentującą gminę. Zgłoszenie wstępne zostało ostatecznie wysłane po przekroczeniu terminu 24 godzin od momentu, w którym – zgodnie z późniejszą analizą – incydent powinien zostać uznany za wykryty.

Analiza zdarzenia po fakcie nie wykazała złej woli żadnej z zaangażowanych osób. Wykazała za to kumulację przewidywalnych mechanizmów: błąd normalności na najniższym szczeblu, obawę przed przedwczesnym alarmem na poziomie technicznym oraz brak jasno ustalonej ścieżki decyzyjnej na poziomie zarządczym w organizacji, która nigdy wcześniej nie musiała jej używać. Spółka wprowadziła od tego momentu jednoznaczną instrukcję: każde podejrzenie zdarzenia bezpieczeństwa, niezależnie od poziomu pewności, jest zgłaszane bezpośrednio do prezesa w ciągu dwóch godzin od zauważenia, z gotowym szablonem zgłoszenia wstępnego do CSIRT oraz jednoznacznym umocowaniem prezesa do samodzielnego podjęcia decyzji o wysłaniu zgłoszenia bez uprzedniej konsultacji z radą nadzorczą.

W małych spółkach komunalnych bardzo często pokutuje przekonanie, że poważne incydenty zdarzają się gdzie indziej – w bankach, w dużych korporacjach, nie w lokalnym wodociągu. To przekonanie samo w sobie wydłuża czas reakcji, bo pierwszy odruch brzmi „to na pewno nic takiego", zanim ktokolwiek w ogóle rozważy scenariusz poważny. Najskuteczniejszym zabezpieczeniem, jakie taka organizacja może wdrożyć, bywa nie kolejne narzędzie techniczne, tylko jedno proste zdanie w procedurze: zgłaszamy od razu, nawet jeśli nie jesteśmy pewni.

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

Wnioski praktyczne

• Reżim czasowy 24/72 godzin wymagany przez NIS2/KSC zakłada zgłoszenie na podstawie niepełnej wiedzy, a nie kompletnej diagnozy – organizacje, które oczekują od siebie pewności przed zgłoszeniem, systematycznie przekraczają ten termin.
• Ostry stres zawęża pole uwagi i sprzyja błędowi normalności, przez co pierwsze godziny po wykryciu nieprawidłowości są najbardziej narażone na bagatelizowanie sygnałów wskazujących na poważny incydent.
• Decyzja o zgłoszeniu powinna być przypisana konkretnej, imiennie wskazanej osobie z jasnym umocowaniem do działania na podstawie niepełnych danych – rozproszona lub niejasna odpowiedzialność decyzyjna wydłuża czas reakcji niezależnie od kompetencji technicznych zespołu.
• Wcześniej przygotowany szablon zgłoszenia wstępnego oraz jasne oddzielenie komunikatu „w toku weryfikacji” od ostatecznej oceny zdarzenia zdejmują z zespołu presję sformułowania idealnego, kompletnego raportu pod presją czasu.
• Kultura, w której zgłoszenie wątpliwości nie jest odbierane jako przyznanie się do winy, skraca czas, zanim informacja o pierwszych sygnałach incydentu dotrze do osób uprawnionych do podjęcia decyzji o formalnym zgłoszeniu.

Czy Twoja organizacja wie, kto dokładnie podejmuje decyzję o zgłoszeniu incydentu do CSIRT i ile czasu realnie zajęłoby przygotowanie takiego zgłoszenia pod presją? BetterNow.Group łączy wiedzę techniczną z zakresu cyberbezpieczeństwa z doświadczeniem w projektowaniu procesów decyzyjnych i komunikacyjnych, które działają nie tylko na papierze, ale i w pierwszych, najbardziej chaotycznych godzinach po wykryciu zdarzenia. Skontaktuj się z nami.