Dyrektywa (UE) 2022/2555, znana jako NIS2, zastąpiła pierwotną dyrektywę NIS z 2016 r., a termin transpozycji do prawa krajowego upłynął 17 października 2024 r. Znacząco poszerza ona krąg podmiotów objętych unijnym prawem cyberbezpieczeństwa oraz podnosi wymagania w zakresie zarządzania ryzykiem, ładu korporacyjnego i zgłaszania incydentów. Jeśli prowadzisz aplikacje webowe, API lub usługi online w UE, ten artykuł wyjaśnia — w praktyczny, nieprawniczy sposób — gdzie możesz się znajdować i jak testy bezpieczeństwa wspierają Twoje obowiązki.
Kto jest objęty
NIS2 dotyczy podmiotów średnich i dużych (co do zasady 50+ pracowników lub obrót 10 mln € +) działających w wymienionych sektorach. Dzieli je na dwie kategorie:
- Podmioty kluczowe (Załącznik I): energetyka, transport, bankowość, infrastruktura rynku finansowego, zdrowie, woda pitna i ścieki, infrastruktura cyfrowa (DNS, rejestry TLD, chmura, centra danych, CDN), zarządzanie usługami ICT, administracja publiczna i przestrzeń kosmiczna.
- Podmioty ważne (Załącznik II): usługi pocztowe, gospodarka odpadami, chemikalia, żywność, produkcja, dostawcy cyfrowi (platformy handlowe, wyszukiwarki, sieci społecznościowe) i badania.
Progi wielkości nie są jedynym kryterium — niektóre podmioty są objęte niezależnie od wielkości (np. rejestry DNS i TLD czy kwalifikowani dostawcy usług zaufania). Co istotne, NIS2 sięga Twojego łańcucha dostaw: nawet jeśli sam nie jesteś objęty bezpośrednio, objęty klient przeniesie te wymagania na Ciebie umownie.
Obowiązki zarządzania ryzykiem (art. 21)
Artykuł 21 wymaga odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych w podejściu uwzględniającym wszystkie zagrożenia. Dyrektywa wskazuje minimalny zestaw, który dobrze odwzorowuje uznane ramy, takie jak ISO/IEC 27001 i NIST Cybersecurity Framework:
- Analiza ryzyka i polityki bezpieczeństwa systemów informacyjnych
- Obsługa incydentów (wykrywanie, reagowanie, odtwarzanie)
- Ciągłość działania, zarządzanie kopiami zapasowymi i zarządzanie kryzysowe
- Bezpieczeństwo łańcucha dostaw, w tym relacje z bezpośrednimi dostawcami
- Bezpieczeństwo w pozyskiwaniu, rozwoju i utrzymaniu — w tym obsługa i ujawnianie podatności
- Polityki oceny skuteczności środków (czyli testowanie i audyt)
- Podstawowa higiena cybernetyczna i szkolenia
- Polityki kryptografii i szyfrowania
- Kontrola dostępu, zarządzanie aktywami i uwierzytelnianie wieloskładnikowe
Dwie kwestie zasługują na podkreślenie. Po pierwsze, organy zarządzające muszą zatwierdzać i nadzorować te środki i mogą ponosić odpowiedzialność (art. 20) — cyberbezpieczeństwo to dziś obowiązek na poziomie zarządu, nie tylko sprawa IT. Po drugie, wymóg oceny skuteczności sprawia, że testowanie staje się nieodzowne.
Zgłaszanie incydentów: zegar 24/72 h (art. 23)
NIS2 nakłada rygorystyczny, wieloetapowy harmonogram dla incydentów istotnych (powodujących poważne zakłócenia operacyjne, straty finansowe lub istotną szkodę dla innych):
- W ciągu 24 godzin — wczesne ostrzeżenie do CSIRT lub właściwego organu, ze wskazaniem, czy incydent może być bezprawny/złośliwy oraz czy może mieć skutek transgraniczny.
- W ciągu 72 godzin — zgłoszenie incydentu z wstępną oceną, wagą, wpływem i wskaźnikami naruszenia (IoC).
- Na żądanie — pośrednia aktualizacja statusu.
- W ciągu miesiąca — raport końcowy obejmujący przyczynę źródłową, działania naprawcze i skutek transgraniczny.
Te terminy są napięte. Ich dotrzymanie wymaga logowania, wykrywania i przećwiczonego wcześniej scenariusza reagowania na incydenty — a nie improwizacji w trakcie ataku.
Jak testy penetracyjne i audyty wspierają zgodność
NIS2 nie narzuca konkretnej metodyki testów, ale test penetracyjny to najbardziej bezpośredni dowód, że oceniłeś skuteczność środków i że Twój proces obsługi podatności działa. Konkretnie testowanie wspiera kilka punktów art. 21 naraz:
- Obsługa podatności — test oparty na OWASP Top 10 i OWASP Web Security Testing Guide (WSTG) ujawnia problemy jak nieprawidłowa kontrola dostępu (A01), wstrzyknięcia (A03) i SSRF (A10), zanim zrobią to atakujący.
- Priorytetyzacja z CVSS — podatności ocenione w CVSS v3.1/v4.0 pozwalają na triage i wykazanie podejścia opartego na ryzyku, a mapowanie na CWE i MITRE ATT&CK pokazuje analityczną rzetelność.
- Ocena skuteczności — ponowny test po naprawie daje udokumentowany dowód, że poprawki faktycznie zamknęły lukę.
- Zapewnienie dla łańcucha dostaw — raport, którym możesz się podzielić, dostarcza objętym klientom dowodów wymaganych przez ich własne obowiązki NIS2.
- Gotowość na incydenty — ćwiczenia red team / purple team weryfikują, czy Twój łańcuch wykrywania i zgłaszania 24/72 h faktycznie zadziała.
Rozsądna kadencja to co najmniej test raz w roku oraz ponowny test po każdej istotnej zmianie systemów dostępnych z internetu, uzupełniony ciągłym skanowaniem podatności między zleceniami.
Praktyczne kolejne kroki
- Ustal swój zakres: sektor (Załącznik I/II), progi wielkości i ewentualne kryteria niezależne od wielkości.
- Odwzoruj obecne zabezpieczenia na minimalny zestaw z art. 21; potraktuj ISO/IEC 27001 lub NIST CSF jako szkielet.
- Zbuduj i przećwicz plan reagowania na incydenty zgodny z harmonogramem 24/72 h / jeden miesiąc.
- Zleć test penetracyjny oparty na OWASP/WSTG z podatnościami ocenionymi w CVSS i ponownym testem po naprawie.
- Przenieś analogiczne wymagania na własnych dostawców.
Ten artykuł to praktyczne wskazówki, a nie porada prawna. Dokładne obowiązki zależą od ustawy transponującej w Twoim państwie członkowskim i klasyfikacji podmiotu — potwierdź szczegóły u wykwalifikowanego prawnika i w krajowym CSIRT.