Jak Wdrożyć Zarządzanie Ryzykiem I Nadzór Zgodnie Z Art. 21 Dyrektywy NIS2

Dlaczego zarządzanie ryzykiem stanowi fundament zgodności z NIS2

Dyrektywa NIS2 (Directive (EU) 2022/2555) nakłada na podmioty z sektorów krytycznych i ważnych obowiązek przyjęcia kompleksowego podejścia do zarządzania ryzykiem cyberbezpieczeństwa. Artykuł 21 tej dyrektywy wymaga wdrożenia adekwatnych i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych w celu zabezpieczenia sieci i systemów informatycznych oraz ograniczenia wpływu incydentów.

Co istotne, NIS2 przenosi odpowiedzialność za cyberbezpieczeństwo również na najwyższe szczeble zarządzania – zarząd i kierownictwo muszą sprawować nadzór nad bezpieczeństwem i mogą ponosić odpowiedzialność w razie zaniedbań. W niniejszym artykule omawiamy, jak praktycznie wdrożyć zarządzanie ryzykiem i nadzór zgodnie z art. 21 NIS2 – krok po kroku, w oparciu o formalne wymagania dyrektywy oraz najlepsze praktyki rynkowe.

Ten artykuł jest częścią serii NIS2 – Jak być zgodnym, w której krok po kroku omawiamy wymagania dyrektywy NIS2, zarządzanie ryzykiem, raportowanie incydentów i wdrożenie zgodności w organizacjach.

Wymagania art. 21 dyrektywy NIS2 w zakresie zarządzania ryzykiem

Artykuł 21 NIS2 jasno określa minimalny zakres obszarów, które powinny zostać objęte działaniami zarządzania ryzykiem cyberbezpieczeństwa. Zgodnie z ust. 2 tego artykułu, każde objęte dyrektywą przedsiębiorstwo musi co najmniej wdrożyć następujące elementy:

• Politykę analizy ryzyka i bezpieczeństwa systemów informatycznych – formalne dokumenty i procedury określające, jak identyfikować i oceniać ryzyka oraz jak zabezpieczać kluczowe systemy IT.
• Procedury obsługi incydentów – gotowe mechanizmy reagowania na incydenty bezpieczeństwa (Incident handling), w tym wykrywanie, eskalacja, raportowanie i rozwiązywanie incydentów.
• Plan ciągłości działania i zarządzanie kryzysowe – rozwiązania zapewniające utrzymanie lub szybkie przywrócenie kluczowych usług w razie zakłóceń (np. regularne kopie zapasowe, odtwarzanie awaryjne, plany awaryjne na wypadek sytuacji kryzysowych).
• Bezpieczeństwo łańcucha dostaw – zarządzanie ryzykiem związanym z dostawcami i partnerami (wymóg oceny podatności i jakości zabezpieczeń u dostawców oraz uwzględnianie wyników wspólnych ocen ryzyka łańcucha dostaw).
• Bezpieczeństwo przy nabywaniu, rozwoju i utrzymaniu systemów – uwzględnianie kwestii bezpieczeństwa w cyklu życia oprogramowania i infrastruktury (secure by design), w tym zarządzanie podatnościami i procedury zgłaszania/ujawniania podatności.
• Ocena skuteczności środków bezpieczeństwa – polityki i procedury regularnej weryfikacji, czy zastosowane środki zarządzania ryzykiem są efektywne (np. wewnętrzne audyty zgodności, testy penetracyjne, przeglądy zabezpieczeń).
• Podstawowa cyberhigiena i szkolenia – programy podnoszenia świadomości pracowników oraz stosowanie podstawowych dobrych praktyk (aktualizacje, silne hasła, antywirusy itp.) w codziennym użytkowaniu systemów.
• Polityki stosowania kryptografii – wytyczne dotyczące używania mechanizmów kryptograficznych (np. szyfrowanie transmisji i danych spoczynkowych, zarządzanie kluczami) odpowiednio do potrzeb organizacji.
• Bezpieczeństwo zasobów ludzkich i kontrola dostępu – środki takie jak weryfikacja personelu, procedury bezpiecznego zatrudniania/zwalniania, polityki zarządzania dostępami (zasada najmniejszych uprawnień, przeglądy uprawnień) oraz zarządzanie aktywami (ewidencja i ochrona urządzeń oraz informacji).
• Uwierzytelnianie wieloskładnikowe i bezpieczna komunikacja – gdzie to właściwe, wdrożenie uwierzytelniania multi-factor (MFA) lub ciągłego, a także zabezpieczonych kanałów komunikacji (szyfrowane połączenia głosowe, tekstowe, wideo) w tym systemów alarmowej komunikacji wewnętrznej.

Powyższe wymagania wskazują, że zarządzanie ryzykiem zgodne z NIS2 jest procesem holistycznym, obejmującym zarówno aspekty techniczne (narzędzia i infrastruktura), jak i proceduralne oraz organizacyjne (polityki, świadomość, nadzór). Aby je spełnić, organizacja powinna ustanowić spójny system zarządzania bezpieczeństwem informacji, najlepiej zintegrowany z istniejącymi standardami (np. ISO 27001 dla systemu zarządzania bezpieczeństwem czy ISO 31000 dla zarządzania ryzykiem). W kolejnych sekcjach opisujemy, jak zbudować taki system w praktyce – od cyklu oceny ryzyka, przez wdrożenie odpowiednich zabezpieczeń, po mechanizmy nadzoru i ciągłego doskonalenia.

Proces zarządzania ryzykiem – identyfikacja, ocena i traktowanie ryzyka

Skuteczne zarządzanie ryzykiem rozpoczyna się od systematycznej oceny ryzyka. Zgodnie z NIS2 nie może to być jednorazowe ćwiczenie – wymagane jest podejście ciągłe, z regularnym monitorowaniem i przeglądami poziomu ryzyka. Organizacja powinna stale dostosowywać środki bezpieczeństwa do zmieniającego się krajobrazu zagrożeń. Innymi słowy, cyberbezpieczeństwo ma być oparte na ryzyku – zastosowane zabezpieczenia muszą być proporcjonalne do oszacowanego poziomu ryzyka dla poszczególnych usług, systemów i danych.

Standardowy proces oceny ryzyka zwykle obejmuje następujące kroki:

1. Identyfikacja aktywów – zidentyfikowanie krytycznych zasobów organizacji: kluczowych systemów, aplikacji, baz danych, urządzeń oraz informacji, których poufność, integralność lub dostępność jest kluczowa dla działania firmy.
2. Identyfikacja zagrożeń – sporządzenie listy potencjalnych zagrożeń, które mogą wpłynąć na te aktywa. Mogą to być zagrożenia cybernetyczne (np. malware, ransomware, ataki DDoS, ataki phishingowe) oraz zagrożenia fizyczne czy błędy ludzkie.
3. Identyfikacja podatności – wskazanie słabych punktów i luk w zabezpieczeniach posiadanych aktywów. Podatności mogą wynikać z nieaktualnego oprogramowania, błędnej konfiguracji, braku procedur lub słabych zabezpieczeń fizycznych.
4. Ocena skutków (impact) – oszacowanie wpływu każdego zidentyfikowanego ryzyka, gdyby się zmaterializowało. Należy rozważyć wpływ finansowy, operacyjny, prawny oraz reputacyjny potencjalnego incydentu.
5. Ocena prawdopodobieństwa – oszacowanie, jak jest prawdopodobne wystąpienie danego zagrożenia, biorąc pod uwagę dostępne dane historyczne, trendy rynkowe oraz informacje wywiadu o zagrożeniach.
6. Szacowanie poziomu ryzyka – określenie poziomu ryzyka poprzez połączenie oceny skutków i prawdopodobieństwa. Często poziomy ryzyka kategoryzuje się jakościowo (np. niski, średni, wysoki) lub przypisuje się im wartości na macierzy ryzyka.
7. Postępowanie z ryzykiem – podjęcie decyzji, co zrobić z każdym ryzykiem. Typowe opcje to: redukcja ryzyka (poprzez wdrożenie odpowiednich zabezpieczeń), akceptacja ryzyka (jeśli jest dostatecznie niskie), przeniesienie ryzyka (np. poprzez ubezpieczenie lub outsourcing) lub unikanie ryzyka (zaprzestanie działania związanego z ryzykiem).

Po przejściu tych kroków organizacja powinna uzyskać mapę ryzyk – uporządkowany obraz własnego krajobrazu zagrożeń i słabych punktów, co pozwala efektywnie priorytetyzować działania i zasoby na najpoważniejsze ryzyka. Ważne jest udokumentowanie całego procesu (np. w formie raportu z analizy ryzyka), gdyż organy nadzorcze mogą wymagać wykazania, że ocena ryzyka była przeprowadzona rzetelnie i regularnie aktualizowana.

Przykład: Dla zobrazowania – wyobraźmy sobie, że podmiotem objętym NIS2 jest szpital (sektor opieki zdrowotnej). Jako krytyczne aktywo zidentyfikowano system elektronicznej dokumentacji pacjentów. W analizie ryzyka rozważono scenariusz ataku ransomware na ten system. Zidentyfikowano podatności: brak aktualnych patchy w serwerach i zbyt szerokie dostępy zdalne. Potencjalny wpływ oceniono jako bardzo wysoki, ponieważ zaszyfrowanie danych pacjentów sparaliżuje ciągłość opieki i może zagrozić życiu pacjentów. Prawdopodobieństwo również uznano za wysokie, biorąc pod uwagę nasilone kampanie ransomware wymierzone w służbę zdrowia. W efekcie ryzyko sklasyfikowano jako “wysokie”, co wymaga podjęcia działań. Szpital wdrożył więc dodatkowe środki: segmentację sieci (oddzielenie sieci szpitalnej od sieci administracyjnej), rygorystyczne mechanizmy kontroli dostępu do systemu, regularne kopie zapasowe offline oraz przyspieszony harmonogram aktualizacji oprogramowania. Ten przykład ilustruje podejście, jakie powinna przyjąć organizacja – poważne ryzyka muszą skutkować konkretnymi planami redukcji ryzyka i inwestycjami w zabezpieczenia.

W przeprowadzeniu profesjonalnej oceny ryzyka pomocne są uznane standardy i metodyki. Dyrektywa NIS2 nie narzuca jednego konkretnego standardu, ale rekomenduje korzystanie z aktualnej wiedzy i standardów europejskich lub międzynarodowych. W praktyce wiele organizacji opiera proces zarządzania ryzykiem na ramach takich jak: ISO/IEC 27005 (dedykowana norma zarządzania ryzykiem bezpieczeństwa informacji), NIST SP 800-30 (szczegółowa metodyka oceny ryzyka cyber), czy wytyczne ENISA dostosowane do sektorów objętych dyrektywą. Niezależnie od wyboru metodologii kluczowe jest, aby proces był udokumentowany, powtarzalny i dostosowany do wielkości oraz kontekstu organizacji.

Narzędzia i metody wspierające ocenę ryzyka

Przy wdrażaniu oceny ryzyka warto wykorzystać dostępne narzędzia automatyzujące część zadań i dostarczające obiektywnych danych o podatnościach i zagrożeniach. Przykładowe praktyczne podejścia i narzędzia to:

• Skanowanie podatności – regularne skany bezpieczeństwa infrastruktury i aplikacji za pomocą narzędzi typu Nessus, OpenVAS, Qualys itp., aby wykryć znane podatności i luki w konfiguracji zanim wykorzystają je atakujący.
• Audyty konfiguracji – porównywanie konfiguracji serwerów, urządzeń sieciowych i baz danych z dobrymi praktykami (np. benchmarki CIS). Dostępne są automatyczne narzędzia jak CIS-CAT, które sprawdzają zgodność konfiguracji z wzorcami bezpieczeństwa i generują raporty zgodności.
• Wywiad o zagrożeniach (Threat Intelligence) – śledzenie aktualnych informacji o kampaniach ataków, nowych podatnościach, technikach i TTP (Tactics, Techniques, Procedures) stosowanych przez cyberprzestępców. Włączenie feedów threat intelligence (np. bazy MISP, informacje od CERT/CSIRT, serwisy typu IBM X-Force) do procesów bezpieczeństwa (np. integracja z systemem SIEM) pozwala lepiej oceniać prawdopodobieństwo zagrożeń i szybko reagować na nowe ryzyka.
• Inwentaryzacja zasobów – utrzymywanie aktualnego rejestru sprzętu, oprogramowania i danych. Narzędzia CMDB (Configuration Management Database) lub skanery sieciowe mogą automatycznie wykrywać i katalogować urządzenia oraz usługi w naszej sieci. Pełna wiedza o tym, co chronimy, jest fundamentem rzetelnej analizy ryzyka.

Wdrożenie powyższych mechanizmów daje solidne podstawy do identyfikacji i kwantyfikacji ryzyka. Na tej bazie można przejść do kolejnego etapu, czyli doboru i implementacji odpowiednich środków bezpieczeństwa, które to ryzyko zredukują do akceptowalnego poziomu.

Wdrożenie odpowiednich środków bezpieczeństwa (risk treatment)

Po zidentyfikowaniu i ocenieniu ryzyk organizacja staje przed kluczowym zadaniem: wyborem i wdrożeniem środków bezpieczeństwa adekwatnych do tych ryzyk. Dyrektywa NIS2 w art. 21 mocno akcentuje, że bezpieczeństwo ma być proporcjonalne do ryzyka oraz uwzględniać najlepsze praktyki i stan wiedzy w zakresie zabezpieczeń. Poniżej przedstawiamy główne domeny zabezpieczeń, które powinny znaleźć się w planie postępowania z ryzykiem, wraz z przykładami konkretnych mechanizmów:

• Segmentacja sieci i kontrola dostępu – Podzielenie infrastruktury na odseparowane segmenty (strefy zaufania) tak, aby ograniczyć ruch pomiędzy nimi. Krytyczne systemy powinny być odizolowane od mniej istotnych środowisk, co utrudni atakującym poruszanie się po sieci (lateral movement). Kluczowe jest wdrożenie silnej kontroli dostępu: polityki IAM (Identity and Access Management) obejmujące zasadę najmniejszych uprawnień, nadawanie dostępów według roli oraz ich regularny przegląd, a także wieloskładnikowe uwierzytelnianie dla dostępu do wrażliwych systemów.
• Zabezpieczenie punktów końcowych (endpoint security) – Wszystkie stacje robocze, laptopy, serwery i urządzenia mobilne powinny być chronione przez aktualne oprogramowanie zabezpieczające: antywirus/antymalware, firewalle hostowe, a w miarę możliwości zaawansowane systemy EDR (Endpoint Detection & Response) do wykrywania nietypowych zachowań na hostach. Niezwykle ważne jest regularne aktualizowanie i łatanie systemów operacyjnych oraz aplikacji – wdrożenie procesu patch management pozwoli na bieżąco usuwać znane podatności zanim zostaną wykorzystane.
• Szyfrowanie i bezpieczna komunikacja – Dane krytyczne powinny być szyfrowane zarówno w spoczynku, jak i w tranzycie. W praktyce oznacza to korzystanie z silnych protokołów (np. TLS 1.2/1.3 z bezpiecznymi pakietami szyfrów, takich jak AES-256) do komunikacji sieciowej oraz szyfrowanie wrażliwych danych przechowywanych na dyskach, w bazach czy w chmurze. Należy również eliminować przestarzałe, niezabezpieczone protokoły (np. Telnet, FTP na rzecz ich szyfrowanych odpowiedników SSH, SFTP). W ramach komunikacji wewnętrznej i zdalnej pracy – wdrożyć VPN lub inne szyfrowane kanały oraz zabezpieczone systemy komunikacji alarmowej, co wprost wynika z art. 21 lit. j dyrektywy NIS2.
• Monitorowanie i detekcja zagrożeń – Nie sposób zarządzać ryzykiem bez zdolności do ciągłego monitorowania środowiska i wykrywania incydentów. Standardem staje się wdrożenie scentralizowanego systemu SIEM (Security Information and Event Management), takiego jak Splunk, QRadar czy otwartoźródłowy Wazuh, który gromadzi logi z różnych źródeł i generuje alerty korelując zdarzenia. Dodatkowo zaleca się posiadanie systemu IDS/IPS (Intrusion Detection/Prevention System) analizującego ruch sieciowy pod kątem podejrzanych wzorców (popularne są np. Snort, Suricata). Te narzędzia, odpowiednio skonfigurowane (reguły detekcji, minimalizacja false positives), pozwalają na wczesne wykrycie potencjalnego ataku zanim spowoduje poważne szkody.
• Reagowanie na incydenty i ciągłość działania – Nawet najlepsze zabezpieczenia nie dają 100% gwarancji uniknięcia incydentu, dlatego krytyczne jest posiadanie Planu Reagowania na Incydenty (Incident Response Plan) oraz Planu Ciągłości Działania (Business Continuity/Disaster Recovery Plan). Plan IR powinien precyzować role i procedury na wypadek różnych scenariuszy incydentów – kto wchodzi w skład zespołu reagowania, jak przebiega eskalacja, jakie działania podjąć aby ograniczyć skalę ataku itp.. Podobnie plan ciągłości działania określa priorytetowe procesy biznesowe i maksymalne czasy ich przywrócenia (RTO/RPO), procedury odtworzenia systemów z kopii zapasowych itp. Regularne testy (np. testy odtwarzania backupów, ćwiczenia typu table-top dla zespołu IR) zapewniają, że w sytuacji kryzysowej organizacja zadziała sprawnie. Art. 21 NIS2 wymaga, by incydenty zgłaszać właściwym organom w określonych ramach czasowych, dlatego procedury muszą uwzględniać również szybkie powiadamianie CSIRT/regulatora o incydencie istotnym.
• Architektura Zero Trust – Coraz więcej organizacji dąży do modelu Zero Trust, co oznacza odejście od tradycyjnej architektury zaufanej sieci wewnętrznej. W modelu Zero Trust nie ufa się żadnemu ruchowi ani użytkownikowi z definicji – każdy dostęp musi być zweryfikowany i autoryzowany, a zasoby są mocno izolowane. Implementacja Zero Trust obejmuje m.in. mikrosegmentację sieci (dzielenie sieci na bardzo małe, izolowane segmenty), ciągłą weryfikację tożsamości i stanu urządzeń przy każdej próbie dostępu oraz dokładne logowanie i analizę zachowań w sieci. Podejście to jest zgodne z duchem NIS2, gdyż znacząco utrudnia przemieszczanie się atakującego po sieci i ogranicza zasięg potencjalnego incydentu.

Powyższe obszary zabezpieczeń powinny zostać uwzględnione w planie działania po ocenie ryzyka. NIS2 pozostawia swobodę co do szczegółowej realizacji poszczególnych środków – ważne, aby wykazać, że dla zidentyfikowanych ryzyk zastosowano rozwiązania redukujące ryzyko do akceptowalnego poziomu. Dla udokumentowania zgodności zaleca się sporządzenie planu zarządzania ryzykiem lub planu poprawy bezpieczeństwa, który mapuje wymagania dyrektywy na konkretne inicjatywy (np. “wymóg art. 21 ust.2 (d) – działania: przegląd dostawców pod kątem bezpieczeństwa, dodanie klauzul bezpieczeństwa do umów, wdrożenie procedury due diligence dostawców”). Taki plan ułatwi też komunikację z zarządem i interesariuszami.

Nadzór i odpowiedzialność kierownictwa

Wdrożenie procesów i narzędzi cyberbezpieczeństwa musi iść w parze z ustanowieniem odpowiednich struktur nadzoru i rozliczalności. Jedną z kluczowych zmian, jakie wprowadza NIS2, jest przesunięcie ciężaru odpowiedzialności na najwyższy poziom zarządzania organizacją. Cyberbezpieczeństwo przestaje być postrzegane jako wyłącznie problem działu IT – dyrektywa wymaga, by było traktowane jako kwestia strategiczna, za którą ostatecznie odpowiada zarząd. W wielu krajach planuje się przepisy nakładające osobistą odpowiedzialność na członków zarządu za poważne zaniedbania w obszarze bezpieczeństwa. Dlatego firmy muszą zapewnić nie tylko wdrożenie środków technicznych, ale też jasne mechanizmy nadzoru – od poziomu rady nadzorczej po codzienny monitoring zgodności z procedurami.

Kluczowe elementy nadzoru zgodnego z NIS2 obejmują:

• Zaangażowanie zarządu – Zarząd (lub najwyższe kierownictwo, tzw. management body) powinien aktywnie uczestniczyć w przeglądzie stanu bezpieczeństwa organizacji. W praktyce oznacza to regularne raportowanie o ryzykach i incydentach na posiedzeniach zarządu, uwzględnianie cyberbezpieczeństwa przy podejmowaniu decyzji strategicznych, a także zapewnienie adekwatnego budżetu i zasobów na bezpieczeństwo. Zarząd powinien również formalnie zatwierdzać kluczowe polityki bezpieczeństwa i strategię cyberbezpieczeństwa, aby nadać im odpowiednią rangę w organizacji.
• Raportowanie ryzyk w sposób zrozumiały dla zarządu – CISO (Chief Information Security Officer) lub inna osoba odpowiedzialna za bezpieczeństwo powinna dostarczać zarządowi regularne, merytoryczne raporty o stanie bezpieczeństwa. Raporty te powinny przedstawiać w skondensowanej formie najważniejsze metryki: zidentyfikowane istotne ryzyka i trendy (np. wzrost liczby incydentów określonego typu), podjęte działania i ich skuteczność, poziom zgodności z wymaganiami itp. Taka transparentność ułatwia zarządowi podejmowanie świadomych decyzji i rozliczanie realizacji działań bezpieczeństwa.
• Jasno zdefiniowane role i struktura – Organizacja powinna ustanowić strukturę zarządzania bezpieczeństwem z wyraźnym podziałem ról i odpowiedzialności, aby uniknąć luk kompetencyjnych lub przeciwnie – zbędnych nakładających się funkcji. Dobrym rozwiązaniem jest powołanie dedykowanej roli CISO (lub równoważnej) ulokowanej wysoko w strukturze, raportującej bezpośrednio do członka zarządu (np. do CTO, COO lub CEO). Ponadto zaleca się utworzenie komitetu ds. bezpieczeństwa informacji lub ryzyka operacyjnego, który skupia przedstawicieli różnych działów: IT, bezpieczeństwa, prawnego, zgodności, ryzyka, a nawet HR czy zakupów. Taki komitet może periodycznie (np. co miesiąc lub kwartał) omawiać status inicjatyw bezpieczeństwa, analizować poważne incydenty i zatwierdzać kluczowe decyzje (np. wybór dostawcy systemu bezpieczeństwa, akceptacja ryzyka pozostawionego). Ważna jest także współpraca międzydziałowa – bezpieczeństwo to nie tylko domena IT, ale też m.in. działu personalnego (rekrutacje i szkolenia), działu zakupów (wymagania bezpieczeństwa wobec dostawców), działu prawnego (zgodność z regulacjami).

Przykładowy podział ról – macierz RASCI

Poniżej przedstawiono uproszczony przykład macierzy RASCI dla wybranych obszarów zarządzania ryzykiem i bezpieczeństwem. Macierz RASCI pozwala zdefiniować, kto w organizacji Realizuje dane zadanie (Responsible), kto jest Odpowiedzialny końcowo / zatwierdza (Accountable), kto Wspiera (Support), kto jest Konsultowany (Consulted), a kto tylko Informowany (Informed) o danym zagadnieniu:

Obszar / zadanie	Zarząd	CISO	Zespół IT	Dział ryzyka/zgodności
Strategia i polityki bezpieczeństwa (ustalenie i zatwierdzanie)	A	R	C	C
Identyfikacja i analiza ryzyk	I	A	S	R
Wdrażanie zabezpieczeń technicznych	I	A	R	C
Monitorowanie oraz audyt zgodności	I	A	S	R
Reagowanie na incydenty i ciągłość działania	I	A	R	C
Szkolenia i budowanie świadomości	S	A	I	R

Legenda: R – Responsible (Wykonawca zadania), A – Accountable (Odpowiada za wyniki, zatwierdza), S – Support (Wspiera wykonanie), C – Consulted (Dostarcza informacji, jest konsultowany), I – Informed (Otrzymuje informacje).

Powyższa macierz obrazuje, że np. zarząd zatwierdza strategię i polityki bezpieczeństwa (A), ale ich przygotowanie leży po stronie CISO (R) przy udziale innych działów (konsultacje z IT i ryzykiem). Za bieżące wdrażanie zabezpieczeń odpowiada zespół IT (R) nadzorowany przez CISO (A). Z kolei monitorowanie zgodności i audyty to domena działu ryzyka/zgodności (R), choć CISO pozostaje odpowiedzialny przed zarządem za wyniki (A). Reagowanie na incydenty operacyjnie realizuje zespół IT/security (R) z udziałem np. osób z ryzyka przy zgłaszaniu incydentu do organów (C), a CISO nadzoruje cały proces (A) i informuje zarząd o poważnych incydentach (zarząd w roli I). Wreszcie szkolenia i budowanie kultury bezpieczeństwa są prowadzone przez funkcję ryzyka/zgodności lub dedykowanych trenerów (R), przy czym CISO odpowiada za istnienie programu szkoleń (A), zarząd wspiera te działania przez zapewnienie środków i osobisty przykład (S), a wszyscy pracownicy – w tym zespół IT – są odbiorcami szkoleń (I jako informowani/uczestniczący).

Oczywiście rzeczywista struktura ról może się różnić w zależności od wielkości i specyfiki organizacji – ważne jednak, by nikt nie miał wątpliwości, kto za co odpowiada. Warto formalnie przypisać obowiązki związane z NIS2 do konkretnych stanowisk (np. w opisach stanowisk, w regulaminie organizacyjnym czy uchwale zarządu). Dyrektywa wymaga też, by kadra zarządzająca była odpowiednio przeszkolona i świadoma zagrożeń – dlatego członkowie zarządu powinni regularnie odbywać szkolenia z zarządzania ryzykiem cyber (w wielu krajach będzie to wprost wymagane przepisami implementującymi NIS2).

Elementem nadzoru jest również system polityk, procedur i mechanizmów kontrolnych, które zapewnią, że zasady bezpieczeństwa są przestrzegane na co dzień. Dobre praktyki to m.in.:

• Formalny proces zatwierdzania polityk – Nowe lub aktualizowane polityki bezpieczeństwa powinny przechodzić przez zatwierdzenie nie tylko przez dział bezpieczeństwa, ale też inne kluczowe działy (IT, prawny, HR) oraz ostatecznie przez kierownictwo wyższego szczebla. Można to usprawnić narzędziowo (workflow akceptacji polityk, repozytorium polityk z kontrolą wersji i historią zmian).
• Regularne przeglądy i aktualizacje polityk – Polityki nie mogą być statyczne. Należy ustalić ich przegląd (review) np. co 12 lub 24 miesiące, a także nadzwyczajne aktualizacje po wystąpieniu poważnych incydentów lub zmianie prawa/technologii. Każda polityka powinna mieć wyznaczonego właściciela (owner) odpowiedzialnego za jej aktualność. Dzięki temu organizacja jest w stanie szybko dostosować wewnętrzne regulacje do nowych wymogów lub zagrożeń.
• Monitoring przestrzegania zasad – Samo napisanie polityk to nie wszystko – trzeba sprawdzić, czy pracownicy faktycznie się do nich stosują. Niezbędne są mechanizmy kontrolne: od technicznych środków wymuszających polityki (np. system DLP blokujący wysyłkę poufnych danych na zewnątrz, reguły hardeningu wdrożone w konfiguracji systemów), po audyty wewnętrzne, testy penetracyjne i kontrole operacyjne. NIS2 kładzie nacisk na to, by wszelkie niezgodności były wykrywane i usuwane bez zbędnej zwłoki. Przykładowo, jeżeli polityka zabrania używania niezautoryzowanego oprogramowania, to powinna istnieć procedura okresowego skanowania stacji roboczych i usuwania wykrytych niezgodnych aplikacji. W razie stwierdzenia poważnego naruszenia zasad – musi zadziałać proces dyscyplinarny lub korygujący, nadzorowany przez określoną rolę lub komitet.
• Raportowanie zgodności i metryk – Mechanizmy nadzoru powinny dostarczać zarządowi i kadrze kierowniczej okresowych raportów z osiągnięcia zgodności (compliance) z NIS2. Raporty mogą zawierać np.: wyniki audytów (ilu wymogom już sprostaliśmy, a gdzie są luki), statystyki szkoleń (jaki % pracowników przeszkolono), metryki bezpieczeństwa (liczba incydentów, średni czas reakcji, poziom patchowania systemów itp.). Takie KPI bezpieczeństwa powiązane z celami biznesowymi zwiększają świadomość na szczycie organizacji i pozwalają lepiej zarządzać bezpieczeństwem jak każdym innym ryzykiem biznesowym.

Ciągły nadzór, audyt i doskonalenie po stronie organizacji

Zarządzanie ryzykiem to proces ciągły – osiągnięcie zgodności z NIS2 nie jest jednorazowym projektem, lecz wymaga stałego utrzymania i doskonalenia ustanowionych praktyk. Artykuł 21 wskazuje potrzebę ciągłego oceniania skuteczności wdrożonych środków (lit. f), co oznacza, że organizacja powinna zapętlić swój proces zarządzania ryzykiem w cykl planowania, działania, sprawdzania i poprawy (PDCA). W kontekście bezpieczeństwa można to zrealizować następująco:

• Plan (Planuj) – na podstawie przeglądów, audytów i wniosków z incydentów aktualizuj polityki, procedury oraz plany bezpieczeństwa. Ustal, jakie zmiany lub usprawnienia są potrzebne (np. nowa kontrola bezpieczeństwa, dodatkowe szkolenie, poprawka procesu reagowania).
• Do (Wykonaj) – wdrażaj zaplanowane zmiany i komunikuj je odpowiednim zespołom. Na tym etapie następuje realna poprawa: konfigurujesz nowe zabezpieczenia, aktualizujesz dokumentację, szkolisz personel z nowych procedur.
• Check (Sprawdź) – testuj i audytuj wprowadzone zmiany. Mogą to być dedykowane audyty zgodności, testy bezpieczeństwa, inspekcje czy nawet symulacje incydentów, aby zweryfikować, czy nowe środki działają skutecznie i czy osiągnięto zamierzony efekt (np. szybszy czas reakcji, zablokowanie danego wektora ataku itp.).
• Act (Działaj korygująco) – jeśli sprawdzenie ujawniło dalsze braki lub nowe słabości, dokonaj korekt. Jest to etap wyciągania wniosków – na podstawie danych z testów i audytów ulepszaj dalej proces. Następnie cykl powtarza się od Plan, zapewniając ciągłe doskonalenie.

Takie podejście gwarantuje, że bezpieczeństwo w organizacji nadąża za zmieniającymi się zagrożeniami i rozwojem samej organizacji (nowe systemy, usługi, zmiany kadrowe itp.). Co więcej, organy nadzorcze będą oczekiwać dowodów, że organizacja proaktywnie identyfikuje luki i je eliminuje w ramach ciągłego doskonalenia.

Warto tutaj podkreślić rolę regularnych audytów i testów bezpieczeństwa. NIS2 zaleca, aby podmioty objęte dyrektywą przeprowadzały regularne audyty wewnętrzne oraz były gotowe na audyty zewnętrzne (np. ze strony regulatora lub niezależnego podmiotu). Audyty wewnętrzne (np. kwartalne lub roczne) pozwalają ocenić, na ile przestrzegane są wewnętrzne polityki i procedury oraz czy spełniamy wymagania prawne. Z kolei audyt zewnętrzny daje obiektywne spojrzenie i często jest wymagany przez prawo lub zamawiających usługi. Przy audytach należy brać pod uwagę zarówno obszar techniczny (skany, testy systemów), jak i obszar proceduralny (dokumentacja, świadomość personelu). Wyniki audytów powinny trafiać do najwyższego kierownictwa – to wzmacnia rozliczalność i motywuje do usuwania stwierdzonych niezgodności.

Analogicznie, testy bezpieczeństwa (np. testy penetracyjne, red teaming, symulacje ataków) są cennym narzędziem sprawdzającym odporność organizacji. W ramach ciągłego doskonalenia każda poważniejsza zmiana w systemach (nowa aplikacja, duża aktualizacja, integracja z nowym dostawcą) powinna pociągać za sobą test bezpieczeństwa lub audyt ad-hoc, by upewnić się, że nie wprowadzono nowych podatności.

Nie można zapominać o lessons learned po incydentach. Każdy incydent bezpieczeństwa – nawet mały – to cenna lekcja. Organizacja powinna posiadać proces po-incydentowej analizy i raportowania. Analiza taka powinna odpowiedzieć na pytania: co się stało, dlaczego udało się to stać (przyczyna pierwotna, np. brak łatki, błąd człowieka, nieskuteczna procedura), jak przebiegła reakcja (co zadziałało, co wymaga poprawy) oraz jakie działania korygujące wdrożyć, by zapobiec podobnym incydentom w przyszłości. Wnioski z każdego incydentu należy przekuć na konkretne ulepszenia – czy to modyfikację procedur, dodatkowe szkolenia personelu, czy wdrożenie nowych zabezpieczeń. Dyrektywa NIS2 będzie wymagała od podmiotów wykazania, że wyciągają wnioski z incydentów i doskonalą swoje zabezpieczenia (np. poprzez przedstawienie raportów po incydentach podczas kontroli).

Podsumowanie

Wdrożenie zarządzania ryzykiem i nadzoru zgodnie z art. 21 dyrektywy NIS2 to złożone przedsięwzięcie, które wymaga zaangażowania wielu obszarów organizacji – od zespołów technicznych po najwyższe kierownictwo. Kluczowe jest przyjęcie podejścia systemowego: zaczynając od rzetelnej analizy ryzyka, poprzez wdrożenie szeregu środków bezpieczeństwa (polityki, procedury, narzędzia techniczne, mechanizmy reagowania), aż po ustanowienie struktury governance zapewniającej nadzór i ciągłe doskonalenie. NIS2 ustanawia pewien benchmark – wspólny minimalny poziom bezpieczeństwa dla kluczowych sektorów w całej UE – ale to od organizacji zależy, jak efektywnie te wymagania wdroży w praktyce.

Dla menedżerów, CISO i specjalistów ds. IT/cyberbezpieczeństwa oznacza to potrzebę bliskiej współpracy: zarząd musi rozumieć ryzyka i wspierać inicjatywy bezpieczeństwa, zaś zespoły techniczne muszą potrafić przekładać wymagania regulacyjne na konkretne plany i kontrole. Wymagania art. 21 nie są oderwane od dobrych praktyk – w dużej mierze pokrywają się z tym, co dobrze zarządzana organizacja już powinna robić w ramach np. ISO 27001 czy innych standardów. Nowością jest kategoryczny obowiązek i odpowiedzialność prawna: niewywiązanie się z tych wymogów może skutkować dotkliwymi karami finansowymi (do 10 mln euro lub 2% globalnych obrotów dla podmiotów kluczowych) oraz sankcjami administracyjnymi wobec kadry zarządzającej.

Podchodząc jednak pozytywnie – zgodność z NIS2 to nie tylko obowiązek, ale i szansa na podniesienie poziomu cyberodporności organizacji. Wdrożenie solidnego systemu zarządzania ryzykiem i nadzoru przełoży się na lepszą gotowość na ataki, mniejszą liczbę incydentów i szybsze reagowanie, a także większe zaufanie klientów i partnerów. Organizacja, która proaktywnie zarządza ryzykiem cyber, staje się bezpieczniejszym i bardziej wiarygodnym ogniwem ekosystemu cyfrowego – co jest nadrzędnym celem dyrektywy NIS2.

Spełnienie wymagań art. 21 NIS2 to zatem inwestycja w bezpieczeństwo i stabilność operacyjną. Kluczem jest potraktowanie tych działań nie jako jednorazowej checklisty, ale jako ciągłego procesu wpisanego w kulturę organizacji. W ten sposób można nie tylko uniknąć kar, ale przede wszystkim realnie wzmocnić swoją organizację przed współczesnymi zagrożeniami cyfrowymi, co z perspektywy biznesowej przyniesie długofalowe korzyści.

Seria „NIS2 – Jak być zgodnym” powstała na podstawie publikacji open access „NIS2 – How to Be Compliant v1.3” autorstwa Wojciecha Ciemskiego (Zenodo, 2025). Materiał stanowi praktyczny przewodnik po wdrażaniu dyrektywy NIS2 w organizacjach zgodnie z jej artykułami 21 i 23.