Penetration testing compliance: Jak zapewnić zgodność i skuteczność

Nie każdy raport z testu penetracyjnego zostanie zaakceptowany przez audytora. To zdanie brzmi zaskakująco, ale w praktyce właśnie ten problem dotyka znaczną część zespołów bezpieczeństwa w Europie. Firmy inwestują w pentesty, otrzymują dokumenty z listą podatności, a potem okazuje się, że nie spełniają wymogów ISO 27001, GDPR ani żadnego innego standardu. Pentest sam w sobie to nie compliance. Compliance to zestaw wymagań dotyczących zakresu, autoryzacji, metodyki i dokumentacji, bez których żaden test nie ma wartości dowodowej.

Spis treści

• Czym jest penetration testing compliance i dlaczego nie każdy pentest się liczy

• Jakie przepisy i standardy wymagają pentestów zgodnych z compliance w Europie

• Pentest a assessment: Co spełnia wymogi, a co nie?

• Skuteczne wdrożenie: Jak przygotować i rozliczyć pentest zgodny z compliance

• Czego brakuje w większości pentestów na potrzeby compliance - nasze doświadczenia

• Narzędzia i wsparcie dla skutecznych testów penetracyjnych zgodnych z compliance

• Najczęściej zadawane pytania

Kluczowe Wnioski

Czym jest penetration testing compliance i dlaczego nie każdy pentest się liczy

Zacznijmy od jasnego rozróżnienia. Penetration testing compliance to coś więcej niż samo wykonanie testu. SANS Glossary definiuje sam pentest jako kontrolowaną symulację ataku w celu weryfikacji odporności systemu - termin "penetration testing compliance" wykracza poza tę definicję i oznacza dopasowanie takich testów do konkretnych regulacji i polityk: z legalnym, autoryzowanym i kontrolowanym przebiegiem oraz wartością dowodową dla audytu. Nie chodzi tu o to, czy ktoś uruchomił Nmap i Metasploit. Chodzi o to, czy cały proces spełnia wymogi formalne i proceduralne narzucone przez regulatora lub standard.

W praktyce compliance wymaga kilku elementów, których zwykły test penetracyjny może nie zawierać:

• Pisemna autoryzacja: Każdy test musi mieć wyraźne zezwolenie właściciela systemu. Bez dokumentu autoryzacyjnego test nie istnieje dla audytora.

• Zdefiniowany zakres (scope): Co dokładnie jest testowane, jakie adresy IP, systemy, aplikacje i w jakim oknie czasowym.

• Rules of engagement: Zasady określające, jakie techniki są dozwolone, co jest zakazane i kto jest punktem kontaktowym w sytuacjach kryzysowych.

• Metodologia: Odwołanie do uznanej metodyki. Dla aplikacji webowych - OWASP WSTG (Web Security Testing Guide), dla mobile - OWASP MASTG. Dla infrastruktury, sieci i Active Directory - PTES (Penetration Testing Execution Standard), NIST SP 800-115 lub OSSTMM. Dla sektora finansowego objętego DORA - TIBER-EU/TLPT.

• Dokumentacja wyników: Nie lista podatności, ale udokumentowane dowody eksploitacji, realne ścieżki ataku i ocena ryzyka.

Kluczowa różnica między testem na potrzeby compliance a zwykłym assessmentem polega na tym, że compliance wymaga dowodów, nie tylko wyników. Audytor nie pyta "czy test był", ale "co udowodnił i jak był przeprowadzony".

Czym różni się pentest zgodny z compliance od oceny podatności (vulnerability assessment)? Ocena podatności to w skrócie zautomatyzowane lub częściowo manualne wykrycie znanych luk w oparciu o bazę CVE. Pentest idzie dalej. Pentester próbuje aktywnie wykorzystać podatności, łączyć je w łańcuchy ataków i udowodnić realne ryzyko. Dla compliance liczy się właśnie ten element symulacji realnego atakującego.

Warto też podkreślić, że "odhaczenie" pentestu na liście zadań to jeden z najczęstszych błędów. Organizacje zlecają test, dostają raport w PDF i umieszczają go w folderze compliance. Audytor pyta o zakres, autoryzację, zasady gry i dowody eksploatacji. Jeśli tych elementów nie ma, raport jest bezużyteczny z perspektywy zgodności.

Jakie przepisy i standardy wymagają pentestów zgodnych z compliance w Europie

Znamy już definicję. Teraz konkretne regulacje i normy, które stawiają realne wymagania w tym zakresie.

GDPR (Rozporządzenie o Ochronie Danych Osobowych)

Artykuł 32 GDPR zobowiązuje organizacje przetwarzające dane osobowe do wdrożenia "procesu regularnego testowania, mierzenia i oceniania skuteczności środków technicznych i organizacyjnych". GDPR nie wymienia słowa "pentest", ale europejscy regulatorzy i organy nadzorcze wielokrotnie interpretowali ten przepis jako wymóg regularnych, technicznych testów bezpieczeństwa. Jak wskazuje GDPR cybersecurity requirements, GDPR promuje regularne testowanie skuteczności środków bezpieczeństwa, interpretowane często jako wymaganie pentestów.

Co to oznacza dla pentestera? Jeśli wykonujesz test dla organizacji podlegającej GDPR, raport musi wyraźnie wskazywać, jakie środki ochrony danych były testowane i jaka jest ich skuteczność. Sama lista CVE nic tu nie udowadnia.

ISO 27001

ISO/IEC 27001:2022 to obowiązująca wersja standardu zarządzania bezpieczeństwem informacji (okres przejściowy z wersji 2013 zakończył się 31 października 2025 - audytorzy odwołują się dziś do nowej numeracji). Kontrola A.8.8 "Management of technical vulnerabilities" (dawniej A.12.6.1 z wersji 2013) dotyczy zarządzania podatnościami technicznymi, a kontrola A.5.36 "Compliance with policies, rules and standards for information security" (dawniej A.18.2.3) wprost wymaga przeglądu technicznego pod kątem zgodności. ISO 27001 nie wymusza pentestu z nazwy, ale audytorzy oczekują obiektywnych dowodów skuteczności kontroli. W praktyce oznacza to, że jeśli twój ISMS (Information Security Management System) zawiera stwierdzenie, że kontrole są skuteczne, musisz to udowodnić. A pentest z odpowiednią dokumentacją to właśnie taki dowód.

NIST SP 800-115

NIST Special Publication 800-115 to dokument techniczny opisujący metodologię przeprowadzania testów bezpieczeństwa. Definiuje cztery fazy: planowanie, odkrycie, atak i raportowanie. Dla compliance istotne jest to, że NIST wymaga dokumentowania każdego etapu procesu z precyzją pozwalającą na odtworzenie wyników.

Kontekst europejski

DORA (Digital Operational Resilience Act), obowiązujący sektor finansowy od 17 stycznia 2025 roku, nakłada obowiązek przeprowadzania Threat-Led Penetration Testing (TLPT) dla podmiotów krytycznych. TLPT bazuje na frameworku TIBER-EU opracowanym przez Europejski Bank Centralny - dokument operacyjny definiuje wymagania scope, threat intelligence i red teamingu pod nadzorem regulatora krajowego.

NIS2 (Dyrektywa UE 2022/2555) to dziś główny driver pentestów w UE dla podmiotów kluczowych i ważnych: energetyka, transport, zdrowie, woda, infrastruktura cyfrowa, dostawcy usług ICT, administracja publiczna. W Polsce implementowana ustawą o krajowym systemie cyberbezpieczeństwa (KSC). Artykuł 21 wymaga zarządzania ryzykiem cyberbezpieczeństwa, w tym oceny skuteczności środków - regulatorzy interpretują to jako wymóg cyklicznych testów technicznych. Kary: do 10 mln EUR lub 2% obrotu globalnego (podmioty kluczowe), do 7 mln EUR lub 1,4% (podmioty ważne).

CRA (Cyber Resilience Act, Rozporządzenie UE 2024/2847) wszedł w życie w grudniu 2024 (główne obowiązki od 11 grudnia 2027). Nakłada wymagania security-by-design oraz testów bezpieczeństwa na producentów produktów z elementami cyfrowymi - hardware IoT, oprogramowanie, urządzenia podłączone. Pentest staje się elementem oceny zgodności przed wprowadzeniem produktu na rynek UE.

Pentest a assessment: Co spełnia wymogi, a co nie?

Wiesz już, które przepisy są istotne. Czas na praktyczne rozróżnienie, jakie działania realnie spełniają wymogi compliance.

Pentest i vulnerability assessment brzmią podobnie. W praktyce to dwie różne usługi o zupełnie innej wartości dowodowej. Jak wskazuje SANS pentest vs. assessment, pentest to symulacja ataku, assessment to identyfikacja znanych podatności, a compliance wymaga raczej pierwszego.

Co dokładnie sprawdza audytor compliance w raporcie z pentestu? Oto lista kluczowych elementów, które muszą się znaleźć w dokumentacji:

1. Dokument autoryzacji z podpisem właściciela systemu lub zarządu.

2. Zakres (scope) z precyzyjną listą systemów, sieci i aplikacji objętych testem.

3. Rules of engagement z opisem dozwolonych i zabronionych technik.

4. Odwołanie do metodyki (PTES, OWASP, NIST SP 800-115 lub innej uznanej normy).

5. Dowody eksploitacji: zrzuty ekranu, logi, PoC (proof of concept) dla każdej krytycznej podatności.

6. Ocena ryzyka biznesowego w kontekście testowanego środowiska.

7. Rekomendacje remediation z priorytetyzacją.

8. Data i wersja raportu z danymi osoby odpowiedzialnej.

NIST oraz wytyczne ENISA dla regulacji UE są w tym punkcie zgodne: compliance wymaga dowodu na test w warunkach adwersaryjnych. Oznacza to, że sam skan automatyczny, nawet z tysiącem wyników, nie zastąpi udokumentowanej próby eksploitacji.

Porada profesjonalisty: Zanim zaczniesz test, przygotuj szablon dokumentacji zgodny z wymaganiami standardu, który musisz spełnić. Wypełniaj go na bieżąco, nie po zakończeniu testu. Audytorzy potrafią odróżnić dokumentację pisaną "na żywo" od tej tworzonej post factum.

Dodatkową wartość ma też zapoznanie się z przewodnikiem po fuzzingu, który pokazuje zaawansowane techniki odkrywania podatności, mające bezpośrednie zastosowanie w dowodzeniu realności ataków.

Skuteczne wdrożenie: Jak przygotować i rozliczyć pentest zgodny z compliance

Po poznaniu różnicy i standardów warto pokazać praktycznie, jak wygląda pentest spełniający compliance krok po kroku.

Prawidłowo zorganizowany pentest na potrzeby compliance przebiega przez sześć faz:

1. Planowanie i autoryzacja: Spotkanie z klientem, zdefiniowanie celów biznesowych i technicznych, podpisanie dokumentu autoryzacyjnego. Na tym etapie ustalane są ramy prawne. Bez tego kroku żaden kolejny nie ma wartości.

2. Zdefiniowanie zakresu i rules of engagement: Precyzyjna lista systemów, wykluczone systemy produkcyjne wrażliwe na przestoje, okna czasowe testów, dane kontaktowe. Zakres musi być tak szczegółowy, żeby można go było zweryfikować po zakończeniu testu.

3. Rekonesans i odkrycie: Zbieranie informacji o infrastrukturze, mapowanie sieci, identyfikacja potencjalnych wektorów ataku. Wyniki tego etapu muszą być udokumentowane, bo pokazują, co było dostępne dla hipotetycznego atakującego.

4. Eksploitacja i dowodzenie: Aktywne próby wykorzystania podatności, łączenie ich w łańcuchy ataków, eskalacja uprawnień. Każda udana eksploitacja musi być udokumentowana zrzutem ekranu lub logiem, z dokładnym timestampem i wersją narzędzia.

5. Post-eksploitacja i ocena ryzyka: Co realnie mógłby zrobić atakujący po przełamaniu zabezpieczeń? Czy mógłby uzyskać dostęp do danych osobowych, systemów płatności, infrastruktury krytycznej? Ten etap jest najważniejszy dla compliance, bo pokazuje realne ryzyko biznesowe.

6. Raportowanie i review: Przygotowanie raportu w dwóch warstwach: technicznej (dla pentesterów i developerów) i executive summary (dla zarządu i audytorów). Raport powinien pozwalać na obronę wyników przed audytem.

Jak wskazują wytyczne CREST dotyczące "defensible penetration test", kluczowa jest jakość dowodów: zakres, zasady gry, precyzyjna dokumentacja oraz zdolność obrony raportu przed audytem.

Czego audytorzy szukają w dokumentacji? Przede wszystkim spójności. Zakres zdefiniowany na początku musi odpowiadać systemom omówionym w raporcie. Dowody eksploitacji muszą być powiązane z konkretnymi podatnościami. Rekomendacje muszą być wykonalne i powiązane z ryzykiem.

Najczęstsze błędy w pentestach na potrzeby compliance to:

• Brak dokumentu autoryzacyjnego lub autoryzacja od osoby bez odpowiednich uprawnień.

• Zakres zbyt ogólny: "cała infrastruktura IT" bez listy adresów IP i nazw systemów.

• Brak timestampów w dowodach eksploitacji.

• Raport tylko techniczny bez oceny ryzyka biznesowego i executive summary.

• Brak odwołania do metodyki: audytor nie wie, jakimi kryteriami kierował się pentester.

• Test przeprowadzony wyłącznie automatycznie: skanery nie zastąpią ręcznej weryfikacji i eksploitacji.

Porada profesjonalisty: Jeśli chcesz, żeby twój raport był naprawdę odporny na pytania audytora, dodaj sekcję "Limitations" opisującą, czego test nie obejmował i dlaczego. To pokazuje dojrzałość metodyczną i zapobiega nieporozumieniom dotyczących zakresu.

Zaawansowane techniki, takie jak fuzzing, mają bezpośrednie zastosowanie w dokumentowaniu realności eksploitacji. Szczegółowe podejście opisuje artykuł o zastosowaniu fuzzingu w pentestach, który warto uwzględnić jako uzupełnienie metodyki.

Czego brakuje w większości pentestów na potrzeby compliance - nasze doświadczenia

Pracując ze specjalistami bezpieczeństwa i śledząc raporty z testów, które trafiają do audytorów, obserwujemy wyraźny wzorzec. Większość problemów z compliance nie wynika z braku technicznej jakości testu. Wynika z braku dyscypliny dokumentacyjnej i błędnego rozumienia tego, czego audytor w ogóle szuka.

Pierwszy i najczęstszy problem to zakres opisany zbyt ogólnie. "Testowaliśmy infrastrukturę sieciową klienta" to zdanie, które nic nie udowadnia. Audytor potrzebuje listy: które serwery, które aplikacje, które zakresy IP, w którym oknie czasowym. Brak tej precyzji sprawia, że nawet świetnie wykonany test technicznie nie może być zaakceptowany jako dowód compliance.

Drugi problem to brak weryfikacji exploitatowalności. Wiele raportów zawiera długie listy podatności z CVSS 9.0+, ale bez jednego dowodu, że którakolwiek z nich daje się realnie wykorzystać w testowanym środowisku. Compliance wymaga symulacji realnego ataku, a nie listy zagrożeń teoretycznych. Audytorzy coraz lepiej rozumieją tę różnicę i coraz częściej odrzucają raporty oparte wyłącznie na skanie automatycznym.

Trzeci problem to raporty pisane wyłącznie dla techników. Compliance dotyczy całej organizacji, a decyzje podejmuje zarząd. Raport bez executive summary z oceną ryzyka biznesowego jest bezużyteczny dla osoby decyzyjnej i często blokuje akceptację przez audytora.

Naszym zdaniem, najważniejszy parametr pentestowego compliance to realistyczność symulowanego ataku. Nie liczy się, czy pentester użył najnowszej techniki. Liczy się, czy test odwzorował realne zagrożenia dla konkretnego środowiska. Atakujący, którzy realnie zagrażają europejskim firmom, to nie badacze akademiccy. Używają prostych, sprawdzonych wektorów: phishingu, słabych haseł, niezaktualizowanych serwisów publicznych. Pentest, który skupia się wyłącznie na egzotycznych exploitach i pomija te wektory, daje fałszywe poczucie bezpieczeństwa.

Osobnym zagadnieniem jest jakość ustaleń na początku procesu. Rules of engagement, scope i cel biznesowy testu powinny być uzgodnione w formie pisemnej przed startem. Widzimy zbyt wiele przypadków, gdzie pentesterzy zaczynają pracę bez jasnych ram, a potem muszą "dopasowywać" dokumentację do gotowego raportu. To zawsze widać. Audytorzy, którzy mają doświadczenie, potrafią to rozpoznać.

Jeśli chodzi o narzędzia, to dobry sprzęt laboratoryjny znacząco wpływa na jakość dowodów. Urządzenia do testowania sieci Wi-Fi, sprzęt do analizy RFID/NFC czy dedykowane akcesoria do symulacji ataków pozwalają uzyskać reproducible evidence, czyli dowody, które można zweryfikować i powtórzyć. To jest dokładnie ten standard, którego wymaga solidny pentest na potrzeby compliance. Więcej o zaawansowanych technikach gromadzenia dowodów można znaleźć w praktycznym przewodniku fuzzingu, który opisuje metody bezpośrednio przekładające się na wartość dowodową raportu.

Narzędzia i wsparcie dla skutecznych testów penetracyjnych zgodnych z compliance

Masz wiedzę. Teraz pora wyposażyć się w sprzęt, który pozwoli ją zastosować w praktyce i uzyskać dowody akceptowane przez audytorów.

Sapsan to europejski dystrybutor specjalistycznego sprzętu dla pentesterów i specjalistów bezpieczeństwa IT. W ofercie znajdziesz narzędzia do testowania sieci Wi-Fi, urządzenia do analizy RFID i NFC, sprzęt SDR (Software Defined Radio), akcesoria BadUSB oraz rozszerzenia do Flipper Zero. To sprzęt przeznaczony do realnych testów w warunkach laboratoryjnych i produkcyjnych, generujący dowody eksploitacji w formie akceptowanej przez audytorów compliance. Każde urządzenie dostępne w sapsan-sklep.pl jest dobrane z myślą o profesjonalnych zastosowaniach: pentestach sieci bezprzewodowych, testach fizycznego bezpieczeństwa systemów dostępowych, analizie protokołów radiowych i symulacji ataków na urządzenia IoT. Zamówienia realizowane są z dostawą na terenie całej Europy.

Najczęściej zadawane pytania

Czy każde regularne skanowanie podatności wystarcza dla compliance?

Nie, compliance wymaga raczej realistycznych testów typu pentest niż tylko automatycznego skanowania. Jak wskazuje SANS pentest vs. assessment, compliance wymaga symulacji realnych ataków, nie tylko detekcji luk.

Czy GDPR wymaga pentestu z nazwy?

GDPR nie wymienia wprost pentestu, ale artykuł 32 nakłada obowiązek regularnych testów skuteczności środków bezpieczeństwa. Jak podkreślają wymagania GDPR w zakresie cyberbezpieczeństwa, wymóg regularnego testowania skuteczności zabezpieczeń jest interpretowany przez regulatorów jako konieczność przeprowadzania pentestów.

Jaką formę raportu z pentestu akceptują audytorzy compliance?

Audytorzy preferują raporty z czytelnym zakresem, pisemnymi uzgodnieniami, dowodami z realistycznych testów i konkretnymi rekomendacjami. Według penetration testing code compliance, jakość raportu musi pozwalać na obronę wyników przed audytem.

Jak często należy przeprowadzać pentesty zgodne z compliance?

Częstotliwość powinna wynikać z analizy ryzyka: zmienności środowiska, poziomu wrażliwości danych i tempa zmian w systemach IT. Kontekst europejski wymaga podejścia risk-based, a nie sztywnego kalendarza testów.