Spis treści:
-
- Obowiązek organizacyjny, a nie tylko techniczny
- Od NIS 2 do uksc: nowa logika zgodności
- Kogo w sektorze publicznym mogą objąć nowe obowiązki
- Obowiązki podmiotów publicznych: nie każdy przypadek wygląda tak samo
- Koniec pozornej zgodności
Nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa wdrażająca dyrektywę NIS 2 oznacza zmianę jakościową dla administracji publicznej. Cyberbezpieczeństwo staje się elementem legalności działania, kontroli zarządczej, ciągłości świadczenia usług publicznych i należytej staranności kierownictwa jednostki.
Jednostka publiczna musi być w stanie wykazać, że zna swoje zadania publiczne, systemy informacyjne, zależności od dostawców, ryzyka, procedury incydentowe, obowiązki raportowe i mechanizmy odtworzeniowe. Pozorna zgodność, polegająca na posiadaniu polityk i procedur bez realnego wdrożenia, będzie coraz trudniejsza do obrony w razie kontroli, incydentu albo sporu dotyczącego odpowiedzialności za zaniechania.
Dla radcy prawnego obsługującego administrację oznacza to konieczność wejścia w rolę współtwórcy systemu zgodności. Obsługa prawna powinna wspierać kwalifikację statusu podmiotu, porządkowanie governance, ocenę obowiązków kierownictwa, przegląd regulacji wewnętrznych, projektowanie postanowień umownych, zamówienia publiczne na usługi ICT oraz przygotowanie jednostki do kontroli i audytu.
Obowiązek organizacyjny, a nie tylko techniczny
Nowelizacja ustawy o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustaw (dalej: uksc) weszła w życie 3 kwietnia 2026 r. Wdrożyła zasadnicze założenia dyrektywy NIS 2 do polskiego porządku prawnego, zastępując wcześniejszy model operatorów usług kluczowych i dostawców usług cyfrowych nowym podziałem na podmioty kluczowe i podmioty ważne.
Znaczenie tej zmiany nie polega wyłącznie na tym, że więcej podmiotów zostanie objętych ustawą. Istotniejsze jest to, że uksc wymusza spojrzenie na cyberbezpieczeństwo jako na proces zarządczy. W centrum tego procesu są: identyfikacja usług i zadań publicznych, zarządzanie ryzykiem, system zarządzania bezpieczeństwem informacji, bezpieczeństwo łańcucha dostaw, ciągłość działania, obsługa incydentów, audyt, szkolenia, dokumentowanie decyzji oraz odpowiedzialność kierownictwa. Dlatego nowelizacja uksc powinna być postrzegana przez administrację nie jako kolejny obowiązek sprawozdawczo-techniczny, ale jako impuls do uporządkowania odpowiedzialności za cyfrowe funkcjonowanie jednostki.
Od NIS 2 do uksc: nowa logika zgodności
Dyrektywa NIS 2 zakłada osiągnięcie wysokiego wspólnego poziomu cyberbezpieczeństwa w Unii Europejskiej. Polska implementacja rozbudowuje katalog sektorów, podmiotów i obowiązków. Ministerstwo Cyfryzacji wskazuje, że Krajowy System Cyberbezpieczeństwa może objąć ok. 38 tys. podmiotów, w tym ok. 27 tys. podmiotów publicznych.
Właściwa analiza powinna obejmować co najmniej 5 zagadnień:
- Czy jednostka mieści się w sektorze podmiotów publicznych z załączników nr 1 albo nr 2 do uksc?
- Czy wykonuje zadania publiczne z wykorzystaniem systemów informacyjnych?
- Czy ze względu na rodzaj działalności może należeć również do innego sektora, np. ochrony zdrowia, wody, ścieków, transportu, odpadów, badań naukowych albo infrastruktury cyfrowej?
- Czy będzie wpisywana do Wykazu KSC z urzędu czy powinna dokonać samorejestracji?
- Jakie obowiązki należy zastosować z uwzględnieniem statusu podmiotu kluczowego albo podmiotu ważnego i ewentualnych modyfikacji dotyczących podmiotów publicznych?
Kogo w sektorze publicznym mogą objąć nowe obowiązki
Ustawa definiuje podmiot publiczny przez odesłanie do załączników nr 1 i 2 w sektorze „podmioty publiczne”. W uproszczeniu załącznik nr 1 obejmuje podmioty publiczne w sektorach kluczowych, natomiast załącznik nr 2 obejmuje podmioty publiczne w sektorach ważnych. Nie należy jednak sprowadzać tej kwalifikacji do prostego rozróżnienia: „administracja centralna – kluczowa, administracja samorządowa – ważna”. Ustawa posługuje się bardziej szczegółowymi kategoriami, a część jednostek publicznych może być kwalifikowana także na podstawie innych sektorów.
W załączniku nr 1 w sektorze podmiotów publicznych wskazano m.in. określone jednostki sektora finansów publicznych, urzędy je obsługujące, państwowe instytucje kultury, instytuty badawcze i wskazane z nazwy lub rodzaju podmioty publiczne. W załączniku nr 2 w sektorze podmiotów publicznych ujęto m.in. samorządowe jednostki budżetowe, samorządowe zakłady budżetowe, samorządowe instytucje kultury i spółki wykonujące zadania o charakterze użyteczności publicznej w rozumieniu ustawy o gospodarce komunalnej.
Z punktu widzenia praktyki radcy prawnego istotne są następujące konsekwencje:
- analiza statusu powinna być dokonana odrębnie dla każdej jednostki, a nie jedynie na poziomie „urzędu” rozumianego potocznie;
- kwalifikacja do sektora podmiotów publicznych nie wyklucza równoległej kwalifikacji sektorowej;
- trzeba odróżniać pojęcia „podmiot kluczowy”, „podmiot ważny” i „podmiot krytyczny” – to ostatnie pojęcie występuje w uksc, ale nie powinno być używane publicystycznie jako synonim podmiotu kluczowego. „Podmiot krytyczny” to pojęcie powiązane z reżimem odporności podmiotów krytycznych i dyrektywą CER, natomiast podstawowymi kategoriami uksc/NIS 2 pozostają podmiot kluczowy oraz podmiot ważny.
Obowiązki podmiotów publicznych: nie każdy przypadek wygląda tak samo
Jednym z miejsc wymagających szczególnej ostrożności interpretacyjnej jest art. 8 uksc. Co do zasady podmiot kluczowy lub podmiot ważny wdraża system zarządzania bezpieczeństwem informacji w systemie informacyjnym wykorzystywanym w procesach wpływających na świadczenie usługi. System ten ma zapewniać m.in. systematyczne szacowanie ryzyka, zarządzanie ryzykiem, odpowiednie i proporcjonalne środki techniczne i organizacyjne, bezpieczeństwo łańcucha dostaw, plany ciągłości działania, monitorowanie, polityki kryptografii, cyberhigienę, edukację personelu i kontrolę dostępu.
Jednocześnie ustawa wprowadza istotne odrębności dla podmiotu ważnego będącego podmiotem publicznym. Taki podmiot nie stosuje art. 8 ust. 1, lecz opracowuje, wdraża, realizuje, monitoruje i utrzymuje w kontrolowanych przez siebie systemach informacyjnych system zarządzania bezpieczeństwem informacji spełniający wymogi z załącznika nr 4 do uksc. To rozróżnienie powinno znaleźć odzwierciedlenie w dokumentacji wdrożeniowej. Nie wystarczy mechanicznie przepisać obowiązków z art. 8 ust. 1 dla każdego podmiotu publicznego. Trzeba najpierw ustalić jego status i dopiero potem dobrać właściwą ścieżkę zgodności.
Istotny jest także art. 16d uksc. Zgodnie z nim podmiot publiczny realizuje wskazane obowiązki, jeżeli wykorzystuje system informacyjny w celu realizacji zadania publicznego. Ten przepis ma duże znaczenie dla praktyki, ponieważ wiąże obowiązki cyberbezpieczeństwa z faktycznym wykonywaniem zadań publicznych przy użyciu systemów informacyjnych. Innymi słowy, analiza nie powinna kończyć się na strukturze organizacyjnej. Należy ustalić, jakie zadania jednostka wykonuje i które systemy są do tego potrzebne.
W praktyce warto stworzyć mapę zależności:
zadanie publiczne – proces – system informacyjny – dane – dostawca – infrastruktura – właściciel procesu – skutki przerwy w działaniu.
Dopiero taka mapa pozwala rzetelnie ocenić, które systemy mają znaczenie dla ciągłości działania i które umowy lub procedury wymagają pilnej aktualizacji.
Koniec pozornej zgodności
Centralnym problemem administracji publicznej nie będzie brak dokumentów, lecz brak dowodów, że zostały wdrożone. Pozorna zgodność polega na tym, że jednostka posiada politykę bezpieczeństwa, procedurę incydentową, regulamin korzystania z systemów i rejestr uprawnień, ale nie potrafi wykazać ich stosowania. Pracownicy nie wiedzą, komu zgłaszać incydent. Kierownictwo nie otrzymuje informacji o ryzykach. Dostawca nie ma obowiązku niezwłocznego przekazania logów. Kopie zapasowe istnieją, ale nie były testowane. Umowa serwisowa nie przewiduje wsparcia przy incydencie. Plan ciągłości działania nie wskazuje priorytetów odtworzenia usług.
Nowy model uksc wymusza odejście od takiego podejścia. Ustawa akcentuje nie tylko dokumentację normatywną, ale także dokumentację operacyjną, czyli zapisy poświadczające wykonywanie czynności wymaganych przez dokumentację bezpieczeństwa, w tym zapisy generowane w dziennikach systemów informacyjnych.
To bardzo ważna zmiana praktyczna. W razie kontroli, audytu albo incydentu jednostka będzie musiała wykazać nie tylko, że przyjęła procedury, ale że je stosuje. Dowodami mogą być m.in. wyniki szacowania ryzyka, protokoły testów odtworzeniowych, potwierdzenia szkoleń, raporty z przeglądów uprawnień, rejestry incydentów, notatki z decyzji kierownictwa, harmonogramy działań naprawczych, zgłoszenia do właściwego CSIRT, korespondencja z dostawcami, raporty z audytów, protokoły odbioru usług i dokumentacja ćwiczeń.
Z perspektywy obsługi prawnej oznacza to, że pytanie: „czy mamy procedurę?”, należy zastąpić pytaniem: „czy potrafimy udowodnić, że procedura działa?”.
Autorzy
Mateusz Jakubik
Autor jest prawnikiem z doświadczeniem łączącym aspekty prawne z IT. Zawodowo związany z Bonnier Business Polska (CISO), InfinityLawTech (Partner) oraz ODO Szkolenia (CIO). Jest certyfikowanym audytorem wiodącym systemów zarządzania bezpieczeństwem informacji (ISO/IEC 27001), ciągłością działania (ISO 22301) i sztuczną inteligencją (ISO/IEC 42001).
Rafał Tomasz Prabucki
Autor jest doktorem nauk prawnych i inżynierem; członkiem Społecznego Zespołu Ekspertów przy Prezesie Urzędu Ochrony Danych Osobowych; Auditorem wiodącym ISO/IEC 27001, BCMS ISO 22301 oraz ISO/IEC 42001/2023. Jest posiadaczem tytułu Certified in Cybersecurity (CC) wydanym przez (ISC)²; adiunktem na UŚ; członkiem CYBER SCIENCE i SABI; założycielem LegalHackers Katowice.
