NIS2 artykuł 21(2)(a): dwa dokumenty, o które audytor pyta najpierw

15 sierpnia 2026 r. weszła w życie holenderska ustawa Cyberbeveiligingswet. Ponad 8 000 organizacji ma teraz obowiązek staranności, obowiązek rejestracji w NCSC oraz 24-godzinny termin zgłoszenia.
Żadna z nich nie zostanie zapytana najpierw o konsolę EDR.
Artykuł 21(2)(a) NIS2 to miejsce, od którego zaczyna się każda rozmowa z organem nadzoru: wasza polityka bezpieczeństwa sieci i systemów informatycznych oraz wasze ramy zarządzania ryzykiem. Dwa dokumenty. Oba zatwierdzone przez organ zarządzający. Oba opatrzone datą.
Większość organizacji nie ma żadnego z nich w formie, której faktycznie wymaga rozporządzenie. Oto czego wymaga artykuł 21(2)(a), środek po środku, i co to oznacza dla konsultantów, którzy mają to dostarczyć.
Artykuł 21(2)(a) to dwa obowiązki, nie jeden
Tekst dyrektywy jest krótki: „polityki analizy ryzyka i bezpieczeństwa systemów informatycznych". Czytany pobieżnie brzmi jak jeden dokument.
Rozporządzenie wykonawcze (UE) 2024/2690 widzi to inaczej. Jego załącznik dzieli artykuł 21(2)(a) na dwie odrębne sekcje główne:
- Sekcja 1 — Polityka bezpieczeństwa sieci i systemów informatycznych oraz role, obowiązki i uprawnienia.
- Sekcja 2 — Polityka zarządzania ryzykiem: ramy, monitorowanie zgodności i niezależny przegląd.
Rozporządzenie jest bezpośrednio wiążące dla dostawców DNS, rejestrów TLD, dostawców chmury, operatorów centrów danych, CDN, dostawców usług zarządzanych, dostawców zarządzanych usług bezpieczeństwa, internetowych platform handlowych, wyszukiwarek, platform społecznościowych i dostawców usług zaufania. Dla wszystkich pozostałych stanowi faktyczny punkt odniesienia, bo krajowe organy nadzoru nie mają nic bardziej szczegółowego do pomiaru.
Jeśli dostarczacie jedną połączoną „politykę bezpieczeństwa informacji" i uznajecie artykuł 21(2)(a) za zamknięty, spełniliście mniej więcej połowę.
Wasza polityka bezpieczeństwa ma jedenaście obowiązkowych elementów
Punkt 1.1.1 załącznika wymienia, co musi zawierać polityka najwyższego szczebla. Nie „powinna rozważyć" — musi określać:
- Podejście podmiotu do zarządzania bezpieczeństwem swoich sieci i systemów informatycznych
- Zgodność ze strategią i celami biznesowymi
- Określone cele bezpieczeństwa
- Zobowiązanie do ciągłego doskonalenia
- Zobowiązanie do zapewnienia zasobów — personelu, budżetu, procesów, narzędzi, technologii
- Zakomunikowanie i potwierdzenie przez właściwych pracowników i strony zewnętrzne
- Role i obowiązki zgodnie z punktem 1.2
- Dokumentację do przechowywania i okres jej przechowywania
- Wykaz polityk tematycznych
- Wskaźniki i mierniki do monitorowania wdrożenia i aktualnego poziomu dojrzałości
- Datę formalnego zatwierdzenia przez organy zarządzające
Punkt 5 najczęściej przesądza o negatywnym wyniku audytu. Polityka, która deklaruje bezpieczeństwo, ale nigdy budżetu ani etatów, nie spełnia 1.1.1(e). Punkt 10 również: jeśli nie potraficie pokazać wskaźników, którymi mierzycie własną politykę, macie deklarację intencji, a nie politykę.
Punkt 11 jest najtańszy do naprawienia i najczęściej brakujący. Polityka bez datowanego zatwierdzenia przez organ zarządzający jest — z punktu widzenia nadzoru — projektem.
Gdzie 21(2)(a) plasuje się wśród dziesięciu środków
Artykuł 21(2)(a) to pierwszy z dziesięciu środków zarządzania ryzykiem — i ten, z którego wywodzą się wszystkie pozostałe. Kontrola dostępu z 21(2)(i) musi być polityką tematyczną podporządkowaną waszej polityce najwyższego szczebla. Wymogi dotyczące kopii zapasowych z 21(2)(c) muszą wynikać z analizy wpływu na działalność, która zasila wasz plan postępowania z ryzykiem. Jeśli (a) jest zrobione źle, pozostałe dziewięć nie ma fundamentu.
Artykuł 21 — 10 Środków Cyberbezpieczeństwa NIS2
Artykuł 21
10 Środków Cyberbezpieczeństwa
Zarządzanie & Strategia
1Analiza ryzyka & polityki bezpieczeństwa informacji6Ocena skuteczności środków bezpieczeństwaIncydenty & Ciągłość
2Obsługa incydentów & zgłaszanie3Ciągłość działania & odtwarzanie po awariiŁańcuch Dostaw & Systemy
4Bezpieczeństwo łańcucha dostaw5Bezpieczeństwo w rozwoju systemów sieciowych i informatycznychKontrole Techniczne
8Kryptografia & szyfrowanie10Uwierzytelnianie wieloskładnikowe & bezpieczna komunikacjaLudzie & Zasoby
7Cyberhigiena & szkolenia9Bezpieczeństwo HR & kontrola dostępu
Organ zarządzający musi podpisać — i podpisać ponownie
Punkt 1.1.2 wymaga, aby polityka była przeglądana i w razie potrzeby aktualizowana przez organy zarządzające co najmniej raz w roku, a dodatkowo zawsze, gdy wystąpią poważne incydenty lub istotne zmiany w działalności lub ryzykach. Wynik każdego przeglądu musi być udokumentowany.
Dwie praktyczne konsekwencje.
Po pierwsze, „corocznie" to minimum, a nie harmonogram. Fuzja, nowa platforma chmurowa, incydent ransomware u kluczowego dostawcy — każde z nich uruchamia przegląd poza cyklem. Jeśli wasz klient wdrożył nowy ERP w marcu, a polityka była ostatnio przeglądana w styczniu, to luka, którą organ nadzoru znajdzie jednym pytaniem.
Po drugie, przegląd jest czynnością organu zarządzającego, nie działu IT. CISO może go przygotować. Organ zarządzający musi go przeprowadzić. To operacyjny wyraz osobistej odpowiedzialności z artykułu 20 — i powód, dla którego protokoły posiedzeń zarządu stały się dowodem audytowym.
Co najmniej jedna osoba musi raportować bezpośrednio zarządowi
Punkt 1.2.3 to jedno zdanie o nieproporcjonalnie dużych skutkach: co najmniej jedna osoba raportuje bezpośrednio organom zarządzającym w sprawach bezpieczeństwa sieci i systemów informatycznych.
Dla MSP to granica, której nie przekroczycie w imieniu klienta. Możecie prowadzić SOC, napisać politykę, utrzymywać rejestr ryzyka i przygotować materiały dla zarządu. Nie możecie być osobą, która raportuje zarządowi w ich imieniu, ponieważ odpowiedzialność leży wewnątrz podmiotu.
Punkt 1.2.5 dodaje rozdzielenie sprzecznych obowiązków, o ile ma to zastosowanie. Punkt 1.2.4 uznaje realia mniejszych podmiotów: bezpieczeństwo może być zadaniem wykonywanym dodatkowo obok istniejącej roli, a nie dedykowaną funkcją. Czego nie dopuszcza, to brak tego zadania.
Ramy zarządzania ryzykiem to proces, nie arkusz kalkulacyjny
Punkt 2.1.2 załącznika definiuje proces zarządzania ryzykiem cyberbezpieczeństwa w dziesięciu krokach. Podmioty muszą:
- Stosować metodykę zarządzania ryzykiem
- Ustalić poziom tolerancji ryzyka zgodny z apetytem na ryzyko
- Ustalić i utrzymywać kryteria ryzyka
- Identyfikować i dokumentować ryzyka w podejściu uwzględniającym wszystkie zagrożenia, wyraźnie obejmując strony trzecie i pojedyncze punkty awarii
- Analizować zagrożenie, prawdopodobieństwo, wpływ i poziom ryzyka, wykorzystując informacje o cyberzagrożeniach i dane o podatnościach
- Oceniać ryzyka względem kryteriów
- Identyfikować i priorytetyzować opcje postępowania
- Stale monitorować wdrażanie środków postępowania z ryzykiem
- Wskazać, kto odpowiada za każdy środek postępowania i w jakim terminie
- Udokumentować środki w planie postępowania z ryzykiem, wraz ze zrozumiałym uzasadnieniem każdego zaakceptowanego ryzyka szczątkowego
Zestawcie tę listę z przeciętnym rejestrem ryzyka klienta. Większość ma listę ryzyk z oceną czerwony-bursztynowy-zielony. Bardzo niewiele ma udokumentowaną metodykę, określony poziom tolerancji, wskazanych właścicieli z terminami i pisemne uzasadnienie ryzyka szczątkowego.
Wymóg „wszystkie zagrożenia" jest też szerszy, niż zakłada większość zespołów. Obejmuje zagrożenia fizyczne i środowiskowe, awarię dostawcy i niedostępność personelu — nie tylko cyberataki. Jeśli wasz rejestr zawiera wyłącznie scenariusze ataków, nie spełnia 2.1.2(d). Zwłaszcza ryzyko stron trzecich musi być rozpoznawalne w samym rejestrze, i tam łączy się z obowiązkami łańcucha dostaw z artykułu 21(2)(d).
Punkt 2.1.3 dodaje ograniczenie, które konsultanci powinni przyjąć z zadowoleniem: przy priorytetyzacji postępowania podmioty muszą ważyć koszt wdrożenia względem oczekiwanej korzyści. Proporcjonalność jest wpisana w rozporządzenie. Nie musicie rekomendować wszystkiego — musicie uzasadnić, co zrobiliście, a czego nie.
Ryzyko szczątkowe potrzebuje nazwiska
Punkt 2.1.1 to zdanie, które zmienia ład korporacyjny: wyniki oceny ryzyka i ryzyka szczątkowe muszą być zaakceptowane przez organy zarządzające lub przez osoby odpowiedzialne i uprawnione do zarządzania ryzykiem, przy odpowiednim raportowaniu do organów zarządzających.
To wymóg podpisu. „Zarząd został poinformowany" nie jest akceptacją. Musi istnieć decyzja, podjęta przez wskazaną z nazwiska osobę odpowiedzialną, i zapisana.
Punkt 2.1.4 wymaga następnie przeglądu oceny ryzyka i planu postępowania w zaplanowanych odstępach i co najmniej raz w roku, a także po poważnych incydentach lub istotnych zmianach. Ta sama logika wyzwalaczy co przy przeglądzie polityki, zastosowana do rejestru.
Monitorowanie zgodności i niezależny przegląd to dwie różne rzeczy
Punkt 2.2 wymaga regularnego przeglądu zgodności z własnymi politykami, standardami i zasadami, wraz z regularnym raportowaniem do organów zarządzających poprzez skuteczny system raportowania zgodności.
Punkt 2.3 wymaga czegoś zupełnie innego: niezależnego przeglądu podejścia podmiotu do zarządzania bezpieczeństwem — ludzi, procesów i technologii — przeprowadzonego przez osoby o odpowiednich kompetencjach audytowych, które nie podlegają służbowo obszarowi objętemu przeglądem.
Gdy rozdzielenie jest niemożliwe ze względu na wielkość, podmiot musi wprowadzić alternatywne środki gwarantujące bezstronność. Nie może po prostu pominąć przeglądu.
To najwyraźniejsza szansa komercyjna w artykule 21(2)(a) dla konsultantów i vCISO. Dziesięcioosobowy podmiot ważny nie wystawi wewnętrznie niezależnego recenzenta. Zewnętrzny jest tym alternatywnym środkiem. Uwaga: 2.3 występuje obok, a nie zamiast oceny skuteczności z artykułu 21(2)(f) — organy nadzoru będą oczekiwać obu.
Organy nadzoru już nie czekają
Presja przychodzi z dwóch stron jednocześnie.
Krajowo: Holandia weszła w życie 15 sierpnia 2026 r. z ustawą Cyberbeveiligingswet, obejmującą 18 sektorów i ponad 8 000 podmiotów. Niemieckie okno rejestracji zamknęło się miesiące temu, a duża część podmiotów objętych zakresem wciąż nie była zarejestrowana. Austria, Szwecja, Polska i Portugalia — wszystkie obowiązują.
Z Brukseli: 8 lipca 2026 r. Komisja Europejska skierowała Irlandię, Hiszpanię, Francję i Holandię do Trybunału Sprawiedliwości UE z powodu niepełnej transpozycji, wnioskując o sankcje finansowe. Państwa członkowskie opóźniające transpozycję są mocno naciskane — co historycznie przekłada się na krajowe organy chętne wykazać aktywność egzekucyjną, gdy tylko ich ustawa zacznie obowiązywać.
Status Wdrożenia NIS2 według Kraju (2025–2026)
W pełni obowiązuje
BelgiaChorwacjaWęgryLitwaŁotwaWłochy6 krajówPrzyjęta — koniec 2025
NiemcyCzechyFinlandia3 krajówW trakcie — oczekiwane 2026
HolandiaFrancjaHiszpaniaPolskaAustriaSzwecjaIrlandia7 krajów
Co się dzieje, gdy brakuje 21(2)(a)
Brakująca lub niedatowana polityka rzadko jest ustaleniem kończącym kontrolę. To ustalenie, które ją rozpoczyna. Jeśli polityka najwyższego szczebla nie jest zatwierdzona, podległe jej polityki tematyczne nie mają mandatu. Jeśli rejestr ryzyka nie ma metodyki, każda dalsza decyzja o zabezpieczeniach staje się nieuzasadniona.
Stamtąd narzędzia nadzorcze eskalują: wiążące polecenia, obowiązkowe audyty na koszt podmiotu, publiczne ujawnienie niezgodności, administracyjne kary pieniężne do 10 mln euro lub 2% światowego rocznego obrotu dla podmiotów kluczowych oraz — dla podmiotów kluczowych — czasowe zawieszenie pełnienia funkcji kierowniczych.
Eskalacja sankcji NIS2 — Poza karą finansową
!Zdarzenie wyzwalające
Wykryto niezgodność lub wystąpił incydent
Organ nadzorczy identyfikuje lukę w zgodności lub organizacja nie spełnia wymagań NIS2
Organy mogą nałożyć▼Sankcje niefinansowe1Nakazy zgodności z wiążącymi terminami
2Obowiązkowe audyty bezpieczeństwa na Twój koszt
3Publiczne ujawnienie naruszeń
4Wiążące instrukcje dotyczące konkretnych środków bezpieczeństwa
Eskaluje do▼Konsekwencje operacyjne i osobiste1Zawieszenie certyfikatów lub licencji operacyjnych
2Tymczasowy zakaz pełnienia funkcji zarządczych dla osób
3Publiczne wskazanie odpowiedzialnych osób fizycznych
Zdarzenie wyzwalająceNiefinansoweOperacyjne / osobiste
Plan na 30 dni dla konsultantów
Jeśli wspieracie klientów objętych zakresem, ta kolejność najszybciej daje możliwe do obrony dowody:
Dni 1–5. Pobierzcie aktualną politykę bezpieczeństwa klienta. Sprawdźcie ją względem jedenastu elementów z punktu 1.1.1. Większość polegnie na zasobach, wskaźnikach i dacie zatwierdzenia.
Dni 6–10. Ustalcie, czy ktokolwiek raportuje bezpośrednio organowi zarządzającemu w sprawach bezpieczeństwa. Jeśli nie — wskażcie tę osobę i zaprotokołujcie to.
Dni 11–20. Przebudujcie rejestr ryzyka wokół 2.1.2: udokumentowana metodyka, określona tolerancja, zakres obejmujący wszystkie zagrożenia wraz z dostawcami i pojedynczymi punktami awarii, wskazani właściciele, terminy i pisemne uzasadnienie ryzyka szczątkowego.
Dni 21–25. Przedstawcie politykę i plan postępowania z ryzykiem organowi zarządzającemu. Uzyskajcie formalne zatwierdzenie, z datą i w protokole.
Dni 26–30. Określcie rytm monitorowania zgodności z 2.2 i zaplanujcie pierwszy niezależny przegląd z 2.3, z wyraźną notatką o tym, jak zapewniono bezstronność.
To wytwarza dwa artefakty, o które organ nadzoru pyta w pierwszej kolejności — wraz ze śladem ładu korporacyjnego, który dowodzi, że są prawdziwe.
Jeśli chcecie szybko ocenić, jak klient wypada wobec artykułu 21, zanim ustalicie zakres projektu, uruchomcie quick scan NIS2. Mapuje luki w kilka minut, dzięki czemu wycenicie pracę zamiast zgadywać.
Wersja krótka
Artykuł 21(2)(a) to nie narzut dokumentacyjny. To środek, który czyni każdy inny środek możliwym do obrony. Polityka z jedenastoma określonymi elementami i datowanym zatwierdzeniem zarządu. Ramy ryzyka z metodyką, wskazanymi właścicielami i zaakceptowanym ryzykiem szczątkowym. Monitorowanie zgodności i niezależny przegląd przez kogoś spoza linii podległości służbowej.
Cała reszta artykułu 21 opiera się na tym. Zbudujcie to najpierw.
