Rejestr ryzyka cyberbezpieczeństwa porządkuje wiedzę o zagrożeniach, podatnościach, możliwych skutkach i decyzjach dotyczących zabezpieczeń. W podmiocie objętym KSC lub NIS2 powinien być aktualnym narzędziem zarządczym powiązanym z SZBI, właścicielami ryzyka, planem postępowania i dowodami skuteczności, a nie jednorazowym arkuszem przygotowanym przed audytem.
Pozycja „ransomware – ryzyko wysokie” nie mówi zarządowi, jaka usługa może zostać zatrzymana, dlaczego obecne zabezpieczenia są niewystarczające, kto ma podjąć decyzję ani co należy wykonać. Dopiero połączenie kontekstu, oceny, odpowiedzialności, działania i dowodu tworzy użyteczny zapis.
Decyzjaogranicz, unikaj, przenieś lub zaakceptuj
Rezultatryzyko pod kontrolą i ślad działania
Rejestr jest praktycznym sposobem utrwalenia wyników procesu. Powinien pozwalać ustalić, czego dotyczy ryzyko, jaki scenariusz analizowano, jakie środki już działają, kto odpowiada za decyzję, co ma zostać wykonane i kiedy nastąpi ponowna ocena.
Czy KSC, NIS2 i ISO 27001 wymagają rejestru ryzyka?
Znowelizowana ustawa o krajowym systemie cyberbezpieczeństwa wymaga od podmiotów kluczowych i ważnych wdrożenia systematycznego oraz udokumentowanego procesu zarządzania ryzykiem. Przyjęte środki techniczne, operacyjne i organizacyjne mają być odpowiednie do stopnia narażenia, wielkości podmiotu oraz prawdopodobieństwa i możliwych skutków incydentu.
Ustawa nie wskazuje jednak obowiązkowego pliku o nazwie „rejestr ryzyka” ani wzoru tabeli do skopiowania. Obowiązek dotyczy procesu i jego wyników. Organizacja musi umieć wykazać, że rozpoznaje ryzyka, podejmuje wobec nich decyzje, wdraża środki, ocenia ich skuteczność i aktualizuje ocenę po zmianach. Aktualny rejestr jest najprostszym sposobem uporządkowania tych informacji i połączenia ich z dokumentacją operacyjną.
Podobną logikę przyjmuje art. 21 dyrektywy NIS2. Wymaga on podejścia uwzględniającego wszystkie zagrożenia oraz środków obejmujących między innymi analizę ryzyka, obsługę incydentów, ciągłość działania, bezpieczeństwo łańcucha dostaw, ocenę skuteczności zabezpieczeń, kontrolę dostępu i zarządzanie aktywami.
ISO/IEC 27001:2022 wymaga określenia kryteriów oceny i akceptacji ryzyka, prowadzenia porównywalnych ocen, identyfikacji właścicieli oraz zachowania udokumentowanych wyników oceny i postępowania. Norma również nie nakazuje używania konkretnego programu ani jednej macierzy. ISO/IEC 27005 rozwija tę metodykę i opisuje pełny cykl identyfikacji, oceny, postępowania, komunikacji, monitorowania oraz przeglądu ryzyka.
Szablon może uporządkować kolumny, ale nie zastąpi określenia zakresu SZBI, krytycznych usług, zależności i kryteriów oceny. Rejestr skopiowany z internetu zwykle zawiera ogólne opisy ryzyk, których nie można połączyć z decyzjami ani budżetem konkretnej organizacji.
Rejestr, metodyka, plan postępowania i Deklaracja Stosowania
Cztery elementy bywają łączone w jednym arkuszu, ale pełnią inne funkcje. Ich rozdzielenie ułatwia aktualizację, nadawanie odpowiedzialności i przedstawianie informacji zarządowi.
Metodyka
Określa zakres, skale, kryteria prawdopodobieństwa i skutku, progi akceptacji, częstotliwość przeglądu oraz sposób zatwierdzania wyników.
Rejestr ryzyka
Pokazuje scenariusze, właścicieli, istniejące zabezpieczenia, ocenę oraz podjętą decyzję. Powinien zmieniać się wraz z organizacją.
Plan postępowania
Przekłada decyzję na zabezpieczenia, zadania, odpowiedzialność, zasoby, terminy, status i oczekiwany poziom ryzyka po wykonaniu.
Deklaracja Stosowania
Wskazuje niezbędne zabezpieczenia, uzasadnia ich włączenie albo wyłączenie i pokazuje status wdrożenia. Nie jest ustawowym zamiennikiem rejestru.
Szerszą mapę polityk, procedur i rejestrów przedstawia poradnik Dokumentacja SZBI – jakie polityki, procedury i rejestry musi posiadać firma? Rejestr ryzyka powinien być z tą dokumentacją połączony, lecz nie może zostać zastąpiony samą polityką bezpieczeństwa.
Jak przygotować rejestr ryzyka cyberbezpieczeństwa krok po kroku?
Punktem wyjścia nie jest lista zagrożeń, lecz zakres SZBI i usługi, które organizacja musi utrzymać. Dopiero po ustaleniu, co jest istotne dla działalności, można rozpoznać aktywa, zależności, możliwe zdarzenia i ich skutki.
Warsztat identyfikacji ryzyka powinien łączyć wiedzę właścicieli procesów, IT, bezpieczeństwa, prawa i osób zarządzających dostawcami. Zespół techniczny wie, gdzie istnieją podatności i zależności. Właściciel procesu potrafi ocenić czas przestoju, wpływ na klientów i zobowiązania umowne. Zarząd określa poziom ryzyka, który może zostać zaakceptowany, oraz zapewnia środki na działania.
Jakie pola powinien zawierać rejestr ryzyka cyberbezpieczeństwa?
Zakres pól powinien wynikać z przyjętej metodyki. Poniższy zestaw pozwala jednak zbudować czytelny ślad od kontekstu biznesowego do zatwierdzonej decyzji i późniejszego przeglądu.
| Pole | Co należy zapisać | Dlaczego jest potrzebne | Przykład |
|---|---|---|---|
| Identyfikator | Stały, unikalny numer ryzyka | Łączy rejestr z zadaniami, raportami, incydentami i protokołami | R-ERP-014 |
| Usługa lub proces | Proces biznesowy, którego ciągłość albo bezpieczeństwo jest zagrożone | Pozwala oceniać skutek dla działalności, a nie tylko dla urządzenia | Realizacja zamówień i fakturowanie |
| Aktywa i zależności | Systemy, dane, personel, lokalizacje, dostawcy i usługi wspierające proces | Pokazuje, od czego rzeczywiście zależy usługa | ERP, baza klientów, dostawca chmury, łącze internetowe |
| Scenariusz | Zdarzenie, przyczyna, wykorzystana słabość i konsekwencje | Precyzuje zakres ryzyka i umożliwia dobór zabezpieczeń | Zaszyfrowanie ERP po przejęciu konta administratora |
| Właściciel ryzyka | Osoba uprawniona do podjęcia lub eskalowania decyzji biznesowej | Zapobiega przenoszeniu całej odpowiedzialności na IT | Dyrektor operacyjny |
| Istniejące środki | Faktycznie wdrożone zabezpieczenia wraz z odwołaniem do dowodów | Ocena nie może opierać się na planach ani deklaracjach | MFA, EDR, backup offline, segmentacja, test odtworzenia |
| Ocena | Prawdopodobieństwo, skutek, poziom ryzyka i uzasadnienie | Umożliwia porównanie i priorytetyzację | 4 × 5 = 20, ryzyko krytyczne |
| Decyzja | Ograniczenie, unikanie, przeniesienie albo akceptacja | Każde istotne ryzyko musi prowadzić do świadomej decyzji | Ograniczenie |
| Plan działania | Zadania, odpowiedzialny, zasoby, termin, status i oczekiwany rezultat | Zmienia ocenę w wykonalny plan | PAM i oddzielne konta administracyjne do 31 stycznia |
| Ryzyko rezydualne | Poziom pozostający po działających lub planowanych środkach | Pokazuje, czy rezultat mieści się w kryteriach akceptacji | 2 × 4 = 8, średnie |
| Akceptacja i przegląd | Decydent, data, warunki akceptacji, kolejny przegląd i zdarzenia wyzwalające | Utrwala odpowiedzialność i zapobiega bezterminowej akceptacji | Zarząd, przegląd za kwartał lub po incydencie |
Nie każda organizacja potrzebuje identycznej liczby kolumn. Mały podmiot może połączyć kilka pól, a rozbudowana grupa kapitałowa może dodać identyfikatory wymagań prawnych, lokalizacje, jednostki organizacyjne, koszty działań i powiązania z celami ciągłości. Rejestr musi pozostać zrozumiały dla osób, które podejmują decyzje.
Jak prawidłowo opisać ryzyko w rejestrze?
Opis ryzyka powinien przedstawiać konkretny scenariusz przyczynowo-skutkowy. Nie trzeba przewidywać każdego wariantu ataku. Należy jednak wskazać zdarzenie, podatność, zagrożoną usługę lub informację oraz możliwe konsekwencje. Taki opis pozwala ocenić poziom ryzyka i dobrać właściwe zabezpieczenia.
Źródło zagrożenia lub zdarzenie wykorzystuje podatność albo niekorzystny warunek, przez co dochodzi do naruszenia usługi lub informacji, powodującego określone konsekwencje biznesowe, prawne albo operacyjne.
Ransomware – ryzyko wysokie.
Nie wiadomo, którego procesu dotyczy wpis, jak może dojść do zdarzenia, jakie środki już działają ani kto powinien podjąć decyzję.
Przejęcie konta administratora bez odpornego na phishing MFA może umożliwić zaszyfrowanie systemu ERP i kopii dostępnych online, powodując zatrzymanie realizacji zamówień oraz fakturowania na ponad 48 godzin.
Warto oddzielać zagrożenie od podatności. Atakujący, błąd pracownika, awaria zasilania albo pożar są źródłami zagrożenia lub zdarzeniami. Brak MFA, nieaktualny system, jedna kopia danych albo nieweryfikowane uprawnienia są słabościami zwiększającymi prawdopodobieństwo lub skutek.
Jak ocenić prawdopodobieństwo i skutek?
Metodyka powinna definiować każdą wartość skali. Samo oznaczenie prawdopodobieństwa jako „3” nie pozwala powtórzyć oceny. Organizacja powinna ustalić, czy oznacza ono zdarzenie możliwe raz na kilka lat, obserwowane w branży, czy scenariusz, dla którego istnieją już próby wykorzystania podatności.
Skutek warto oceniać w kilku wymiarach: przestój usługi, utrata lub zmiana danych, odpowiedzialność regulacyjna, konsekwencje umowne, strata finansowa, wpływ na klientów, zdrowie i bezpieczeństwo oraz reputację. Metodyka powinna też wyjaśniać, czy o wyniku decyduje najwyższy wymiar, średnia, suma czy reguła mieszana.
Prawd. →
Przykład wizualny. UoKSC, NIS2 ani ISO 27001 nie narzucają macierzy 5 × 5 ani przedstawionych progów. Organizacja powinna zdefiniować własne kryteria i stosować je konsekwentnie.
Dwa scenariusze z wynikiem 12 mogą mieć zupełnie inne znaczenie. Jeden może dotyczyć krótkiego przestoju wewnętrznego narzędzia, drugi naruszenia danych lub usługi krytycznej. Przy ocenie należy zachować opis przesłanek, źródeł i przyjętych założeń.
Ryzyko pierwotne, aktualne, rezydualne i docelowe
Ryzyko pierwotne
Pokazuje potencjalną ekspozycję przed uwzględnieniem środków ochronnych. Pomaga zrozumieć znaczenie procesu i wartość zabezpieczeń.
Ryzyko aktualne
Uwzględnia środki, które rzeczywiście działają i mają dowody. Nie należy obniżać oceny na podstawie działań dopiero zaplanowanych.
Ryzyko docelowe
To oczekiwany poziom po zakończeniu planu. Po wdrożeniu trzeba go zweryfikować testem i ponowną oceną, zanim stanie się ryzykiem rezydualnym.
Terminologia może różnić się pomiędzy organizacjami. Najważniejsze, aby metodyka jednoznacznie wyjaśniała, czy „ryzyko rezydualne” oznacza poziom obecny po działających zabezpieczeniach, czy oczekiwany wynik po zakończeniu planu. Mieszanie obu znaczeń prowadzi do przedstawiania planów jako już osiągniętych rezultatów.
Kto jest właścicielem ryzyka i kto może je zaakceptować?
Właścicielem ryzyka powinna być osoba mająca wystarczającą wiedzę o procesie oraz umocowanie do podjęcia decyzji albo eskalowania jej do zarządu. Nie zawsze będzie to kierownik IT. Jeżeli ryzyko dotyczy ciągłości produkcji, rozliczeń, świadczenia usług medycznych albo obsługi klientów, jego właścicielem powinien być odpowiedni właściciel biznesowy.
Ocenia znaczenie biznesowe, rekomenduje sposób postępowania i pilnuje, aby decyzja została podjęta.
Odpowiada za utrzymanie konkretnego zabezpieczenia i dostarczanie dowodów jego skuteczności.
Realizuje zadanie z planu w uzgodnionym zakresie, terminie i budżecie.
Akceptuje ryzyko w granicach uprawnień albo zatwierdza zasoby potrzebne do jego ograniczenia.
Pełnomocnik ds. cyberbezpieczeństwa nadzorujący SZBI może prowadzić warsztaty, utrzymywać rejestr, monitorować działania i przygotowywać materiał dla zarządu. Nie powinien jednak akceptować ryzyka biznesowego zamiast właściwego właściciela ani zatwierdzać własnych rekomendacji bez odpowiedniego nadzoru.
Jak połączyć rejestr z planem postępowania z ryzykiem?
Ocena bez decyzji nie kończy procesu. Dla każdego ryzyka należy określić sposób postępowania: ograniczenie, unikanie, przeniesienie lub współdzielenie albo świadomą akceptację. Następnie decyzja musi zostać przełożona na konkretne zadania.
Plan powinien wskazywać środek lub zmianę organizacyjną, właściciela działania, zasoby, termin, mierzalny rezultat i dowód wykonania. Dla wdrożenia MFA dowodem nie będzie samo zamówienie licencji, lecz raport pokrycia kont, konfiguracja, wynik testu oraz lista uzasadnionych wyjątków. Dla kopii zapasowych nie wystarczy harmonogram backupu – potrzebny jest wynik odtworzenia.
Po zakończeniu działania właściciel powinien sprawdzić, czy środek funkcjonuje i czy zmienił ocenę zgodnie z założeniem. Dopiero wtedy można zaktualizować poziom ryzyka. Taki cykl tworzy dowód działania Systemu Zarządzania Bezpieczeństwem Informacji.
Czy rejestr prowadzi do rzeczywistych decyzji?
Audyt zerowy KSC/NIS2 pozwala zweryfikować zakres, kryteria, odpowiedzialność i ślad dowodowy, a następnie zbudować plan działań dopasowany do ryzyka organizacji.
Umów bezpłatną konsultacjęJak ujmować ryzyko dostawców i łańcucha dostaw?
Ryzyko dostawcy nie powinno kończyć się na informacji, że firma korzysta z chmury albo zewnętrznego serwisu. Trzeba ustalić, jakie procesy zależą od usługi, do jakich danych i systemów dostawca ma dostęp, jak organizacja zareaguje na niedostępność oraz czy istnieje realna możliwość migracji.
W rejestrze warto uwzględniać koncentrację usług u jednego dostawcy, jego podwykonawców, zakończenie wsparcia produktu, dostęp uprzywilejowany, lokalizację danych, terminy zgłaszania incydentów, uzależnienie od własnościowych formatów oraz brak przetestowanego planu wyjścia. Ocena powinna być powtarzana w trakcie umowy, szczególnie po zmianie zakresu usługi, istotnym incydencie lub zmianie podwykonawców.
Rejestr pokazuje ryzyko i decyzję, natomiast umowa powinna zapewniać narzędzia potrzebne do jego kontrolowania. Pomocniczo warto wykorzystać poradnik Umowa z dostawcą IT NIS2 – 12 klauzul chroniących firmę.
Przykład kompletnego wpisu w rejestrze
Ransomware a system ERP i realizacja zamówień
Proces zależy od ERP, bazy danych, integracji z magazynem, kont administracyjnych i dostawcy utrzymania.
Skutkiem może być przerwa przekraczająca 48 godzin, utrata bieżących danych, opóźnienia dostaw i kary umowne.
Ostatni test odtworzenia wykonano osiem miesięcy temu. MFA nie obejmuje wszystkich kont administratorów, a kopie są dostępne z domeny.
Ocena uwzględnia aktywne kampanie ransomware, niespójne MFA, brak izolowanej kopii i krytyczność ERP.
Wdrożenie odpornego na phishing MFA, oddzielnych kont, repozytorium offline, segmentacji oraz kwartalnych testów odtworzenia. Właściciele i terminy przypisani w planie.
Skutek awarii pozostanie istotny, ale prawdopodobieństwo i czas odtworzenia powinny spaść. Wynik wymaga potwierdzenia testem.
Akceptacja jest czasowa, zawiera warunek realizacji działań i nie obejmuje niewdrożonych zabezpieczeń.
Niezależnie od zdarzeń przegląd nastąpi najpóźniej w kolejnym kwartale wraz z raportem dla zarządu.
Przykład pokazuje, dlaczego nie każde działanie obniża wszystkie elementy oceny. MFA i segmentacja zmniejszają prawdopodobieństwo przejęcia środowiska, a izolowana kopia i test odtworzenia ograniczają czas przestoju. Skutek utraty krytycznego ERP nadal może pozostać wysoki, dlatego rezultat powinien być oceniany realistycznie.
Kiedy aktualizować rejestr ryzyka?
Przegląd roczny może być elementem kalendarza SZBI, lecz nie wystarcza w szybko zmieniającej się organizacji. Aktualizacja powinna następować również po zdarzeniach, które zmieniają usługi, zależności, zagrożenia albo skuteczność zabezpieczeń.
Nowa usługa, fuzja, reorganizacja, zmiana lokalizacji albo właściciela procesu.
Migracja do chmury, nowy system, integracja, dostawca albo wycofanie wsparcia.
Incydent, istotna podatność, nieudany test, awaria lub sygnał o nieskutecznym środku.
Zmiana prawa, umowy, wymagań klienta, regulatora albo przyjętego standardu.
Każdy wpis powinien mieć datę przeglądu, ale także katalog zdarzeń uruchamiających wcześniejszą ocenę. Jeżeli rejestr jest aktualizowany wyłącznie przed audytem, nie wspiera codziennych decyzji i przedstawia historyczny obraz organizacji.
Najczęstsze błędy w rejestrze ryzyka
| Błąd | Dlaczego osłabia proces | Jak go poprawić |
|---|---|---|
| Ogólne opisy ryzyk | Nie wskazują usług, przyczyn, skutków ani zabezpieczeń | Budować scenariusze powiązane z procesami i aktywami |
| Właścicielem wszystkiego jest IT | IT nie może samodzielnie ocenić wpływu na wszystkie cele biznesowe | Przypisać ryzyka właścicielom procesów z pomocą ekspertów |
| Plan obniża ocenę przed wykonaniem | Przedstawia oczekiwany stan jako już osiągnięty | Oddzielić ocenę aktualną od docelowej i wymagać dowodów |
| Akceptacja bez terminu | Ryzyko może pozostać poza kontrolą mimo zmiany warunków | Określić ważność decyzji, warunki i zdarzenia przeglądowe |
| Zabezpieczenie bez testu | Samo wdrożenie nie potwierdza skuteczności | Powiązać środek z wynikiem testu, raportem lub logiem |
| Usuwanie zamkniętych ryzyk | Traci się historię decyzji i zmian profilu ryzyka | Archiwizować wpis z datą, uzasadnieniem i śladem zatwierdzenia |
Checklista gotowości rejestru
Rejestr powinien pozwolić odpowiedzieć twierdząco na każde z poniższych pytań.
FAQ: rejestr ryzyka cyberbezpieczeństwa
Czy UoKSC wprost wymaga dokumentu o nazwie „rejestr ryzyka”?
Ustawa wymaga systematycznego, udokumentowanego zarządzania ryzykiem oraz dokumentacji potwierdzającej wykonywanie wymaganych czynności. Nie narzuca jednego wzoru ani nazwy pliku. Rejestr jest praktyczną formą utrwalenia aktualnych wyników, decyzji i odpowiedzialności.
Czy rejestr ryzyka można prowadzić w Excelu?
Tak, jeżeli arkusz zapewnia kontrolę dostępu, wersjonowanie, przypisanie odpowiedzialności, historię zmian i powiązanie z działaniami. W większych organizacjach wygodniejsze może być narzędzie GRC albo system obsługi zadań, ale samo narzędzie nie decyduje o jakości procesu.
Ile pozycji powinien zawierać rejestr?
Nie istnieje prawidłowa liczba wspólna dla wszystkich podmiotów. Rejestr ma pokrywać istotne scenariusze dotyczące usług i zakresu SZBI. Zbyt mała liczba może oznaczać pominięcia, a setki niemal identycznych wpisów utrudniają podejmowanie decyzji.
Czy ISO 27001 wymaga macierzy ryzyka 5 × 5?
Nie. Organizacja określa własne kryteria i metodę, pod warunkiem że wyniki są spójne, ważne i porównywalne. Może zastosować skalę jakościową, ilościową albo model mieszany.
Kto może zaakceptować ryzyko rezydualne?
Osoba posiadająca formalne uprawnienie i odpowiednią odpowiedzialność biznesową, zgodnie z progami określonymi w metodyce. Ryzyka przekraczające kompetencje właściciela powinny zostać eskalowane do zarządu. Pełnomocnik lub ekspert może rekomendować decyzję, ale nie powinien zastępować właściwego decydenta.
Czy rejestr ryzyka RODO może zastąpić rejestr SZBI?
Zwykle nie. Analiza ryzyka RODO skupia się na prawach i wolnościach osób fizycznych, a ocena SZBI obejmuje również ciągłość usług, systemy, aktywa, zobowiązania umowne i cele organizacji. Dane można współdzielić, ale kryteria i zakresy należy wyraźnie rozróżnić.
Czy Deklaracja Stosowania jest tym samym co rejestr ryzyka?
Nie. Rejestr opisuje scenariusze i wyniki oceny. Deklaracja Stosowania w modelu ISO 27001 pokazuje niezbędne zabezpieczenia, uzasadnienie ich zastosowania lub wyłączenia oraz status wdrożenia. Dokumenty powinny być ze sobą spójne.
Jak często aktualizować rejestr ryzyka?
W zaplanowanych odstępach oraz po istotnych zmianach, incydentach, nowych podatnościach, wdrożeniach i nieskutecznych testach. Częstotliwość powinna wynikać z ryzyka; krytyczne obszary mogą wymagać przeglądu częściej niż raz w roku.
Czy jeden rejestr może służyć zgodności z KSC, NIS2 i ISO 27001?
Tak. Jeden spójny rejestr może obsługiwać kilka źródeł wymagań, jeżeli obejmuje ich zakres, pozwala wskazać podstawę oceny i pozostaje zgodny z przyjętą metodyką. Nie ma potrzeby tworzenia trzech równoległych rejestrów tych samych scenariuszy.
Rejestr ryzyka powinien prowadzić do decyzji, a nie kończyć się na ocenie
Podczas wdrożenia SZBI łączymy ryzyka z usługami, właścicielami, zabezpieczeniami i konkretnym planem postępowania. Dzięki temu zarząd otrzymuje aktualny materiał decyzyjny, a organizacja dowody rzeczywistego działania systemu.