Test penetracyjny NIS2: zgodność z Art. 21 i środki techniczne

Dyrektywa NIS2 (UE 2022/2555), obowiązująca we wszystkich państwach członkowskich UE od 17 października 2024 r., rozszerza obowiązkowe wymogi cyberbezpieczeństwa na około 160 000 podmiotów w 18 sektorach krytycznych. Art. 21 wymaga konkretnie 'odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych' do zarządzania ryzykami związanymi z sieciami i systemami informatycznymi. Test penetracyjny jest podstawowym mechanizmem technicznym, który właściwe organy akceptują jako dowód zgodności z Art. 21. Ten przewodnik wyjaśnia, czego faktycznie wymaga NIS2, kto kwalifikuje się jako podmiot kluczowy a kto jako ważny, czego oczekują organy nadzoru oraz jak zbudować program testowy, który spełni wymagania krajowych organów właściwych.

Uruchom darmowy skan NIS2

Written by Malte Wagenbach

Founder of Matproof Security. Specialized in AI-driven penetration testing and EU compliance (DORA, NIS2, ISO 27001, SOC 2).

Last reviewed: May 17, 2026

Dlaczego NIS2 czyni test penetracyjny faktycznie obowiązkowym środkiem kontroli

Art. 21 ust. 2 dyrektywy NIS2 wymienia dziesięć minimalnych środków bezpieczeństwa, które muszą być wdrożone. Wśród nich: 'obsługa incydentów', 'ciągłość działania', 'bezpieczeństwo łańcucha dostaw', 'bezpieczeństwo sieci i systemów informatycznych', 'polityki i procedury oceny skuteczności środków zarządzania ryzykiem cyberbezpieczeństwa' oraz 'podstawowe praktyki cyberhigieny i szkolenia z zakresu cyberbezpieczeństwa'. Sformułowanie 'polityki i procedury oceny skuteczności środków zarządzania ryzykiem' (Art. 21 ust. 2 lit. g) stanowi prawną podstawę dla testów penetracyjnych. Właściwe organy, w tym ENISA, BSI, ANSSI, ACN, NCSC-NL, CCN-CERT oraz krajowe organy implementujące, konsekwentnie wskazują, że samo skanowanie podatności nie stanowi wystarczającej oceny skuteczności. Test penetracyjny z udokumentowanym zakresem, metodyką, dowodem eksploitacji oraz planem naprawczym jest akceptowanym standardem. Poza obowiązkiem technicznym, NIS2 wprowadziła osobistą odpowiedzialność organów zarządzających (Art. 20): członkowie zarządu mogą zostać ukarani osobistymi karami pieniężnymi i czasowym zakazem pełnienia funkcji kierowniczych, jeżeli nie zapewnili odpowiednich środków bezpieczeństwa, w tym regularnych testów. Jest to istotna zmiana w porównaniu z NIS1, gdzie egzekwowanie koncentrowało się wyłącznie na samym podmiocie.

Art. 21 ust. 2 lit. g NIS2 wymaga udokumentowanych procedur oceny skuteczności środków bezpieczeństwa - test penetracyjny jest standardową w branży metodyką akceptowaną przez organy nadzoru UE jako dowód zgodności.
Art. 20 NIS2 czyni organy zarządzające osobiście odpowiedzialnymi za zarządzanie cyberbezpieczeństwem. Członkowie zarządu, którzy nie mogą wykazać, że przeglądali aktualne wyniki testów penetracyjnych i nadzorowali naprawy, ryzykują osobistymi sankcjami.
Podmioty kluczowe (energetyka, transport, bankowość, infrastruktura rynku finansowego, ochrona zdrowia, woda pitna, ścieki, infrastruktura cyfrowa, zarządzanie usługami ICT, administracja publiczna, przestrzeń kosmiczna) podlegają karom do €10 mln lub 2 % globalnego rocznego obrotu (zależnie od tego, która kwota jest wyższa) zgodnie z Art. 34.
Podmioty ważne (usługi pocztowe, gospodarka odpadami, produkcja chemikaliów, żywność, produkcja wyrobów medycznych/komputerów/elektroniki/pojazdów, dostawcy usług cyfrowych w tym chmura, centra danych, CDN, platformy handlowe online, wyszukiwarki, sieci społecznościowe) podlegają karom do €7 mln lub 1,4 % globalnego rocznego obrotu.
Właściwe organy mogą przeprowadzać kontrole na miejscu i wymagać dostępu do dokumentacji testów penetracyjnych w dowolnym momencie - podmioty, które nie potrafią okazać raportu z testu z ostatnich 12 miesięcy, narażają się na natychmiastowe ryzyko egzekucyjne.
Art. 21 ust. 3 NIS2 wymaga, aby podmioty uwzględniały 'aktualny stan wiedzy' w środkach bezpieczeństwa - coroczny test punktowy nie odzwierciedla już aktualnego stanu wiedzy; testowanie ciągłe lub kwartalne staje się oczekiwaniem organów nadzoru.
Obowiązki w zakresie łańcucha dostaw (Art. 21 ust. 2 lit. d NIS2) oznaczają, że podmioty kluczowe muszą oceniać bezpieczeństwo swojego łańcucha dostaw ICT, w tym wymagać dowodów testów penetracyjnych od krytycznych dostawców SaaS i infrastruktury.

Co musi obejmować test penetracyjny zgodny z NIS2

Bezpieczeństwo sieci i systemów informatycznych (Art. 21 ust. 2 lit. e): enumeracja zewnętrznej powierzchni ataku, eksponowane usługi, konfiguracja TLS/SSL (RFC 8446), higiena DNS, podatności typu subdomain takeover
Uwierzytelnianie i kontrola dostępu (Art. 21 ust. 2 lit. a, wstępny warunek obsługi incydentów): odporność na ataki na poświadczenia, techniki obejścia MFA, zarządzanie sesjami, słabości podpisów JWT (CWE-327), przepływy OAuth 2.0 (RFC 6749 / PKCE RFC 7636)
Zarządzanie podatnościami i poprawkami (Art. 21 ust. 2 lit. h, podstawowa cyberhigiena): skanowanie SCA względem NVD/GHSA, wykrywanie CVE-2024-43481 (Next.js middleware bypass, CVSS 9.1), CVE-2024-4577 (PHP-CGI argument injection, CVSS 9.8), CVE-2023-44487 (HTTP/2 Rapid Reset), dryf wersji zależności
Bezpieczeństwo aplikacji - OWASP Top 10 (2021): A01 Broken Access Control, A02 Cryptographic Failures, A03 Injection (SQL, NoSQL, LDAP, command), A05 Security Misconfiguration, A06 Vulnerable and Outdated Components, A07 Identification and Authentication Failures
Bezpieczeństwo API - OWASP API Top 10 (2023): API1 Broken Object Level Authorization, API2 Broken Authentication, API3 Broken Object Property Level Authorization, API4 Unrestricted Resource Consumption, API5 Broken Function Level Authorization
Ciągłość działania i odporność (Art. 21 ust. 2 lit. b): testowanie kontroli dostępu do kopii zapasowych, ścieżek symulacji ransomware, dostępności mechanizmów odzyskiwania administracyjnego
Bezpieczeństwo łańcucha dostaw (Art. 21 ust. 2 lit. d): ryzyka ładowania skryptów stron trzecich, walidacja SRI (Subresource Integrity), podatne tranzytywne zależności npm/PyPI/Maven
Zdolność wykrywania incydentów: weryfikacja, czy aktywność atakująca podczas testów generuje alerty SIEM/SOAR - 'zaatakowaliśmy, a Państwo tego nie zauważyli' to wynik podlegający zgłoszeniu zgodnie z Art. 21 ust. 2 lit. a NIS2
Konfiguracja nagłówków bezpieczeństwa i transportu: HSTS (RFC 6797), CSP (W3C Level 2), Referrer-Policy, Permissions-Policy, błędna konfiguracja CORS, DNSSEC, DMARC (RFC 7489)
Konfiguracja infrastruktury chmurowej (plan Growth): ścieżki eskalacji uprawnień IAM, nadmiernie permisywne polityki S3 bucket, eksponowane endpointy metadanych chmury (SSRF w stylu CVE-2019-11510), błędna konfiguracja serverless

Sample finding

Critical

Obejście uwierzytelniania przez niesanityzowaną odpowiedź SAML - naruszenie Art. 21 ust. 2 lit. i NIS2

Dostawca usług przetwarza odpowiedzi uwierzytelniające SAML 2.0 od dostawcy tożsamości bez walidacji integralności podpisu XML na elemencie assertion. Aplikacja waliduje zewnętrzny podpis odpowiedzi, ale akceptuje dowolne niepodpisane asercje osadzone wewnątrz. Wykorzystując technikę 'XML Signature Wrapping' (XSW), tester był w stanie sfałszować asercję uwierzytelniającą podającą się za użytkownika administracyjnego, całkowicie omijając SSO. Wszystkie funkcje administracyjne były dostępne bez ważnych poświadczeń od dostawcy tożsamości. CVE-2023-36661 (python3-saml, CVSS 9.8) oraz CVE-2022-31197 (ruby-saml) opisują tę samą klasę podatności. Narusza to Art. 21 ust. 2 lit. i NIS2 ('polityki i procedury dotyczące kryptografii oraz, w stosownych przypadkach, szyfrowania') oraz Art. 21 ust. 2 lit. a ('obsługa incydentów').

Fix: Walidować podpis XML konkretnie na elemencie Assertion, nie tylko na kopercie. Używać dobrze utrzymywanej biblioteki SAML, która domyślnie wymusza walidację podpisu na poziomie asercji (np. OneLogin SAML2 dla Pythona, xmlsec dla Node.js). Włączyć tryb strict w konfiguracji biblioteki. Regularnie przeglądać CVE bibliotek SAML - biblioteki parsujące SAML mają trwałą historię podatności XSW. W konfiguracji dostawcy tożsamości: całkowicie zabronić niepodpisanych asercji, wymagać przepływów inicjowanych przez SP, ustawić krótkie TTL asercji (maks. 5 minut). Po naprawie przetestować ponownie z użyciem Matproof Sentinel poprzez odtworzenie sfałszowanego żądania asercji.

Reference: CVE-2023-36661 python3-saml · CVE-2022-31197 ruby-saml · OWASP A07:2021 Identification and Authentication Failures · NIS2 Art. 21 ust. 2 lit. a oraz i · CWE-347 Improper Verification of Cryptographic Signature

Opcje testów penetracyjnych dla NIS2

—	Free scan	Matproof Sentinel	Traditional consultancy
Automated scan engine	✓ (3-min preview)	✓ Full scan	✗ Manual only
OWASP Top 10 coverage	Partial	✓ Complete	✓ Complete
Proof-of-exploit evidence	✗	✓ Per finding	✓ Per finding
Regulatory mapping (DORA/NIS2/ISO 27001)	✗	✓ Automated	✓ Manual
Audit-ready PDF report	✗	✓ Instant	✓ 2–4 weeks delivery
Continuous / recurring scans	✗	✓ Per deploy	✗ Annual engagement
Time to first result	~3 min	~30 min full scan	2–4 weeks
Price	€0	From €149	€8,000–€25,000
Source code review (SAST)	✗	✓ On Growth plan	✓ Scoped engagement
API testing (REST/GraphQL)	✗	✓ Automated	✓ Manual

Matproof Sentinel dla zgodności z NIS2

Single Run

€149 one-time

1 full pentest scan
AI-prioritized findings with CVSS 3.1
Proof-of-exploit per finding
Audit-ready PDF report
Regulatory mapping (DORA, NIS2, ISO 27001)

Unlimited scans (up to 3 domains)
Continuous monitoring
CI/CD integration (GitHub, GitLab)
All regulatory mappings
Priority support

Start Starter →

Growth

€799 / month

Unlimited scans + domains
Authenticated / White-Box testing
API & cloud infrastructure tests
Dedicated security account manager
24h SLA response time

Contact for Growth →

Najczęstsze pytania dotyczące testów penetracyjnych NIS2

Które podmioty muszą spełniać wymogi bezpieczeństwa NIS2 Art. 21?

NIS2 obejmuje dwie kategorie. Podmioty kluczowe to operatorzy w sektorach: energetyka (elektryczność, gaz, ropa, wodór, ogrzewanie/chłodzenie sieciowe), transport (lotniczy, kolejowy, wodny, drogowy), bankowość, infrastruktura rynku finansowego, ochrona zdrowia (szpitale, produkcja farmaceutyczna, wyroby medyczne), woda pitna, ścieki, infrastruktura cyfrowa (punkty wymiany ruchu IXP, dostawcy DNS, rejestry TLD, dostawcy chmury, centra danych, CDN, dostawcy usług zaufania, publiczne komunikacje elektroniczne), zarządzanie usługami ICT (dostawcy usług zarządzanych B2B, dostawcy zarządzanych usług bezpieczeństwa), niektóre organy administracji publicznej oraz przestrzeń kosmiczna. Podmioty ważne obejmują usługi pocztowe i kurierskie, gospodarkę odpadami, produkcję/dystrybucję chemikaliów, produkcję/przetwarzanie/dystrybucję żywności, producentów wyrobów medycznych/komputerów/elektroniki/pojazdów/maszyn, dostawców usług cyfrowych (platformy handlowe online, wyszukiwarki internetowe, sieci społecznościowe) oraz organizacje badawcze. Próg wielkości to zazwyczaj 50+ pracowników lub €10 mln+ rocznego obrotu - mikro i małe przedsiębiorstwa są wyłączone, chyba że działają w infrastrukturze cyfrowej lub zostały zidentyfikowane jako krytyczne przez krajowe organy właściwe.

Co w praktyce oznacza 'test penetracyjny zgodnie z Art. 21'?

Art. 21 nie używa wprost terminu 'test penetracyjny'. Wymaga od podmiotów oceny skuteczności środków zarządzania ryzykiem cyberbezpieczeństwa. W praktyce właściwe organy zaakceptowały testy penetracyjne jako główny mechanizm techniczny tej oceny. Test musi być: (1) przeprowadzony przez osoby z udokumentowanymi kompetencjami technicznymi (RTS dotyczące raportowania z Art. 23 oraz wytyczne ENISA odwołują się do kwalifikacji na poziomie OSCP/CREST), (2) zakresem objąć systemy krytyczne zgodnie z inwentarzem aktywów, (3) udokumentowany z odwołaniem do metodyki (OWASP Testing Guide v4.2, PTES lub NIST SP 800-115), (4) poparty dowodem eksploitacji dla istotnych wyników oraz (5) uzupełniony planem naprawczym z harmonogramem i potwierdzeniem retestu.

Jak często NIS2 wymaga testu penetracyjnego?

NIS2 nie określa minimalnej częstotliwości testowania - wymaga, aby środki były 'odpowiednie i proporcjonalne' i odzwierciedlały 'aktualny stan wiedzy'. Wytyczne ENISA i publikacje krajowych organów (BSI, ANSSI, NCSC-NL) konsekwentnie wskazują testowanie roczne jako bazę dla większości podmiotów. Po istotnych zmianach w architekturze ICT oczekiwany jest nowy test. Dla ciągłej zgodności i spełnienia standardu 'aktualnego stanu wiedzy', testowanie kwartalne lub ciągłe testowanie automatyczne (jak zapewnia Matproof Sentinel) coraz częściej spełnia oczekiwania organów nadzoru. Powszechne praktyczne podejście: roczny ustrukturyzowany pentest u zewnętrznego dostawcy + ciągłe skanowanie (Matproof Sentinel) + testy ad hoc po znaczących wydaniach.

Jakie są kary NIS2 i czy zarząd może odpowiadać osobiście?

Dla podmiotów kluczowych: do €10 mln lub 2 % globalnego rocznego obrotu, w zależności która kwota jest wyższa (Art. 34 ust. 4 NIS2). Dla podmiotów ważnych: do €7 mln lub 1,4 % globalnego rocznego obrotu, w zależności która kwota jest wyższa. To wartości maksymalne - faktyczne kary zależą od transpozycji krajowej i uznania regulatora. Nowy wymiar osobistej odpowiedzialności (Art. 20): organy zarządzające, zazwyczaj zarząd, mogą być pociągnięte osobiście do odpowiedzialności, jeśli nie zatwierdziły odpowiednich środków cyberbezpieczeństwa, nie nadzorowały ich wdrożenia ani nie zapewniły szkoleń. Indywidualni członkowie zarządu, którzy nie potrafią wykazać, że przeglądali aktualne raporty z testów penetracyjnych i widzieli dowody działań naprawczych, mogą podlegać osobistym karom pieniężnym i czasowym zakazom pełnienia funkcji kierowniczych. Dlatego raporty z testów penetracyjnych muszą być widoczne dla zarządu, a nie tylko trzymane w zespole bezpieczeństwa.

Czy skan Matproof Sentinel wystarczy do zgodności z NIS2 Art. 21?

Matproof Sentinel zapewnia automatyczne testy techniczne, które bezpośrednio wspierają generowanie dowodów dla NIS2 Art. 21. Gotowy do audytu raport PDF zawiera: pokrycie OWASP Top 10 i API Top 10, dowód eksploitacji dla każdego wyniku, ocenę krytyczności CVSS 3.1, mapę drogową napraw oraz jawne mapowanie do wymagań Art. 21 NIS2. Dla większości podmiotów ważnych (Załącznik II), automatyczne testowanie Sentinel uzupełnione corocznym ustrukturyzowanym testem zewnętrznym spełni oczekiwania organów nadzoru. Dla podmiotów kluczowych (Załącznik I) w sektorach wysokiego ryzyka (energetyka, bankowość, ochrona zdrowia, infrastruktura cyfrowa), zalecamy łączenie ciągłego skanowania Sentinel z corocznymi lub półrocznymi ustrukturyzowanymi testami zewnętrznymi u wykwalifikowanych dostawców - niektóre organy krajowe opublikowały wytyczne sektorowe wymagające testów zewnętrznych prowadzonych przez ludzi.

Jaka jest różnica między NIS2 a DORA dla podmiotów finansowych?

Dla podmiotów finansowych podlegających zarówno NIS2, jak i DORA, obowiązuje zasada lex specialis: DORA ma pierwszeństwo jako regulacja sektorowa. Art. 4 dyrektywy NIS2 wprost stanowi, że sektorowe akty prawne UE mające zastosowanie do podmiotów kluczowych lub ważnych (w tym DORA) stanowią szczegółowe przepisy dotyczące cyberbezpieczeństwa równoważne NIS2. Podmioty finansowe nadzorowane na podstawie DORA nie są zatem zobowiązane do oddzielnego spełniania Art. 21 NIS2 - spełnienie Art. 24 DORA pokrywa równoważny obowiązek. Jeżeli jednak podmiot finansowy posiada spółki zależne w sektorach niefinansowych, które są objęte NIS2 (np. grupa ubezpieczeniowa prowadząca spółkę zależną w energetyce), NIS2 ma zastosowanie do tych spółek zależnych.

Jaka dokumentacja jest wymagana do audytu Art. 21 NIS2?

Właściwe organy przeprowadzające kontrole (Art. 32-33 NIS2) zazwyczaj wymagają: (1) inwentarza aktywów obejmującego krytyczne systemy ICT, (2) metodyki oceny ryzyka (ISO 27005, NIST RMF lub metodyka ENISA), (3) raportów z testów penetracyjnych z ostatnich 12-24 miesięcy z udokumentowanym zakresem i metodyką, (4) dokumentacji dowodu eksploitacji dla istotnych wyników, (5) rejestru śledzenia napraw pokazującego status każdego wyniku (otwarty, w toku, rozwiązany, zaakceptowany z uzasadnieniem), (6) dowodów, że zarząd przeglądał i zatwierdził plan naprawczy, (7) dowodów z retestu potwierdzających, że wyniki krytyczne i wysokie zostały rozwiązane. Matproof Sentinel automatycznie generuje punkty 3, 4 i 5. Punkty 6 i 7 są wspierane przez raporty z retestów.

Jak NIS2 stosuje się do testowania bezpieczeństwa łańcucha dostaw?

Art. 21 ust. 2 lit. d NIS2 wymaga, aby podmioty zarządzały bezpieczeństwem w łańcuchu dostaw, w tym aspektami bezpieczeństwa relacji między każdym podmiotem a jego bezpośrednimi dostawcami lub usługodawcami. W praktyce oznacza to, że podmioty kluczowe i ważne muszą oceniać postawę bezpieczeństwa swoich krytycznych dostawców SaaS, chmury i infrastruktury. Mechanizmy obejmują: umowne wymagania, aby dostawcy przeprowadzali roczne testy penetracyjne i dostarczali raporty (z odpowiednimi NDA/poufnością), włączenie wymagań pentestów do kryteriów zakupowych, kontrole wyrywkowe raportów bezpieczeństwa dostawców oraz, gdy technicznie możliwe, włączenie API dostawców i punktów integracji w zakres testu penetracyjnego samego podmiotu. Dla najbardziej krytycznych relacji w łańcuchu dostaw niektóre podmioty organizują 'testy łączone', w których dzielą zakres testu penetracyjnego ze swoim krytycznym dostawcą - jest to wprost przewidziane przez ramy NIS2.

Go deeper — related blog articles

Rozpocznij test penetracyjny zgodny z NIS2

Pobierz darmowy 3-minutowy skan powierzchni, aby zobaczyć aktualną ekspozycję - bez logowania, bez karty kredytowej. Pełny skan Matproof Sentinel dostarcza gotowy do audytu raport PDF zmapowany do wymagań Art. 21 NIS2 w mniej niż 60 minut. Od €149 jednorazowo lub €299/miesiąc za ciągłe pokrycie zgodności.