Polska wdraża dyrektywę NIS2 z opóźnieniem – ale presja na podmioty publiczne rośnie niezależnie od tego, czy nowelizacja KSC jest już w życie, czy jeszcze nie. Urzędy i instytucje, które jeszcze kilka lat temu mogły traktować cyberbezpieczeństwo jako problem sektora bankowego, dziś mierzą się z konkretnymi wymaganiami i realnymi sankcjami. Problem w tym, że większość materiałów o NIS2 jest albo zbyt ogólna, albo napisana językiem prawniczym, który niewiele mówi administratorowi siedzącemu z pustym Wordem przed sobą.
Poniżej zebrałem listę dokumentów, które faktycznie trzeba przygotować – z komentarzem, co w każdym z nich jest naprawdę ważne, a co to tylko formalność.
Czym jest NIS2 i kogo dotyczy?
Dyrektywa NIS2 (EU 2022/2555) zastąpiła NIS1 i obowiązuje od 16 stycznia 2023 r. W Polsce jej przepisy trafiają do krajowego prawa przez nowelizację Ustawy o Krajowym Systemie Cyberbezpieczeństwa (KSC). Dyrektywa dzieli organizacje na dwie kategorie:
- Podmioty kluczowe – energetyka, transport, bankowość, zdrowie, infrastruktura cyfrowa, administracja rządowa
- Podmioty ważne – m.in. część samorządów, uczelnie, instytuty badawcze
Różnica między nimi przekłada się głównie na intensywność nadzoru i wysokość kar – nie na zakres wymaganej dokumentacji, który jest zbliżony.
Do podmiotów publicznych objętych NIS2 należą: organy administracji rządowej, jednostki samorządu terytorialnego (gminy, powiaty, województwa), publiczne szpitale i przychodnie, uczelnie publiczne oraz operatorzy infrastruktury krytycznej.
Jeden praktyczny wniosek: nawet jeśli Twoja jednostka nie jest jeszcze formalnie wyznaczona, coraz więcej przetargów i audytów zewnętrznych pyta o dokumentację zgodną z NIS2. Lepiej mieć ją gotową wcześniej niż tłumaczyć się z jej braku.
Wymagana dokumentacja NIS2 – co faktycznie musisz mieć
NIS2 nie daje gotowej listy dokumentów do odhaczenia. Artykuł 21 dyrektywy określa środki zarządzania ryzykiem – z nich wynikają konkretne dokumenty. Poniżej przekładam to na praktykę.
1. Polityka bezpieczeństwa informacji (PBI)
Często traktowana jako formalność na koniec projektu. To błąd – bez dobrej PBI reszta dokumentacji nie ma zaczepu. PBI musi określać zakres (które systemy i dane obejmuje), kto za co odpowiada, i jak często dokumenty są przeglądane. To ostatnie jest szczególnie zaniedbywane: polityka sprzed trzech lat, której nikt nie ruszał, to w oczach audytora brak polityki.
W treści powinny znaleźć się odniesienia do NIS2/KSC, RODO oraz ustawy o informatyzacji – tak żeby dokument był spójny z resztą otoczenia prawnego organizacji.
2. Analiza i zarządzanie ryzykiem
Tutaj większość podmiotów publicznych ma największą lukę. Nie chodzi o to, żeby kupić drogie narzędzie GRC – chodzi o to, żeby mieć aktualny rejestr aktywów, rejestr ryzyk z oceną prawdopodobieństwa i wpływu, oraz plan postępowania z każdym ryzykiem (akceptacja, mitygacja, transfer).
Metodologia: ISO 27005, EBIOS RM lub uproszczona matryca ryzyka. Dla mniejszych JST ta ostatnia w zupełności wystarczy – ważne, żeby odzwierciedlała rzeczywisty stan, nie wyobrażony.
3. Procedury zarządzania incydentami
To miejsce, gdzie administratorów czeka największe zaskoczenie: terminy są bardzo krótkie. NIS2 wymaga wczesnego ostrzeżenia w ciągu 24 godzin od wykrycia incydentu, powiadomienia właściwego CSIRT w ciągu 72 godzin i raportu końcowego w ciągu 30 dni. Nie ma tu miejsca na „zobaczymy co to jest i potem zadecydujemy”.
Procedura musi mieć gotową klasyfikację incydentów, jasną ścieżkę eskalacji z numerami telefonów do CSIRT sektorowego oraz zasady komunikacji kryzysowej – zarówno wewnętrznej, jak i wobec mediów czy obywateli.
4. Plan ciągłości działania (BCP/DRP)
Dokument, który większość organizacji ma w szufladzie i który nigdy nie był testowany. NIS2 wymaga, żeby plan był realny – co oznacza zdefiniowane wartości RTO i RPO dla systemów krytycznych, procedury odtworzeniowe i – co najważniejsze – udokumentowane ćwiczenia co najmniej raz w roku. Ćwiczenia to ten element, który najłatwiej pominąć i który najszybciej wychodzi przy audycie.
5. Polityka zarządzania dostawcami i łańcuchem dostaw
Niedoceniany obszar, który w ostatnich latach odpowiada za dużą część poważnych incydentów. Podmiot publiczny musi wiedzieć, komu powierza usługi IT, jakie wymagania bezpieczeństwa na nich nakłada i jak weryfikuje ich spełnienie. Klauzule bezpieczeństwa w umowach to minimum – rejestr dostawców z oceną ryzyka to krok dalej, ale już wymagany przez NIS2.
6. Polityka kontroli dostępu i zarządzania tożsamością
Zasada minimalnych uprawnień, MFA dla systemów krytycznych, zarządzanie kontami uprzywilejowanymi (PAM) i – rzecz nagminnie zaniedbywana – procedura szybkiego odbierania dostępów przy odejściu pracownika. W podmiotach publicznych o dużej rotacji kadr ten ostatni punkt jest regularnie słabym ogniwem.
7. Polityka kryptografii i zarządzania kluczami
Nie musi być rozbudowana, ale musi być. Wystarczy, że określa dopuszczalne algorytmy (zgodnie z rekomendacjami ENISA lub NIST), wymogi szyfrowania danych w spoczynku i transmisji oraz sposób zarządzania certyfikatami. Brak tej polityki to jeden z łatwiejszych do zidentyfikowania braków podczas audytu.
8. Bezpieczeństwo zasobów ludzkich
Weryfikacja pracowników na wrażliwych stanowiskach, regularne szkolenia (NIS2 wymaga, żeby były weryfikowalne – sam e-learning „zaliczony” przez kliknięcie nie wystarczy) i procedura offboardingu. W praktyce największy problem to szkolenia: organizacje robią je raz na dwa lata i traktują jako odhaczenie checklisty.
9. Zarządzanie podatnościami i aktualizacjami
Systematyczne skanowanie podatności, priorytetyzacja poprawek według CVSS i zdefiniowane okna czasowe na ich wdrożenie. Dla krytycznych podatności (CVSS ≥ 9.0) rekomendacja to 72 godziny – w środowiskach publicznych z rozbudowanymi procedurami change management to poważne wyzwanie organizacyjne, nie tylko techniczne.
10. Logi audytowe i monitoring
Wykaz systemów objętych centralnym logowaniem, retencja logów minimum 12 miesięcy i – to często pomijane – procedura regularnego przeglądu. Logi, których nikt nie czyta, to tylko pozór bezpieczeństwa. SIEM nie jest wymagany wprost, ale w organizacjach powyżej kilkudziesięciu systemów staje się koniecznością praktyczną.
Od czego zacząć – kolejność ma znaczenie
Po kilku wdrożeniach NIS2 w podmiotach publicznych widać wyraźnie, że kolejność prac ma ogromne znaczenie. Zaatakowanie od razu tworzenia polityk bez wcześniejszej inwentaryzacji aktywów to przepis na dokumenty oderwane od rzeczywistości – piękne na papierze, bezużyteczne w praktyce.
Sensowna kolejność wygląda tak:
- GAP analysis – sprawdzenie, co już masz i czego brakuje. Bez tego nie wiadomo, gdzie jest problem.
- Inwentaryzacja aktywów – zanim cokolwiek ocenisz, musisz wiedzieć, co masz. To fundament analizy ryzyka.
- Analiza ryzyka – dopiero teraz, na podstawie aktywów.
- Dokumenty w kolejności zależności – PBI → zarządzanie ryzykiem → procedury incydentów → reszta.
- Wdrożenie techniczne – MFA, szyfrowanie, monitoring. Dokumenty bez technikaliów to fikcja.
- Szkolenia – nie na początku i nie „raz na zawsze”.
- Test i weryfikacja – ćwiczenia BCP, próbny audyt wewnętrzny.
Sankcje – co grozi za brak dokumentacji
Po wejściu w życie nowelizacji KSC podmioty kluczowe i ważne będą podlegać nadzorowi organów sektorowych. Kary finansowe przewidziane przez NIS2:
- Podmioty kluczowe: do 10 mln EUR lub 2% rocznego obrotu
- Podmioty ważne: do 7 mln EUR lub 1,4% rocznego obrotu
Dla podmiotów publicznych nieprowadzących działalności komercyjnej kary będą ustalane przez krajowe organy nadzorcze na podstawie KSC – ale dyrektywa przewiduje też możliwość zakazu pełnienia funkcji zarządczych przez osoby odpowiedzialne za naruszenia. To istotna zmiana w porównaniu z NIS1, gdzie odpowiedzialność była praktycznie zerowa.
Narzędzia, które rzeczywiście pomagają
Bez konkretnych narzędzi:
- ENISA NIS2 Implementation Guidance – punkt startowy, oficjalne wytyczne UE
- ISO/IEC 27001:2022 – jeśli organizacja ma zasoby, certyfikacja ISO 27001 pokrywa większość wymagań NIS2 z nadwyżką
- Wytyczne CERT Polska / CSIRT NASK – najlepsze polskojęzyczne materiały, dostosowane do realiów krajowych
- Eramba (open source) – do zarządzania ryzykiem i dokumentacją GRC bez kosztów licencyjnych
- Cyber Essentials (NCSC UK) – uproszczony framework, dobry punkt wejścia dla mniejszych JST
Gdzie podmioty publiczne potykają się najczęściej
Dokumentacja „na papierze”. Polityki istnieją, ale kontrole techniczne nie – przy pierwszym audycie to wychodzi natychmiast.
Dokumenty bez dat przeglądu. Polityka bezpieczeństwa sprzed czterech lat, której nikt nie aktualizował, to w praktyce brak polityki.
Pominięci dostawcy. Umowy z firmami IT bez klauzul NIS2 to dziura w systemie – i odpowiedzialność, która w razie incydentu spada z powrotem na organizację.
Szkolenia jako formalność. Kliknięcie „dalej” przez e-learning co dwa lata nie spełnia wymogu „regularnych szkoleń”. Audytorzy pytają o terminy, frekwencję i potwierdzenia uczestnictwa.
Systemy legacy poza zakresem. „Stary system, nikt go nie rusza” – to właśnie te systemy są najczęściej wektorem ataku i najczęściej wypadają z analizy ryzyka.
Podsumowanie
NIS2 w podmiotach publicznych to nie projekt IT z datą zakończenia. To zmiana sposobu, w jaki organizacja podchodzi do ryzyka – ciągła, wymagająca zaangażowania zarówno działu IT, jak i kierownictwa, które podpisuje dokumenty i ponosi odpowiedzialność.
Dobra dokumentacja nie musi być obszerna. Musi być aktualna, spójna z rzeczywistością techniczną i faktycznie stosowana – to trzy warunki, które większość organizacji nie spełnia jednocześnie.
Jeśli masz pytania dotyczące wdrożenia NIS2 w swojej jednostce – napisz. Pomagamy zarówno przy audycie wstępnym, jak i przy budowaniu dokumentacji od zera: zjawa.it/kontakt.