Analiza ryzyka w NIS2 – jak osiągnąć zgodność krok po kroku (przewodnik 2026)

W wielu organizacjach proces szacowania ryzyka nadal pozostaje niewystarczająco dojrzały. Problem ten nie wynika z braku zaangażowania zespołów, lecz raczej z utrwalonego podejścia do bezpieczeństwa jako zbioru narzędzi i inicjatyw, a nie jako procesu zarządzania ryzykiem. W praktyce oznacza to, że decyzje o inwestycjach w bezpieczeństwo często podejmowane są bez uprzedniego określenia, czy rzeczywiście adresują one kluczowe zagrożenia dla organizacji.

Zmiany regulacyjne, w tym dyrektywa NIS2 oraz nowelizacja Ustawy o Krajowym Systemie Cyberbezpieczeństwa, wprowadzają w tym obszarze istotną zmianę podejścia. Nie chodzi wyłącznie o nowe wymagania formalne, lecz o konieczność systemowego i udokumentowanego podejścia do analizy ryzyka.

Od 3 kwietnia 2025 roku rozpoczął się 12-miesięczny okres na dostosowanie się do nowych regulacji. W tym czasie organizacje zobowiązane są nie tylko do wdrożenia odpowiednich środków bezpieczeństwa, ale przede wszystkim do posiadania rzetelnej, udokumentowanej analizy ryzyka, stanowiącej podstawę podejmowanych działań.

W praktyce oznacza to odejście od deklaratywnego podejścia („analiza ryzyka została wykonana”) na rzecz podejścia opartego na dowodach, metodyce i ciągłym doskonaleniu procesu.

Czym właściwie jest ryzyko i gdzie zaczyna się błąd?

Ryzyko powstaje wówczas, gdy zagrożenie może wykorzystać podatność i oddziaływać na aktywo mające określoną wartość dla organizacji. Choć definicja ta może wydawać się akademicka, w praktyce stanowi bardzo operacyjny model pracy z bezpieczeństwem.

Zagrożenia mają charakter konkretny i mierzalny. Mogą to być działania wyspecjalizowanych grup APT wymierzonych w infrastrukturę krytyczną, kampanie ransomware skierowane do szpitali i jednostek samorządu terytorialnego, ukierunkowane ataki phishingowe na pracowników administracji czy ataki DDoS w okresach zwiększonego obciążenia usług publicznych. Do tej kategorii należą również zdarzenia wewnętrzne i losowe — świadome działania pracowników, nieumyślne błędy ludzkie, awarie zasilania czy zdarzenia naturalne, takie jak powodzie.

Podatności są równie konkretne i identyfikowalne. Obejmują m.in. nieaktualizowane systemy SCADA, przestarzałą infrastrukturę serwerową, brak segmentacji sieci między środowiskami IT i OT, współdzielone konta uprzywilejowane, brak uwierzytelniania wieloskładnikowego w systemach wrażliwych oraz niewystarczający poziom świadomości pracowników.

Aktywa nie ograniczają się wyłącznie do infrastruktury technicznej. W sektorze energetycznym są to systemy sterowania przepływem energii, natomiast w administracji publicznej — rejestry mieszkańców, systemy obsługi świadczeń, platformy e-usług, korespondencja elektroniczna oraz reputacja instytucji. Istotnym aktywem pozostaje również dostępność usług publicznych, która często ma bezpośredni wpływ na funkcjonowanie państwa i obywateli.

Nieodzownym elementem analizy ryzyka jest kontekst, który bywa najczęściej pomijany. Czynniki takie jak sytuacja geopolityczna, sezon grzewczy, okres wyborczy czy cykle składania wniosków o świadczenia istotnie wpływają na poziom i charakter ryzyka. Ten sam system może podlegać zupełnie innemu profilowi ryzyka w zależności od czasu i otoczenia operacyjnego.

Podstawowy błąd pojawia się w momencie, gdy powyższe elementy analizowane są w oderwaniu od siebie. Ocena zagrożeń bez odniesienia do konkretnych aktywów lub inwestowanie w rozwiązania technologiczne bez uwzględnienia rzeczywistych podatności prowadzi do pozornego podnoszenia poziomu bezpieczeństwa. Przykładem może być wdrażanie zaawansowanych narzędzi detekcyjnych przy jednoczesnym utrzymywaniu krytycznych systemów na nieaktualnej infrastrukturze z nadmiernymi uprawnieniami dostępu.

Zarządzanie ryzykiem nie równa się wdrażaniu zabezpieczeń

Jest to jeden z najczęściej błędnie rozumianych aspektów całej dyscypliny.

Zarządzanie ryzykiem polega przede wszystkim na identyfikacji obszarów, które mają rzeczywisty wpływ na funkcjonowanie organizacji — tych, których zakłócenie może prowadzić do przerwania ciągłości operacyjnej lub istotnego ograniczenia świadczenia kluczowych usług. Obejmuje to zarówno wskazanie systemów krytycznych, jak i określenie realistycznych scenariuszy ich niedostępności lub kompromitacji.

Dobór zabezpieczeń technicznych i organizacyjnych powinien być konsekwencją tej analizy, a nie jej substytutem.

W praktyce często obserwuje się sytuacje, w których inwestycje w bezpieczeństwo nie są powiązane z rzeczywistym profilem ryzyka. Przykładowo, przedsiębiorstwo energetyczne wdraża zaawansowane systemy monitorowania sieci automatyki przemysłowej, jednocześnie utrzymując niezarządzane zdalne dostępy dla podmiotów serwisowych. W administracji publicznej spotykane są przypadki wdrożenia nowoczesnych rozwiązań klasy EDR przy jednoczesnym funkcjonowaniu kluczowych systemów na przestarzałej infrastrukturze z nadmiernymi uprawnieniami dostępu.

W obu przypadkach poniesione zostały nakłady inwestycyjne, jednak rzeczywista ekspozycja na ryzyko nie uległa istotnemu ograniczeniu.

W praktyce ograniczona liczba ryzyk związanych z kluczowymi usługami, systemami krytycznymi oraz łańcuchem dostaw, odpowiada za zdecydowaną większość ekspozycji organizacji na incydenty cyberbezpieczeństwa. Pozostałe ryzyka mają charakter marginalny.

Rzetelna analiza ryzyka pozwala na ich rozróżnienie oraz właściwe ukierunkowanie działań zabezpieczających.

Proces krok po kroku

Nie ma potrzeby tworzenia metodyki od podstaw. Istnieją sprawdzone i powszechnie stosowane standardy, takie jak ISO 31000, ISO 27005 oraz NIST SP 800-30, które wzajemnie się uzupełniają. W warunkach polskich i europejskich zasadne jest oparcie ram zarządczych na standardach ISO, natomiast w zakresie szczegółowej analizy ryzyka, katalogów zagrożeń i scenariuszy warto korzystać z podejść rozwijanych przez NIST.

Proces analizy ryzyka można uporządkować w pięciu etapach:

Etap 1: Przygotowanie
Należy powołać interdyscyplinarny zespół obejmujący przedstawicieli IT, OT (jeśli dotyczy), obszarów biznesowych lub merytorycznych, compliance oraz bezpieczeństwa. Kluczowe jest określenie zakresu analizy oraz zdefiniowanie wspólnej skali oceny prawdopodobieństwa i wpływu. Brak jednolitej skali prowadzi do niespójnych wyników i utrudnia podejmowanie decyzji.

Etap 2: Identyfikacja
Etap ten obejmuje inwentaryzację infrastruktury, aplikacji, systemów, procesów oraz danych. W administracji publicznej będą to m.in. rejestry mieszkańców, systemy podatkowe, systemy obsługi świadczeń, platformy e-usług oraz systemy obiegu dokumentów. W sektorze przemysłowym — systemy SCADA, DMS, systemy pomiarowe czy systemy klasy CRM. Równolegle należy zidentyfikować zagrożenia (np. na podstawie raportów CERT/CSIRT, producentów) oraz podatności wynikające z audytów, skanów bezpieczeństwa i historii incydentów.

Etap 3: Analiza i ocena ryzyka
Dla realistycznych scenariuszy (nie wszystkich możliwych, lecz tych uzasadnionych operacyjnie) określa się prawdopodobieństwo ich wystąpienia oraz potencjalny wpływ. Przykładowo: utrata kontroli nad elementem infrastruktury krytycznej w energetyce lub wielodniowa niedostępność systemu świadczeń w administracji. Wynikiem jest uporządkowany ranking ryzyk, który umożliwia identyfikację tych nieakceptowalnych z punktu widzenia ciągłości działania oraz zobowiązań wobec klientów lub obywateli.

Etap 4: Planowanie i mitygacja
Dla ryzyk o najwyższym priorytecie należy dobrać adekwatne środki zaradcze — zarówno techniczne, jak i organizacyjne. Dobór ten powinien wynikać bezpośrednio z poziomu ryzyka, a nie z dostępności technologii czy aktualnych trendów rynkowych. Przykładowe działania obejmują segmentację sieci OT, wdrożenie bezpiecznych mechanizmów zdalnego dostępu dla podmiotów zewnętrznych, wzmocnienie mechanizmów uwierzytelniania oraz testowanie procedur odtwarzania po incydencie.

Etap 5: Monitoring i przegląd
Analiza ryzyka powinna podlegać regularnemu przeglądowi (co najmniej raz w roku) oraz każdorazowo w przypadku istotnych zmian technologicznych, organizacyjnych lub regulacyjnych. Przykłady takich zmian to wdrożenie nowych systemów e-usług, integracja rejestrów, migracja do środowisk chmurowych czy implementacja nowych obowiązków regulacyjnych. Każda z nich wpływa na profil ryzyka i powinna inicjować jego ponowną ocenę.

Dla organizacji przeprowadzającej analizę ryzyka po raz pierwszy pełny proces trwa zazwyczaj około trzech miesięcy. Kolejne aktualizacje są znacząco mniej czasochłonne, o ile proces został właściwie ustrukturyzowany i udokumentowany.

Co konkretnie wymaga NIS2 i UKSC?

We wszystkich regulacjach z obszaru cyberbezpieczeństwa punktem wyjścia pozostaje szacowanie ryzyka. Dyrektywa NIS2 oraz nowelizacja Ustawy o Krajowym Systemie Cyberbezpieczeństwa nie stanowią w tym zakresie wyjątku.

Regulacje te wprowadzają cztery kluczowe obowiązki:

Po pierwsze — systematyczną analizę ryzyka wystąpienia incydentów bezpieczeństwa oraz zarządzanie tym ryzykiem.

Po drugie — zapewnienie, że analizy i oceny ryzyka dla systemów IT (a w uzasadnionych przypadkach również OT) są udokumentowane, aktualizowane i adekwatne do zmieniającego się otoczenia.

Po trzecie — stosowanie podejścia „all hazards”, obejmującego nie tylko zagrożenia cybernetyczne, ale również błędy operacyjne, awarie techniczne, działania wewnętrzne (umyślne i nieumyślne), zdarzenia fizyczne oraz szeroko rozumiany czynnik ludzki.

Po czwarte — dostosowanie poziomu zabezpieczeń technicznych i organizacyjnych do zidentyfikowanego poziomu ryzyka, a nie do checklist normatywnych czy praktyk rynkowych stosowanych przez inne podmioty.

W ramach wymaganej dokumentacji należy uwzględnić cztery podstawowe atrybuty bezpieczeństwa informacji: dostępność, poufność, integralność oraz autentyczność.

Istotnym elementem regulacji jest również zarządzanie ryzykiem w łańcuchu dostaw, które zostało wyraźnie zaakcentowane zarówno w NIS2, jak i w nowelizacji UKSC. W praktyce najsłabszym ogniwem bywa podmiot zewnętrzny — często niewielki dostawca lub podwykonawca posiadający szerokie uprawnienia dostępu, nad którymi brak jest skutecznego nadzoru.

Podmioty objęte regulacją zobowiązane są do formalnego egzekwowania od dostawców i podwykonawców odpowiednich standardów w zakresie zarządzania ryzykiem, w tym przeprowadzania analiz ryzyka, wdrażania działań mitygacyjnych oraz raportowania incydentów.

Zjawisko to ma charakter systemowy — ryzyko w łańcuchu dostaw może propagować się w obu kierunkach, wpływając zarówno na organizację, jak i jej partnerów.

Ile kosztuje bezczynność?

To pytanie warto zadawać wprost, ponieważ jest to język zrozumiały dla kadry zarządzającej – zarządów spółek energetycznych, przedstawicieli administracji publicznej oraz dyrektorów podmiotów leczniczych.

Mowa o realnych konsekwencjach: wielodniowych przestojach operacyjnych, braku możliwości wystawiania faktur, niemożności terminowego rozpatrywania wniosków i wydawania decyzji administracyjnych czy paraliżu szpitala w wyniku ataku ransomware w okresie zwiększonego obciążenia. Do tego dochodzą presja medialna, utrata zaufania interesariuszy oraz potencjalne sankcje regulacyjne.

Ryzyko istnieje niezależnie od tego, czy jest mierzone i analizowane. Jednak dopiero jego właściwa identyfikacja i osadzenie w kontekście konkretnej organizacji umożliwia świadome zarządzanie.

Analiza ryzyka nie jest działaniem jednorazowym ani dokumentem tworzonym wyłącznie na potrzeby formalne. Stanowi proces ciągły, który pozwala weryfikować, czy podejmowane inwestycje w obszarze bezpieczeństwa rzeczywiście odpowiadają na najistotniejsze zagrożenia dla organizacji.

---

Tomasz Matuła – ekspert w obszarze technologii, cyberbezpieczeństwa i transformacji cyfrowej, wieloletni lider IT w Orange Polska i Telekomunikacji Polskiej. Doradca zarządów i organizacji jako Technology & Business Trusted Advisor, współtwórca programów rozwojowych CIONET Polska i Digital Excellence. Specjalizuje się w budowie strategii bezpieczeństwa, zarządzaniu infrastrukturą ICT oraz wspieraniu liderów IT w skutecznym łączeniu technologii z celami biznesowymi. Prelegent, mentor i aktywny uczestnik środowiska CIO w Polsce.