Analiza ryzyka krok po kroku — od inwentaryzacji do rejestru

Formalnie: ponieważ wymagają jej przepisy i normy. Praktycznie: ponieważ bez niej decyzje o wydatkach na bezpieczeństwo podejmowane są na podstawie przeczucia, aktualnych doniesień medialnych albo argumentacji dostawcy, który akurat prowadzi rozmowy handlowe.

Analiza ryzyka odpowiada na pytanie, którego nie da się rozstrzygnąć intuicyjnie: co w tej konkretnej organizacji może wyrządzić największą szkodę i gdzie każda wydana złotówka obniża ryzyko najbardziej. Odpowiedź bywa zaskakująca — bardzo często najpoważniejszym ryzykiem okazuje się nieprzetestowana procedura odtworzeniowa, a nie brak zaawansowanego narzędzia detekcji.

Jest jeszcze trzeci powód, istotny z perspektywy zarządu. Regulacje przypisują odpowiedzialność za zatwierdzenie środków zarządzania ryzykiem organom zarządzającym. Udokumentowana analiza wraz z decyzjami stanowi dowód, że nadzór był sprawowany — a jego brak przy kontroli bywa oceniany surowiej niż samo istnienie luk.

Większość nieporozumień przy analizie ryzyka bierze się z mieszania czterech pojęć. Ich rozdzielenie jest warunkiem tego, żeby rejestr nadawał się do czegokolwiek poza dokumentacją.

Zasób to coś, co ma dla organizacji wartość: proces, dane, system, kompetencja konkretnego zespołu. Zagrożenie to zdarzenie, które może ten zasób naruszyć. Podatność to słabość, która umożliwia zagrożeniu zadziałanie. Ryzyko to dopiero połączenie tych trzech elementów wraz z oceną skutku.

Przykład porządkujący: dane klientów są zasobem, ich zaszyfrowanie przez oprogramowanie wymuszające okup jest zagrożeniem, brak przetestowanej kopii zapasowej jest podatnością, a ryzyko brzmi „utrata dostępu do danych klientów na kilka dni z powodu braku możliwości odtworzenia”. Dopiero tak sformułowane ryzyko da się oszacować i przypisać komuś do obsługi.

Analiza obejmująca całą organizację naraz zwykle nie zostaje ukończona. Sensowniejszym rozwiązaniem jest wyznaczenie zakresu, który da się przeanalizować rzetelnie w rozsądnym czasie, a następnie jego rozszerzanie.

Zakres wyznaczają zwykle trzy przesłanki: wymóg regulacyjny, oczekiwanie klienta lub obszar o największej wrażliwości biznesowej. Przy przygotowaniu do zgodności naturalnym zakresem są procesy objęte regulacją. Przy ankiecie od kontrahenta — usługa świadczona temu klientowi.

Na tym etapie warto również ustalić skalę oceny i kryteria akceptowalności. Odkładanie tej decyzji do momentu, w którym ryzyka są już wypisane, prowadzi do dopasowywania progów do wyników zamiast odwrotnie.

Najczęstszy błąd metodyczny polega na rozpoczęciu od spisu systemów informatycznych. Powstaje wtedy lista, której nikt spoza działu technicznego nie potrafi zinterpretować, a zarząd nie widzi w niej żadnej treści decyzyjnej.

Właściwa kolejność jest odwrotna. Zaczyna się od procesów biznesowych: co organizacja realnie robi, na czym zarabia, jakie zobowiązania ma wobec klientów. Dopiero do procesów przypisuje się zasoby, które je wspierają — dane, systemy, dostawców, konkretne osoby.

Ta kolejność daje efekt uboczny o dużej wartości: ujawnia zależności, o których nikt wcześniej nie myślał. Bardzo często okazuje się, że kluczowy proces opiera się na arkuszu kalkulacyjnym prowadzonym przez jedną osobę albo na integracji, dla której nie ma żadnej dokumentacji.

Na tym etapie dla każdego zasobu ustala się, co może pójść nie tak. Praktyka pokazuje, że lista zagrożeń jest zaskakująco powtarzalna między organizacjami — różni je natomiast to, które z nich są realne w konkretnym kontekście.

Warto pracować kategoriami, a nie swobodnym wymienianiem. Kategorie porządkują dyskusję i zapobiegają sytuacji, w której cała uwaga skupia się na zagrożeniach zewnętrznych, a pomijane są awarie, błędy ludzkie i utrata kluczowych kompetencji.

Osobnej uwagi wymagają zagrożenia niezwiązane z atakiem. Statystycznie to one częściej powodują przerwanie działalności: awaria sprzętu, błąd konfiguracyjny, odejście jedynej osoby znającej system, niedostępność dostawcy. W analizach przygotowywanych wyłącznie przez zespoły techniczne bywają systematycznie niedoreprezentowane.

To etap, który budzi najwięcej oporu, ponieważ wymaga oceny wielkości, których nikt nie zna dokładnie. Warto przyjąć założenie porządkujące: celem nie jest wyznaczenie prawdziwej wartości, lecz uporządkowanie ryzyk względem siebie na tyle wiarygodnie, żeby dało się ustalić kolejność działań.

Z tego powodu skala trzy- lub pięciostopniowa jest w zupełności wystarczająca. Próby przeliczania ryzyka na konkretne kwoty przy kilku zdarzeniach historycznych dają wynik obarczony niepewnością tak dużą, że podważa on wiarygodność całej analizy. Precyzja pozorna jest gorsza od przyznanej niepewności.

Skutek warto oceniać wielowymiarowo, ponieważ to samo zdarzenie inaczej wygląda z perspektywy finansowej, a inaczej reputacyjnej czy regulacyjnej. Naruszenie danych o niewielkim koszcie bezpośrednim może oznaczać obowiązek zgłoszenia i utratę kluczowego kontraktu.

Zestawienie prawdopodobieństwa ze skutkiem w macierzy jest najczęściej stosowanym sposobem prezentacji. Jego zaletą jest czytelność dla zarządu, wadą — kilka złudzeń, które łatwo przeoczyć.

Pierwsza pułapka to iloczyn. Przemnożenie oceny prawdopodobieństwa przez ocenę skutku zrównuje sytuacje nieporównywalne: zdarzenie częste o niewielkim wpływie otrzymuje ten sam wynik co zdarzenie rzadkie o skutku katastrofalnym. Drugie wymaga zupełnie innej reakcji i nie powinno znikać w uśrednieniu.

Druga pułapka to skupienie środkowe. Przy skali pięciostopniowej większość ocen ląduje w środku, ponieważ jest to wybór najbezpieczniejszy dla oceniającego. Wymuszenie uzasadnienia dla ocen skrajnych albo zastosowanie skali czterostopniowej bez środka ogranicza to zjawisko.

Trzecia pułapka to traktowanie macierzy jako wyniku. Macierz jest narzędziem prezentacji, a nie decyzją. Decyzją jest dopiero to, co organizacja postanowi zrobić z ryzykami w polach oznaczonych jako nieakceptowalne.

Dla każdego ryzyka przekraczającego próg akceptowalności należy podjąć jedną z czterech decyzji. Kluczowe jest, żeby decyzja została zapisana wraz z uzasadnieniem — samo oznaczenie ryzyka jako istotnego nie jest postępowaniem z nim.

Warto zwrócić uwagę na akceptację, która bywa błędnie odbierana jako uchylenie się od działania. Akceptacja jest decyzją prawidłową i często racjonalną ekonomicznie, pod warunkiem że została podjęta na właściwym poziomie i udokumentowana. Ryzyko zaakceptowane świadomie przez zarząd ma zupełnie inny status niż ryzyko pominięte.

Przeniesienie ryzyka również wymaga ostrożności. Ubezpieczenie pokrywa skutki finansowe, natomiast nie przenosi odpowiedzialności regulacyjnej ani nie odtwarza utraconych danych. Podobnie powierzenie procesu dostawcy nie zdejmuje z organizacji odpowiedzialności za nadzór nad nim.

Rezultatem analizy jest rejestr. W większości organizacji powstaje on raz, zostaje zaakceptowany i nie jest otwierany do następnego audytu — a wtedy okazuje się nieaktualny w stopniu uniemożliwiającym jego obronę.

Rejestr użyteczny różni się od rejestru dokumentacyjnego trzema cechami: każda pozycja ma właściciela z imienia i nazwiska, każde działanie ma termin, a całość jest przeglądana w ustalonym rytmie. Bez tych trzech elementów dokument opisuje przeszłość, a nie steruje działaniem.

Forma ma znaczenie drugorzędne. Arkusz kalkulacyjny prowadzony rzetelnie jest wart więcej niż dedykowane narzędzie wypełnione raz i porzucone. Narzędzia stają się uzasadnione dopiero przy liczbie ryzyk, przy której ręczne utrzymanie zaczyna być zawodne.

Analiza przeprowadzona wyłącznie przez dział techniczny jest systematycznie zniekształcona. Powstaje obraz ryzyka technologicznego, w którym brakuje zależności od pojedynczych osób, słabości procesów i konsekwencji biznesowych, których zespół IT nie ma podstaw oceniać.

Właściwy skład obejmuje właścicieli procesów biznesowych, przedstawiciela IT, osobę odpowiedzialną za obszar prawny lub zgodność oraz przedstawiciela zarządu. Rola prowadzącego polega na zadawaniu pytań i pilnowaniu metodyki, nie na dostarczaniu odpowiedzi.

Sprawdza się forma warsztatu zamiast obiegu dokumentu. Rozmowa ujawnia zależności, których nikt nie wpisałby do formularza, ponieważ wydają się oczywiste — a właśnie takie założenia bywają najsłabszym punktem organizacji.

Minimum wyznaczają regulacje i normy: przegląd co najmniej raz w roku. W praktyce częstotliwość powinna wynikać z tempa zmian w organizacji, a nie wyłącznie z kalendarza.

Poza rytmem rocznym przegląd powinny uruchamiać zdarzenia istotne: wdrożenie nowego systemu kluczowego dla działalności, zmiana dostawcy krytycznego, incydent bezpieczeństwa, wejście na nowy rynek lub przejęcie innego podmiotu. Każde z nich zmienia obraz ryzyka w sposób, którego roczny przegląd nie wychwyci na czas.

Przegląd nie oznacza powtarzania całej analizy. W większości przypadków wystarczy weryfikacja, czy oceny pozostają aktualne, czy zadeklarowane działania zostały wykonane i czy pojawiły się nowe zasoby lub zależności.

Te dwa pojęcia bywają mylone, choć odpowiadają na inne pytania i powstają w innym celu. Analiza ryzyka pyta, co może się wydarzyć i z jakim prawdopodobieństwem. Analiza wpływu na działalność pyta, co się stanie, gdy proces przestanie działać — niezależnie od przyczyny.

Różnica ma konsekwencje praktyczne. Analiza ryzyka prowadzi do doboru zabezpieczeń, analiza wpływu — do wyznaczenia celów odtworzeniowych: jak szybko proces musi wrócić i ile danych organizacja może stracić bez katastrofalnych skutków. Bez tych celów plan ciągłości działania nie ma podstaw, a testy odtworzeniowe nie mają kryterium zaliczenia.

W praktyce oba działania warto prowadzić równolegle, ponieważ korzystają z tej samej inwentaryzacji procesów. Rozdzielenie ich na osobne projekty oznacza dwukrotne wykonanie najbardziej czasochłonnej części pracy — ustalenia, co organizacja robi i od czego to zależy.

Poniższe błędy powtarzają się niezależnie od branży i wielkości organizacji. Ich skutkiem jest zwykle dokument formalnie poprawny, lecz nieużywany.

Wszystkie kluczowe regulacje wymagają analizy ryzyka, choć różnią się szczegółowością wymagań. Dyrektywa NIS2 umieszcza ją na pierwszym miejscu katalogu środków zarządzania ryzykiem w art. 21. ISO/IEC 27001 czyni z niej podstawę doboru zabezpieczeń i deklaracji stosowania. Rozporządzenie DORA rozbudowuje wymagania w odniesieniu do ryzyka technologicznego w sektorze finansowym.

Wspólny mianownik jest istotny praktycznie: żadna z tych regulacji nie narzuca konkretnej metodyki. Wymagają natomiast, aby proces był udokumentowany, powtarzalny i prowadził do decyzji podejmowanych na właściwym poziomie. Oznacza to, że jedna dobrze przeprowadzona analiza może obsłużyć kilka reżimów jednocześnie.

Ma to bezpośrednie przełożenie na koszt. Organizacje przygotowujące się równolegle do kilku wymogów często prowadzą osobne projekty, powielając tę samą pracę. Wspólna analiza ryzyka jako fundament, uzupełniana o wymagania specyficzne dla każdej regulacji, jest rozwiązaniem znacznie efektywniejszym.

Organizacje odkładają analizę ryzyka, ponieważ wyobrażają sobie wielomiesięczny projekt. Pierwsza wersja, wystarczająca do podejmowania decyzji, powstaje jednak w kilka dni — pod warunkiem świadomego ograniczenia zakresu.

Racjonalne podejście polega na objęciu analizą trzech najważniejszych procesów biznesowych i wypisaniu dla nich kilkunastu najbardziej prawdopodobnych scenariuszy. Taki rejestr jest niekompletny, lecz od razu pokazuje, gdzie leżą największe braki — a to wystarczy, żeby uruchomić działania.

Rozszerzanie następuje w kolejnych przeglądach. Rejestr rozwijany stopniowo, lecz utrzymywany, ma wielokrotnie większą wartość niż kompletna analiza wykonana raz i pozostawiona bez aktualizacji.