Ustawa o Krajowym Systemie Cyberbezpieczeństwa – analiza ryzyka i ciągłość działania

15-16 czerwca 2026 • Katowice • Międzynarodowe Centrum Kongresowe

Zarejestruj się

• Ustawa z 23 stycznia 2026 r. została ogłoszona 2 marca 2026 r. i weszła w życie 3 kwietnia 2026 r., a jej celem jest kompleksowa przebudowa krajowego systemu cyberbezpieczeństwa oraz wdrożenie rozwiązań spójnych z dyrektywą NIS 2.
• Nowa uKSC przesuwa ciężar z deklaracji na dowody: analiza ryzyka ma uzasadniać dobór środków i decyzje biznesowe.
• BCP i DRP stają się obowiązkiem operacyjnym: plany trzeba dokumentować, testować, utrzymywać i powiązać z monitoringiem ciągłym.
• Ustawa wzmacnia odpowiedzialność kierownictwa i wskazuje na potrzebę roli CISO, także w modelu CISO-as-a-service, bez przenoszenia odpowiedzialności.

W debacie publicznej najczęściej mówi się o nowych obowiązkach, incydentach i karach. To ważne, ale niepełne. Najbardziej praktyczna zmiana polega na tym, że uKSC łączy obszary, które w wielu firmach działały osobno: analiza ryzyka była domeną compliance, BCP i DRP funkcjonowały jako dokumenty „na wszelki wypadek”, a bezpieczeństwo zostawiano działowi IT. Ustawa rozbija ten model, bo nakłada na podmioty kluczowe i ważne obowiązki zarządzania ryzykiem, wzmacnia odpowiedzialność kierownictwa, wymaga systemu zarządzania bezpieczeństwem informacji i przewiduje cykliczny audyt oraz rozwinięty model reagowania na incydenty.

Analiza ryzyka przestaje być formalnością

Najmocniejszy sygnał płynie już z samego rdzenia ustawy. Art. 8 wymaga wdrożenia systemu zarządzania bezpieczeństwem informacji, który ma zapewniać prowadzenie systematycznego szacowania ryzyka wystąpienia incydentu oraz zarządzanie tym ryzykiem. Co więcej, środki techniczne i organizacyjne mają być odpowiednie i proporcjonalne do oszacowanego ryzyka, z uwzględnieniem m.in. wielkości podmiotu, prawdopodobieństwa incydentów, narażenia na ryzyka oraz skutków społecznych i gospodarczych. To oznacza, że analiza ryzyka powinna być mechanizmem, na którym opiera się cały model ochrony.

Dla biznesu ma to bardzo konkretny skutek. W nowym modelu nie wystarczy ogólne stwierdzenie, że „organizacja zarządza ryzykiem cyber”. Trzeba wykazać, jakie ryzyka zostały zidentyfikowane, jak wpływają na usługi, które procesy są krytyczne i jakie środki dobrano właśnie dlatego, że wynikają z oceny ryzyka.

To przesuwa ciężar z deklaracji na dowód. Zarząd, audyt, regulator i partnerzy biznesowi będą coraz częściej oczekiwali logiki decyzji opartej na ryzyku.

BCP i DRP wchodzą do głównego nurtu zarządzania

Drugi ważny wątek dotyczy ciągłości działania i odtworzenia po awarii. Ustawa nie traktuje BCP i DRP jako dodatku. Wprost wskazuje, że środki bezpieczeństwa mają obejmować wdrażanie, dokumentowanie, testowanie i utrzymywanie planów ciągłości działania umożliwiających ciągłe i niezakłócone świadczenie usługi, a także planów awaryjnych i planów odtworzenia działalności pozwalających odtworzyć system informacyjny po zdarzeniu przekraczającym zdolność odbudowy własnymi środkami. Jednocześnie system informacyjny ma być objęty monitorowaniem w trybie ciągłym.

To zmienia praktyczne znaczenie BCP i DRP. W wielu organizacjach były one przez lata traktowane jako dokumentacja na wypadek audytu, wymóg kontraktowy albo element ISO. uKSC nadaje im rangę obowiązku operacyjnego. BCP ma pokazywać, jak utrzymać usługę, DRP ma pokazywać, jak odtworzyć środowisko, a monitoring ciągły ma wykrywać sygnały, które mogą uruchomić te scenariusze. Innymi słowy: ustawa wymaga nie tylko posiadania planów, ale też ich utrzymywania, testowania i osadzenia w realnym modelu działania.

Warto zwrócić uwagę, że ten kierunek widać także w mechanizmie poleceń zabezpieczających. Ustawa przewiduje, że w reakcji na incydent krytyczny minister może nakazać m.in. przeprowadzenie szacowania ryzyka związanego z danym produktem, usługą lub procesem ICT, a także przegląd planów ciągłości działania, planów awaryjnych i planów odtworzenia działalności pod kątem konkretnego ryzyka.

To pokazuje, że analiza ryzyka i BCP/DRP nie są odrębnymi światami. W logice uKSC to jeden ciąg: identyfikacja ryzyka, przygotowanie scenariuszy i gotowość do działania pod presją.

Gdzie w tym wszystkim jest CISO?

Tu dochodzimy do najważniejszego pytania organizacyjnego. uKSC nie wprowadza literalnego nakazu że każdy podmiot musi zatrudniać CISO, ale coś ważniejszego. Wprost przesuwa odpowiedzialność na kierownika podmiotu kluczowego lub ważnego, który odpowiada za wykonywanie obowiązków z zakresu cyberbezpieczeństwa, także wtedy, gdy część albo całość zadań powierzono innej osobie.

Kierownik ma podejmować decyzje dotyczące przygotowania, wdrażania, stosowania, przeglądu i nadzoru systemu zarządzania bezpieczeństwem informacji, planować adekwatne środki finansowe, przydzielać zadania i nadzorować ich wykonanie.

Dodatkowo kierownik oraz osoba, której powierzono obowiązki kierownika w zakresie cyberbezpieczeństwa, przechodzą szkolenie raz w roku.

Z tego wynika bardzo praktyczny wniosek: cyberbezpieczeństwo nie może już być wyłącznie jednym z zadań IT. Gdy ustawa wymaga jednocześnie analizy ryzyka, ciągłego monitorowania, BCP/DRP, dokumentacji, obsługi incydentów, raportowania do CSIRT i nadzoru kierownictwa, organizacja potrzebuje roli, która spina te elementy z perspektywy ryzyka i biznesu. W wielu firmach naturalną odpowiedzią jest właśnie CISO jako właściciel funkcji bezpieczeństwa na styku zarządu, operacji, IT, audytu i compliance. To jest wniosek organizacyjny wynikający z konstrukcji ustawy.

Dlaczego dział IT to za mało

To nie jest zarzut wobec działów IT tylko kwestia konstrukcji ról. IT odpowiada zwykle za dostępność systemów, tempo wdrożeń, utrzymanie usług, budżet technologiczny i codzienne operacje. Funkcja bezpieczeństwa musi czasem te cele weryfikować: sprawdzić architekturę, przeprowadzić dodatkowe kontrole, dostępy, przesunąć wdrożenie albo zażądać testów planów awaryjnych. Gdy bezpieczeństwo pozostaje wyłącznie częścią IT, pojawia się ryzyko, że ta sama funkcja będzie jednocześnie budować środowisko, oceniać własne decyzje i raportować ich poprawność. W praktyce to klasyczne napięcie między efektywnością operacyjną a niezależnym nadzorem. uKSC wzmacnia tę drugą stronę, bo wymaga odpowiedzialności kierownictwa, audytów i udokumentowanego zarządzania ryzykiem.

Sygnał o potrzebie rozdzielenia ról widać też przy audycie. Ustawa wymaga, by podmiot kluczowy przeprowadzał audyt bezpieczeństwa co najmniej raz na 3 lata, a jego raport przekazywał organowi właściwemu do spraw cyberbezpieczeństwa. To nie jest już model, w którym bezpieczeństwo można w pełni zamknąć w operacji IT. Skoro pojawia się formalny audyt i obowiązek wykazania dojrzałości, potrzebna jest funkcja, która potrafi rozmawiać o ryzyku, BCP/DRP, incydentach i architekturze nie tylko językiem administratora, ale również językiem zarządu i regulatora.

CISO-as-a-service: nie obejście, lecz praktyczny model wdrożenia

Najciekawsze jest to, że sama ustawa dopuszcza elastyczny model organizacyjny. Art. 14 stanowi, że podmiot kluczowy lub ważny ma powołać wewnętrzne struktury odpowiedzialne za cyberbezpieczeństwo albo zawrzeć umowę z dostawcą usług zarządzanych w zakresie cyberbezpieczeństwa. To oznacza, że ustawodawca dopuszcza zarówno model wewnętrzny, jak i zewnętrzny. W praktyce otwiera to drogę do modelu CISO-as-a-service, szczególnie w średnich organizacjach, które potrzebują kompetencji strategicznych i nadzorczych, ale nie są gotowe na budowę pełnej funkcji bezpieczeństwa in-house.

Trzeba jednak postawić sprawę jasno: outsourcing nie oznacza outsourcingu odpowiedzialności.

Kierownik podmiotu nadal odpowiada za wykonanie obowiązków. Dlatego CISO-as-a-service ma sens wtedy, gdy nie jest sprowadzony do roli „doradcy od dokumentów”, lecz rzeczywiście wspiera zarząd w analizie ryzyka, architekturze bezpieczeństwa, przeglądzie BCP/DRP, nadzorze nad incydentami, relacji z dostawcami i przygotowaniu do audytu. Innymi słowy, model usługowy jest zgodny z logiką uKSC, gdy buduje realną funkcję bezpieczeństwa.

Co to oznacza dla zarządów już teraz

Dla biznesu najważniejsze są dziś trzy wnioski.

Po pierwsze, analiza ryzyka musi stać się realnym mechanizmem podejmowania decyzji, a nie załącznikiem do polityki. Po drugie, BCP i DRP trzeba wypracować, przetestować i powiązać z krytycznymi usługami oraz scenariuszami incydentowymi. Po trzecie, organizacja powinna wyraźnie wskazać właściciela funkcji bezpieczeństwa, niezależnie od tego, czy będzie to CISO wewnętrzny, czy model CISO-as-a-service oparty na zewnętrznym dostawcy. To staje się elementem zgodności, odporności operacyjnej i odpowiedzialności kierownictwa.

Największym błędem byłoby dziś traktowanie uKSC jako ustawy wyłącznie o technicznej. To ustawa, która wymusza połączenie trzech rzeczy: dobrego rozpoznania ryzyka, gotowości do utrzymania i odtworzenia usług oraz jasnej odpowiedzialności za bezpieczeństwo. Właśnie dlatego rola CISO, także w formule usługowej, zyskuje dziś zupełnie nowe znaczenie - jako odpowiedź na regulację, która kończy epokę cyberbezpieczeństwa zostawionego IT.

Autor: Tomasz Janas, prezes zarządu Advisory w PKF Polska