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.