NIS2 art. 21: dziesięć środków na jednej mapie

Weźmy przykładową firmę produkcyjną, sto pięćdziesiąt osób. Pełnomocnik do spraw bezpieczeństwa dostaje od zarządu listę dziesięciu środków z art. 21 dyrektywy NIS2 i rozpisuje ją na dziesięć osobnych projektów. Każdy ma swój folder, swojego właściciela i swój termin. Po trzech miesiącach folder „polityki” jest pełny, a reszta czeka.

Tymczasem administrator od roku skanuje serwery, pilnuje terminów usuwania podatności i zapisuje, czego świadomie nie naprawia. Nikt nie połączył tej pracy z listą. Obsługa podatności jest wymieniona wprost w literze e, ale dane z tego procesu przydają się też przy ocenie skuteczności i przy cyberhigienie. Ten sam materiał pasuje do kilku pozycji naraz, tylko nikt go tam nie wpisał.

Ten tekst to mapa: dziesięć środków po ludzku, przykład dowodu przy każdym i miejsca, w których jeden działający proces daje materiał do kilku pozycji.

Co mówi przepis

Dyrektywa NIS2 w art. 21 ust. 1 wymaga od podmiotów kluczowych i ważnych odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych. Mają one zarządzać ryzykiem dla bezpieczeństwa używanych systemów sieciowych i informatycznych oraz zapobiegać wpływowi incydentów na odbiorców usług i na inne usługi albo ten wpływ ograniczać. Art. 21 ust. 2 dodaje, że środki opierają się na podejściu uwzględniającym wszystkie zagrożenia i chronią także fizyczne otoczenie tych systemów, a następnie wymienia dziesięć obszarów, które muszą obejmować co najmniej, oznaczonych literami od a do j.

W Polsce dyrektywę wdraża ustawa o krajowym systemie cyberbezpieczeństwa, znowelizowana w 2026 roku. Obowiązki dotyczące systemu zarządzania bezpieczeństwem informacji są w jej art. 8, ale numeracja punktów nie odpowiada literom dyrektywy jeden do jednego. Na przykład litera i dyrektywy jest w ustawie rozdzielona na kilka osobnych punktów. Na audycie rozmawia się o przepisach ustawy, więc mapę warto uzupełnić o odwołania do nich.

Art. 20 dyrektywy dodaje, że organy zarządzające zatwierdzają te środki, nadzorują ich wdrażanie i mogą ponosić odpowiedzialność za naruszenia. Lista z art. 21 nie jest więc zadaniem wyłącznie dla działu IT.

Dziesięć środków po ludzku

Litera	Co obejmuje	Przykład dowodu
a	Polityki analizy ryzyka i bezpieczeństwa systemów informatycznych	Zatwierdzona polityka z numerem wersji i analiza ryzyka, na którą się powołuje
b	Obsługa incydentów	Procedura i rejestr incydentów z momentem wykrycia, decyzjami i datami zgłoszeń
c	Ciągłość działania: zarządzanie kopiami zapasowymi, odtwarzanie po awarii, zarządzanie kryzysowe	Protokół z ostatniego testu odtworzenia kopii
d	Bezpieczeństwo łańcucha dostaw, w tym aspekty bezpieczeństwa relacji z bezpośrednimi dostawcami lub usługodawcami	Ocena kluczowych dostawców i zapisy w umowach
e	Bezpieczeństwo nabywania, rozwoju i utrzymania systemów sieciowych i informatycznych, w tym obsługa i ujawnianie podatności	Historia skanów, terminy usunięcia, decyzje o wyjątkach
f	Polityki i procedury oceny skuteczności środków zarządzania ryzykiem w cyberbezpieczeństwie	Wskaźniki z kilku okresów i wnioski z przeglądu
g	Podstawowa cyberhigiena i szkolenia z cyberbezpieczeństwa	Lista obecności ze szkolenia i dane o terminowości aktualizacji
h	Polityki i procedury stosowania kryptografii oraz, w stosownych przypadkach, szyfrowania	Polityka kryptograficzna i lista systemów objętych szyfrowaniem
i	Bezpieczeństwo zasobów ludzkich, polityki kontroli dostępu i zarządzanie aktywami	Ewidencja aktywów z właścicielami i przegląd uprawnień
j	W stosownych przypadkach: rozwiązania uwierzytelniania wieloskładnikowego lub ciągłego, zabezpieczona komunikacja głosowa, wideo i tekstowa oraz zabezpieczone systemy łączności alarmowej wewnątrz podmiotu	Lista systemów z wymuszonym drugim składnikiem

Środki mają być proporcjonalne do ryzyka, wielkości podmiotu i skutków ewentualnych incydentów. Lista nie narzuca narzędzi ani częstotliwości działań. Trzeba je ustalić z uwzględnieniem ryzyka i przepisów właściwych dla podmiotu. Przykłady w tabeli to materiały, które zwykle się pokazuje, a nie wymagane prawem formularze ani komplet dowodów dla danej litery.

Gdzie jest luka

Dziesięć liter to nie dziesięć projektów. Lista porządkuje wymagania, ale praca w firmie nie dzieli się tak samo. Działający proces zarządzania podatnościami jest dowodem dla litery e, a jednocześnie daje dane do kilku innych: polityka podatności jest częścią polityk z litery a, wskaźniki terminowości są materiałem do oceny skuteczności z litery f, terminowe aktualizacje to element cyberhigieny z litery g, a ewidencja serwerów z właścicielami to kawałek zarządzania aktywami z litery i. Osobne projekty dla każdej litery łatwo prowadzą do zbierania tych samych danych kilka razy.

Część liter nie ma danych w żadnym systemie. Protokół z testu odtworzenia kopii, ocena dostawcy czy polityka kryptograficzna to materiały, których skaner nie wytworzy. Trzeba je mieć, a do tego wiedzieć, gdzie leżą, kto za nie odpowiada i kiedy ktoś je ostatnio sprawdzał.

Mapa bez właścicieli szybko się starzeje. Tabela zrobiona raz na audyt wygląda dobrze w dniu, w którym powstała. Bez przeglądów odnośniki zaczynają prowadzić do nieaktualnych plików.

Jak zrobić własną mapę

Poniżej proponuję sposób uporządkowania pracy. To nie jest procedura narzucona przez przepisy ani ocena obowiązków konkretnej firmy. Pierwszą wersję mapy osoba odpowiedzialna za KSC przygotuje razem z administratorem i właścicielami pozostałych obszarów; czas zależy od tego, ile dokumentacji już jest.

1. Wypisz dziesięć liter w tabeli. Jeden wiersz na literę, obok odpowiadające jej przepisy ustawy o KSC.

2. Przy każdej literze wpisz, gdzie jest dowód. Konkretna lokalizacja: system, folder, rejestr. Nie „w dziale IT”.

3. Oznacz rodzaj dowodu. Dane z systemu, które powstają same w trakcie pracy, dokument, który ktoś musi aktualizować, albo brak. To rozróżnienie mówi, gdzie potrzebny jest cykliczny przegląd.

4. Przypisz właściciela i datę ostatniego przeglądu. To ułatwia sprawdzanie, czy materiały są aktualne. Sama data przeglądu nie dowodzi jednak, że czynność wykonano, więc przy każdym wierszu powinien być też odnośnik do samego dokumentu albo wyniku.

5. Zaznacz procesy, które dostarczają materiał do więcej niż jednego wiersza. Przy każdym takim wierszu wstaw odnośnik do tego samego źródła, zamiast zbierać dane osobno.

6. Zacznij od braków, nie od dokumentów. Wiersz z oznaczeniem „brak” to pierwszy temat na najbliższy przegląd z zarządem. Art. 20 wymaga, żeby organ zarządzający zatwierdzał środki i nadzorował ich wdrażanie, więc istotne braki przedstaw zarządowi razem z propozycją działań i potrzebnych zasobów.

7. Ustal cykl przeglądu mapy. Na przykład raz na kwartał i po każdej większej zmianie, takiej jak zmiana dostawcy, wdrożenie nowego systemu albo zmiana w zespole.

Gdzie pomaga Secvalis, a gdzie nie

Secvalis ma mapę zgodności, która łączy wybrane wymagania z sygnałami produktu i odsyłaczami do dostępnych danych, a także wskazuje obszary, w których dowody trzeba dostarczyć spoza produktu. Dla dziesięciu liter wygląda to tak:

Litera	Dane z Secvalis	Poza produktem
a	Edytowalny szablon polityki zarządzania podatnościami z progami SLA i EOL konta	Pozostałe polityki, analiza ryzyka, zatwierdzenie
b	Rejestr incydentów z historią i dokumentem do przygotowania zgłoszenia	Wykrywanie i ocena incydentu, przekazanie zgłoszenia
c	Rejestr przeglądów dowodów: lokalizacja, właściciel, cykl, historia	Kopie zapasowe, testy odtworzenia, zarządzanie kryzysowe
d	Rejestr przeglądów dowodów jak w c	Ocena dostawców i umowy
e	Skany, terminy usunięcia z progiem dla podatności aktywnie wykorzystywanych, lista zadań, decyzje o wyjątkach, raport EOL, Evidence Pack	Wdrożenie i sprawdzenie poprawek w firmie, systemy nieobjęte skanem agenta
f	Raport zarządczy z oceną procesu, terminowością i średnim czasem usunięcia	Ocena skuteczności pozostałych środków
g	Dane o terminowości usuwania podatności	Szkolenia
h	Rejestr przeglądów dowodów jak w c	Polityka i stosowanie kryptografii
i	Lista maszyn z krytycznością i ekspozycją	Kadry, kontrola dostępu w firmie, aktywa bez agenta
j	Możliwość wymagania drugiego składnika logowania od członków konta Secvalis	Uwierzytelnianie wieloskładnikowe w systemach firmy

Najwięcej danych produkt ma dla litery e, bo to jego główny obszar. Dla liter c, d i h przechowuje tylko informację, gdzie jest dowód, kto za niego odpowiada i kiedy ktoś go sprawdzał. Nie sprawdza, czy dokument istnieje ani czy czynność wykonano. Uwierzytelnianie wieloskładnikowe z litery j dotyczy dostępu do samego Secvalis, nie systemów firmy.

Rejestr incydentów nie wykrywa incydentów i nie wysyła zgłoszeń do CSIRT. Dla incydentu oznaczonego jako podlegający zgłoszeniu Secvalis wyznacza terminy 24 i 72 godzin na podstawie zapisanej chwili, od której incydent podlega zgłoszeniu. Ustawa o KSC liczy terminy wczesnego ostrzeżenia i zgłoszenia incydentu poważnego od momentu jego wykrycia, więc ten moment trzeba osobno i rzetelnie udokumentować, a terminy ustawowe sprawdzić samodzielnie.

Agent skanuje hosty Linux i obrazy uruchomionych kontenerów. Nie widzi serwerów Windows, urządzeń sieciowych ani maszyn, na których go nie zainstalowano. Secvalis nie zapewnia zgodności z NIS2 ani z ustawą o KSC. Porządkuje dowody z obszaru podatności i wskazuje obszary, w których dowody trzeba zebrać poza produktem.

Jak wygląda mapa zgodności na danych przykładowej firmy, zobaczysz w publicznym demo, bez rejestracji.

Źródła

• EUR-Lex: dyrektywa NIS2 (UE) 2022/2555, art. 20, art. 21 i art. 23
• ELI: ustawa o zmianie ustawy o krajowym systemie cyberbezpieczeństwa, Dz.U. 2026 poz. 252, art. 1 pkt 16 (nowe brzmienie art. 8 ustawy o KSC) oraz art. 11 ustawy o KSC w brzmieniu po nowelizacji
• 3 kwietnia 2027: co w KSC ma już działać, a nie tylko istnieć na papierze