Zarządzanie ryzykiem IT to uporządkowany sposób nazywania zagrożeń dla usług i danych, przypisywania im właściciela i rozstrzygania, które z nich obniżamy, a które akceptujemy świadomie. Menedżer zespołu nie potrzebuje do tego osobnego działu: potrzebuje spisu zasobów, rejestru ryzyk, decyzji o postępowaniu i stałego rytmu przeglądu.
Na skróty
Czego dowiesz się z artykułu:
- Co trafia do rejestru ryzyk, a co jest tylko listą usterek
- Jak wygląda rejestr, który da się utrzymać bez dedykowanego zespołu
- Czego w zakresie analizy ryzyka wymaga dyrektywa NIS2
- Jaki rytm przeglądu utrzymuje rejestr żywy, a nie archiwalny
Dla kogo jest ten artykuł:
- Menedżerowie zespołów IT i liderzy techniczni bez wsparcia działu ryzyka
- Osoby odpowiadające w średniej firmie za zgodność i ciągłość usług
- Właściciele usług, którzy mają podpisać decyzję o akceptacji ryzyka
Czas czytania: 7 minut
Co właściwie oceniamy: zasoby, nie narzędzia
Pierwszy błąd wdrożenia to zaczynanie od listy zagrożeń. Lista zagrożeń jest nieskończona i rośnie szybciej, niż zespół zdąży ją przeczytać. Punktem wyjścia jest spis tego, co faktycznie trzeba chronić: usługi, dane, konta uprzywilejowane, integracje z dostawcami. Dopiero do nazwanego zasobu da się przypisać scenariusz utraty, a bez scenariusza nie ma czego oceniać.
Drugi błąd to mieszanie rejestru ryzyk z listą usterek. Niezaktualizowana biblioteka w jednym serwisie jest podatnością — pozycją dla zespołu technicznego i narzędzi skanujących. Ryzykiem jest dopiero zdanie, które mówi, co się stanie z usługą i kto ponosi skutek: „utrata dostępu do systemu kadrowego na dobę zatrzymuje wypłatę wynagrodzeń”. Pierwsze zamyka się zgłoszeniem, drugie wymaga decyzji właściciela.
Rozróżnienie wygląda formalnie, a rozstrzyga o tym, kto czyta rejestr. Rejestr pełen podatności czyta tylko administrator. Rejestr zapisany językiem skutku dla usługi czyta zarząd — i to jest warunek, żeby cokolwiek z niego wynikło.
Rejestr ryzyk: minimum, które da się utrzymać
Przewodnik oceny ryzyka csrc.nist.gov (SP 800-30 Rev. 1) opisuje ocenę jako złożenie prawdopodobieństwa wystąpienia i wielkości skutku, z jawnie zapisanymi poziomami i kryteriami przypisania. Macierz prawdopodobieństwo×skutek jest tu narzędziem opisu, nie wyrokiem: jej wartość zależy wyłącznie od tego, czy progi poziomów zostały nazwane przed wypełnieniem, a nie dopasowane po.
Minimalny rejestr, który utrzymuje się w zespole, ma dla każdej pozycji: nazwany zasób, scenariusz utraty, poziom prawdopodobieństwa, poziom skutku, właściciela ryzyka, decyzję o postępowaniu i datę przeglądu. Materiały enisa.europa.eu zbierają metodyki i wytyczne zarządzania ryzykiem, z których korzysta się przy doborze skali; samo postępowanie z ryzykiem sprowadza się w praktyce do rozstrzygnięć: obniżyć, przenieść, unikać albo zaakceptować. Akceptacja jest pełnoprawną decyzją — pod warunkiem że ma podpis osoby, która ponosi skutek, a nie milczenie zespołu.
To, czego w minimalnym rejestrze nie ma, jest równie istotne. Nie ma punktacji wyliczanej w arkuszu z pozorną dokładnością, bo precyzja wyniku nie przewyższy jakości oszacowania wejściowego. Nie ma też pozycji bez właściciela: ryzyko, którego nikt nie posiada, nie zostanie przejrzane ani zamknięte.
Czego wymaga NIS2 i gdzie zaczyna się zgodność
Dyrektywa NIS2, czyli dyrektywa (UE) 2022/2555 opublikowana w eur-lex.europa.eu, wymienia analizę ryzyka i politykę bezpieczeństwa systemów informatycznych jako pierwszy ze środków zarządzania ryzykiem w art. 21. Ten sam akt przypisuje organom kierowniczym podmiotu zatwierdzanie środków i odpowiedzialność za ich wdrożenie, co przenosi rejestr z pozycji dokumentu technicznego na pozycję materiału dla zarządu.
Dla menedżera zespołu konsekwencja jest praktyczna i wąska: jeśli firma jest podmiotem objętym dyrektywą, rejestr ryzyk przestaje być dobrą praktyką, a staje się dowodem. Dowód ma datę, autora i ślad decyzji — czyli dokładnie te pola, które wyżej opisano jako minimum. Zgodność nie zaczyna się od zakupu narzędzia, lecz od tego, że w organizacji jest aktualna, wskazana z nazwy wersja tego spisu.
Warto też rozdzielić obowiązek posiadania procesu od obowiązku zgłaszania incydentów, bo w rozmowach o zgodności zlewają się one w całość. Pierwszy jest ciągły i mierzy się rytmem przeglądu, drugi uruchamia się zdarzeniem i mierzy się czasem reakcji.
Rytm przeglądu i rola właściciela ryzyka
Rejestr umiera wtedy, gdy przegląd jest zbyt rzadki, żeby wychwycić zmianę, albo tak częsty, że zespół zaczyna go wypełniać mechanicznie. Rytm kwartalny dla całości rejestru i doraźny przegląd po każdej istotnej zmianie architektury, dostawcy lub zakresu danych wystarcza w średniej organizacji.
Właściciel ryzyka to funkcja, nie stanowisko. Jest nim osoba, która dysponuje budżetem i mandatem, żeby skutek obniżyć albo świadomie go przyjąć — zwykle właściciel usługi lub kierownik obszaru, nie administrator techniczny. Tam, gdzie powołano CISO, jego rolą jest prowadzenie procesu i kwestionowanie oszacowań, a nie przejmowanie ryzyk od właścicieli. Pomyłka w tym miejscu jest najczęstszą przyczyną rejestrów, w których wszystkie pozycje należą do jednej osoby, a więc nie należą do nikogo.
Ostatni element planu wdrożenia jest najmniej techniczny: język. Jeśli rejestr jest zapisany tak, że osoba decydująca rozumie go bez tłumacza, proces zaczyna wpływać na decyzje. Jeśli nie — zostaje załącznikiem do audytu.
Czytaj także
- Zarządzanie ryzykiem — przewodnik po ISO 31000, strategiach i praktyce — szersza rama procesowa, przydatna przy uzgadnianiu nazw poziomów i kryteriów
- Czym jest dyrektywa NIS2? Nowe wymogi i obowiązki w zakresie cyberbezpieczeństwa — zakres podmiotowy i obowiązki, których rejestr ma być dowodem
- Audyt bezpieczeństwa IT — jak się przygotować — audyt czyta rejestr ryzyk jako dowód, więc jego lista wymagań pokazuje, które pola i jaki rytm przeglądu muszą być gotowe, zanim przyjdzie audytor
Rozwijaj kompetencje
Temat rozwijają szkolenia Zarządzanie ryzykiem w bezpieczeństwie informacji oraz Strategiczne zarządzanie ryzykiem w organizacji — identyfikacja, analiza, rejestr ryzyk. Pierwsze pracuje na warstwie bezpieczeństwa informacji, drugie na rejestrze i decyzjach zarządu. Skontaktuj się z nami, żeby dopasować zakres do Twojego obszaru odpowiedzialności.
Najczęściej zadawane pytania (FAQ)
Czym różni się zarządzanie ryzykiem IT od zarządzania ryzykiem w projekcie?
Zakresem i horyzontem. Ryzyko projektowe dotyczy dostarczenia zakresu w terminie i budżecie, więc zamyka się razem z projektem. Ryzyko IT dotyczy usługi, która działa po zakończeniu projektu, i ma właściciela utrzymania. Rejestry bywają prowadzone równolegle; łączy je moment, w którym projekt oddaje usługę i przekazuje też jej ryzyka.
Jaką metodę oceny wybrać na start?
Jakościową, z nazwanymi poziomami prawdopodobieństwa i skutku. Metody ilościowe mają sens, gdy istnieją dane historyczne o awariach i kosztach przestoju; bez nich wynik liczbowy jest pozorną precyzją. Przejście na ocenę ilościową jest łatwiejsze z działającego rejestru jakościowego niż odwrotnie.
Czy potrzebuję oprogramowania do zarządzania ryzykiem?
Nie na początku. Rejestr kilkudziesięciu pozycji utrzymuje się w arkuszu albo w systemie zadań, który zespół już zna. Narzędzie dedykowane zarabia na siebie, gdy pojawia się wiele jednostek, wymóg ścieżki audytu i powiązania z rejestrem dostawców — czyli wtedy, gdy ręczne utrzymanie zaczyna gubić wersje.
Czy menedżer zespołu może prowadzić rejestr bez wsparcia bezpieczeństwa informacji?
Może prowadzić, ale nie powinien zatwierdzać sam. Prowadzenie rejestru to praca redakcyjna i proceduralna, mieszcząca się w zakresie menedżera. Zatwierdzenie akceptacji ryzyka wymaga mandatu właściciela usługi, a w organizacji objętej obowiązkami regulacyjnymi — także zatwierdzenia środków przez organ kierowniczy.