• strona główna
  • Testy penetracyjne w ramach ISO 27001 – przewodnik praktyczny

Testy penetracyjne w ramach ISO 27001 – przewodnik praktyczny

Skaner podatności pokaże Ci listę dziur. Testy penetracyjne pokażą, co napastnik realnie z nimi zrobi: czy z zewnętrznego VPN-a dojdzie do serwera z danymi klientów, czy jedna podatna wtyczka w portalu B2B wystarczy do przejęcia domeny, czy „zabezpieczony” system produkcyjny jest o dwa kroki od zaszyfrowania. W certyfikowanym systemie zarządzania bezpieczeństwem informacji pentesty nie są fanaberią działu IT — są dowodem, że organizacja spełnia konkretne kontrole ISO/IEC 27001:2022 i twarde wymogi prawa: od RODO, przez ustawę o krajowym systemie cyberbezpieczeństwa i ustawę o zarządzaniu kryzysowym, po rozporządzenie DORA w sektorze finansowym.

Ten praktyczny przewodnik przeprowadzi Cię przez cały proces: które kontrole Załącznika A stoją za testami penetracyjnymi w ISO 27001, jaki rodzaj testu wybrać (black / white / grey box, sieć, aplikacja webowa, mobile, API), jak wygląda praca testerów od rozpoznania po raport, co musi zawierać raport z pentestu, żeby przeszedł audyt, jak często powtarzać testy — i co na to wszystko polskie prawo karne. Bo pentest bez umowy i zakresu to nie test, tylko przestępstwo — na szczęście ustawodawca przewidział dla etycznych hakerów konkretne „bezpieczniki”.

Załącznik A ISO 27001 – wymagania dot. testów penetracyjnych

ISO/IEC 27001:2022 nie zawiera przepisu „wykonuj testy penetracyjne raz w roku”. Wymóg jest inteligentniejszy: wynika z kombinacji podejścia opartego na ryzyku (klauzule 6.1.2–6.1.3, 8.1) oraz kontroli Załącznika A, których implementację deklarujesz w Deklaracji Stosowania. Najmocniej z pentestami związane są trzy zabezpieczenia z domeny technologicznej — szerzej o całej strukturze piszemy w artykule Załącznik A ISO 27001 – jakie zabezpieczenia są kluczowe?.

Które kontrole ISO 27001 wymagają pentestów? (A.8.8, A.8.28, A.8.29)

  • A.8.8 — Zarządzanie podatnościami technicznymi: organizacja ma pozyskiwać informacje o podatnościach systemów, oceniać narażenie i podejmować działania. W praktyce audytowej „oceną narażenia” dla systemów krytycznych jest właśnie test penetracyjny: skaner mówi „jest podatność CVE-XXXX”, pentester mówi „da się ją wykorzystać do przejęcia konta administratora domeny”. Kontrola wymaga też działania w odpowiednim czasie — dlatego wyniki pentestu powinny trafiać do procesu zarządzania podatnościami z terminami napraw proporcjonalnymi do ryzyka.
  • A.8.28 — Bezpieczne kodowanie: zasady wytwarzania oprogramowania, w tym wymaganie testów bezpieczeństwa w cyklu wytwórczym (SAST — analiza kodu, SCA — zależności). Pentest aplikacji jest tu naturalnym „testem akceptacyjnym” bezpieczeństwa kodu pisanego przez zespół lub dostawcę.
  • A.8.29 — Testowanie bezpieczeństwa w procesie tworzenia i akceptacji: organizacja ma ustanowić proces testowania bezpieczeństwa (m.in. testy nowego systemu przed wdrożeniem na produkcję). To kontrola, którą audytorzy najczęściej wiążą wprost z pentestami aplikacji i infrastruktury przed go-live oraz przy istotnych zmianach.

 

Do kompletu dochodzą: A.8.16 (monitoring) — wyniki testów kalibrują skuteczność detekcji, A.5.7 (threat intelligence) i A.5.35 (niezależny przegląd zarządzania bezpieczeństwem informacji) — pentest bywa jego elementem, oraz klauzula 9.1 (ocena skuteczności zabezpieczeń). A nad wszystkim klauzula 6.1.3: skoro w analizie ryzyka zidentyfikowałaś(eś) ryzyko „atak na portal klienta”, planem traktowania może być redukcja zweryfikowana testem. Testy penetracyjne ISO 27001 są więc dowodem skuteczności całego systemu, a nie osobnym bytem.

Rodzaje testów penetracyjnych – co wybrać dla swojej firmy?

Black box vs white box vs grey box – różnice i zastosowania

Kryterium Black box Grey box White box
Wiedza testera Zero/minimum — jak zewnętrzny włamywacz Konta użytkowników, szczątkowa dokumentacja Pełna: kody, schematy, dostępy, dokumentacja
Cel Realny obraz ataku z zewnątrz; test detekcji i reakcji SOC Najczęstszy standard rynkowy: balans realizmu i pokrycia Maksymalne pokrycie testowe; audyt logiki biznesowej
Czasochłonność/koszt Dużo czasu na rozpoznanie → drożej za zakres Optymalna Najszybsze na jednostkę zakresu, wymaga przygotowania
Kiedy wybrać Symulacja realnego ataku (red team), weryfikacja perimetru, test SOC Aplikacje klienckie, portale, API, coroczny pentest infrastruktury Audyt przed wdrożeniem (A.8.29), systemy krytyczne, krótkie okna testowe
Typowe ograniczenie Niskie pokrycie — tester „nie zdąży” zajrzeć głęboko Wymaga zaufanego kanału wymiany danych Mniej realistyczny obraz ataku z zewnątrz

 

Dla większości MŚP rekomendacja na pierwszy test to grey box: dwa konta testowe (użytkownik zwykły + uprzywilejowany), dostęp do środowiska testowego (lub produkcyjnego z uzgodnionymi ograniczeniami) i jasny zakres. Black box zostaw na symulacje realnego ataku, white box — na audyty krytycznych aplikacji przed wdrożeniem.

Pentesty sieci, aplikacji web, mobilnych, API – przegląd

  • Pentest infrastruktury (sieci): zewnętrzny (perimetr: VPN, bramki, usługi wystawione do internetu) i wewnętrzny (segmentacja, Active Directory, stacje robocze, serwery). Typowe znaleziska: brak MFA na VPN, usługi RDP/SSH wystawione publicznie, niezabezpieczone udziały sieciowe, brak segmentacji OT/IT. To najczęstszy „pierwszy pentest” — odpowiednik klasycznych pentestów sieci.
  • Aplikacje webowe: metodyka wg OWASP WSTG, punkty odniesienia OWASP Top 10 i OWASP ASVS. Typowe znaleziska: injection (SQL/command), broken access control (IDOR — dostęp do cudzych faktur przez zmianę ID w URL), błędy uwierzytelniania, XSS, SSRF, wycieki w konfiguracji.
  • Aplikacje mobilne: analiza binarna i zachowania (Android/iOS), przechowywanie danych i kluczy na urządzeniu, komunikacja z backendem, podatności logiki biznesowej; metodycznie wg OWASP MASVS/MASTG.
  • API: dziś najczęściej niedoszacowany wektor — testy autoryzacji (BOLA/IDOR na poziomie obiektów), limitów (brak rate-limitingu → wyciąganie całej bazy), walidacji wejść, wersji endpointów; odniesienie: OWASP API Security Top 10.
  • Uzupełniająco: testy socjotechniczne i fizyczne (phishing kierowany, wejście do biura — uwaga: wyłącznie w zakresie i za pisemną zgodą!), testy ciągłości działania (odrębnie wymagane u podmiotów krytycznych — art. 6zzb ust. 1 pkt 2 ustawy o zarządzaniu kryzysowym, t.j. Dz. U. z 2026 r. poz. 574 i 815) oraz TLPT w sektorze finansowym (niżej).

 

Wybór zakresu oprzyj o własną analizę ryzyka (klauzula 6.1.2), a nie o modę: jeśli krytyczny proces biznesowy obsługuje portal klienta — testuj portal i API, nie serwer wydruku.

Proces testów penetracyjnych krok po kroku

Rzetelny pentest realizuje etapy znane z metodyk NIST SP 800-115, PTES i OSSTMM. Przebieg „od kuchni”:

Faza reconnaissance, exploitation, reporting – co sprawdzają testerzy?

  1. Ustalenie zakresu i zasad (Rules of Engagement) — zanim padnie pierwszy pakiet: umowa, pisemne upoważnienie, lista adresów IP/domem/aplikacji, okna czasowe, techniki wykluczone (np. DoS, inżynieria społeczna bez zgody), kontakty awaryjne, zasady eskalacji krytycznych znalezisk „na gorąco”. Bez tego nie ma testu — jest włamanie (o prawie niżej).
  2. Reconnaissance (OSINT + skanowanie): pasywne zbieranie informacji (rekordy DNS, certyfikaty, repozytoria kodu, wycieki haseł w bazach typu Have I Been Pwned), aktywne skanowanie portów i usług (Nmap/masscan), fingerprinting, enumeracja. Tu tester odpowiada na pytanie „jaki jest realny ślad atakowanej organizacji w internecie” — często pierwszy szok dla klienta.
  3. Analiza podatności: skanery (Nessus, OpenVAS) plus weryfikacja ręczna — odróżnienie „podatności teoretycznej” od „wykorzystywalnej”.
  4. Exploitation: kontrolowane wykorzystanie znalezisk — webshelle, eskalacja przywilejów, ataki na AD (Kerberoasting, pass-the-hash), obejścia logiki biznesowej. Zasada: minimum niezbędnej ingerencji, zero destrukcji, każdy krok logowany.
  5. Post-exploitation i pivotowanie: jak daleko napastnik zajdzie z pierwszego przyczółka (segmentacja sieci w praktyce), dostęp do danych wrażliwych (demonstracyjny, bez exfiltracji pełnych zbiorów).
  6. Sprzątanie śladów testu (usunięcie artefaktów) i raportowanie + retest po naprawach.

 

Legalność — co mówi Kodeks karny (t.j. Dz. U. z 2025 r. poz. 383, z późn. zm.): nieuprawniony dostęp do informacji lub systemu to przestępstwo z art. 267 § 1–2 (grzywna, ograniczenie wolności albo pozbawienie wolności do lat 2), zakłócenie pracy systemu — art. 269a (od 3 miesięcy do 5 lat), a posiadanie i udostępnianie „narzędzi hakerskich” — art. 269b § 1 (od 3 miesięcy do 5 lat). Ustawodawca wprowadził jednak dwa „bezpieczniki” dla testerów: art. 269b § 1a (nie popełnia przestępstwa, kto działa wyłącznie w celu zabezpieczenia systemu lub opracowania metody zabezpieczenia) oraz art. 269c (nie podlega karze za czyn z art. 267 § 2 lub art. 269a, kto działa wyłącznie w celu zabezpieczenia systemu, niezwłocznie powiadomił dysponenta systemu o zagrożeniach, a działanie nie naruszyło interesu publicznego lub prywatnego i nie wyrządziło szkody). Wniosek praktyczny: pentest na zlecenie i w uzgodnionym zakresie jest bezpieczny prawnie; „test bez umowy” — nawet w dobrej wierze — to ryzyko karne. Wrażliwe są też dane: raport pentest podlega ochronie jak informacja o podatnościach (por. art. 266 § 1 k.k. — ujawnienie informacji pozyskanej w związku z pełnioną funkcją/wykonywaną pracą; poufność dokumentacji wynika też z art. 6zu ust. 5 ustawy o zarządzaniu kryzysowym).

Raport z pentestu – co musi zawierać, aby spełnić wymogi audytora?

Dobry raport z pentestu ma dwie warstwy i stałą strukturę:

  1. Streszczenie zarządcze (executive summary) — 1–2 strony językiem biznesu: co przetestowano, kluczowe ryzyka (top 3–5), wpływ na procesy biznesowe, rekomendacje strategiczne, ogólna ocena dojrzałości. To tę część czyta zarząd — i audytor na przeglądzie zarządzania (klauzula 9.3).
  2. Część techniczna — dla zespołu IT:
    • metodyka i zakres (adresy, aplikacje, konta, okna czasowe, techniki wyłączone) — dowód zgodności z upoważnieniem,
    • lista znalezisk z oceną ryzyka każdego (najlepiej CVSS v3.1/v4.0 + kalibracja do kontekstu organizacji), dowodami (PoC: zrzuty, żądania HTTP, logi) i krokiem po kroku opisem odtworzenia,
    • rekomendacje naprawcze (konkretne: „włącz MFA na VPN”, nie „popraw bezpieczeństwo”), priorytety i sugerowane terminy,
    • harmonogram retestu i potwierdzenie zamknięcia znalezisk.
  3. Załączniki: skład zespołu i kwalifikacje (certyfikaty OSCP, OSCE, CREST — przydają się przy wymogu kompetencji dostawcy), użyte narzędzia, oświadczenia o poufności.

 

Co na to audytor ISO 27001? Oczekuje spójności: zakres testu wynikający z analizy ryzyka (6.1.2), znaleziska zaadresowane w planie traktowania (6.1.3) i rejestrze działań, dowód retestu, a sam raport — objęty nadzorem nad udokumentowaną informacją (7.5, A.5.12 klasyfikacja, A.5.15 kontrola dostępu). Raport „do szuflady” bez decyzji zarządu to dla audytora niezgodność w praktyce działania, nawet jeśli test się odbył.

Częstotliwość testów a cykl życia zagrożeń

Kiedy powtórzyć pentest? Po zmianach w infrastrukturze, po incydencie, co roku?

Najkrótsza odpowiedź: co najmniej raz w roku dla systemów krytycznych + zawsze po istotnej zmianie + po każdym poważnym incydencie. Dłuższa — wynika z połączenia normy i prawa:

  • ISO 27001: częstotliwość wyznacza analiza ryzyka (6.1.2) i skuteczność zabezpieczeń (9.1). Praktyka certyfikacyjna: coroczny pentest infrastruktury/aplikacji krytycznych mieści się w cyklu auditów i przeglądów (9.2–9.3).
  • RODO: art. 32 ust. 1 lit. d wymaga „regularnego testowania, mierzenia i oceniania skuteczności środków” — „regularnie” kalibrujesz ryzykiem; przy dużym ryzyku DPIA (art. 35) powinna uwzględniać wyniki testów.
  • KSC po NIS2 (t.j. Dz. U. z 2026 r. poz. 20, z późn. zm.): podmioty kluczowe i ważne prowadzą SZBI (art. 8 ust. 1), zarządzanie podatnościami i incydentami, a „testy penetracyjne NIS2″ to dziś standardowy element dowodzenia skutecznością środków — obok corocznych audytów; nadzór sprawuje organ właściwy ds. cyberbezpieczeństwa (art. 41 KSC), a kary sięgają 10 mln EUR lub 2% obrotu (art. 73 ust. 3).
  • Ustawa o zarządzaniu kryzysowym: podmiot krytyczny realizuje „okresowe audyty i certyfikacje” (art. 6zt ust. 1 pkt 2 lit. j), testy ciągłości działania (art. 6zzb ust. 1 pkt 2) i ocenia ryzyko min. co 2 lata (art. 6zt ust. 1 pkt 1) — pentesty naturalnie wpinają się w ten rytm, a krytyczni dostawcy podlegają audytowi za pośrednictwem podmiotu krytycznego (art. 6zzq).
  • DORA (rozporządzenie (UE) 2022/2554) — sektor finansowy: pełny program testowania odporności cyfrowej (art. 24 ust. 1), katalog testów wprost obejmuje „oceny podatności i skanowanie, przeglądy kodu źródłowego, testy scenariuszowe i testy penetracyjne” (art. 25 ust. 1), a istotne podmioty wykonują TLPT (threat-led penetration testing) nie rzadziej niż co 3 lata — na systemach produkcyjnych wspierających funkcje krytyczne, z udziałem zewnętrznych dostawców ICT (art. 26 ust. 1–3), raportując wyniki właściwym organom (art. 27).
  • Telekomunikacja: przedsiębiorcy komunikacyjni zapewniają środki adekwatne do zidentyfikowanego ryzyka w planach na sytuacje szczególnego zagrożenia (art. 39 ust. 1 Prawa komunikacji elektronicznej, Dz. U. z 2024 r. poz. 1221, z późn. zm.) — testy są sposobem weryfikacji adekwatności.

 

Reguły „zdarzeniowe” — powtórz pentest, gdy: wdrażasz nową aplikację/krytyczną zmianę (A.8.29 — test akceptacyjny), zmieniasz architekturę (migracja do chmury, nowy VPN), po incydencie (weryfikacja usunięcia przyczyny; przypomnijmy: incydent istotny podmiotu krytycznego zgłasza się w 24 h — art. 6zv ust. 1 pkt 4 u.z.k.), po pojawieniu się masowo wykorzystywanej podatności w Twoim stosie technologicznym (A.5.7, A.8.8), przed dużym wydarzeniem biznesowym (sezonowość, kampania) oraz po reorganizacji (fuzja, nowy dostawca zarządzany — MSSP w rozumieniu art. 2 pkt 4j KSC).

Warto dodać wymiar unijnej certyfikacji: na podstawie aktu o cyberbezpieczeństwie (rozporządzenie (UE) 2019/881 — art. 48–49: europejskie programy certyfikacji z poziomami uzasadnienia zaufania „podstawowy”, „istotny”, „wysoki”) działa już pierwszy schemat EUCC (rozporządzenie wykonawcze Komisji (UE) 2024/482) dla produktów ICT. Certyfikat produktu nie zastępuje pentestu systemu — ale zmniejsza zakres testowania i jest coraz częściej wymagany w umowach (por. art. 6zt ust. 8 u.z.k. — żądanie certyfikatów od usługodawców).

Podsumowanie: pentest to proces, nie jednorazowa usługa

Testy penetracyjne w ramach ISO 27001 działają najlepiej jako element cyklu: analiza ryzyka → zakres testu → test (grey box jako standard) → raport z dwiema warstwami → decyzje zarządu i plan traktowania → naprawy → retest → dowód dla audytora. Prawo dopisuje rytm: corocznie (dobra praktyka i „regularnie” z RODO), co 2 lata (ocena ryzyka podmiotu krytycznego), co 3 lata (TLPT w DORA), a zawsze po zmianie i incydencie. Szukając wykonawcy — także lokalnie, pod hasłami typu „audyt penetracyjny Olsztyn” — sprawdzaj metodykę (NIST SP 800-115/PTES), certyfikaty zespołu (OSCP/CREST), wzór raportu i ubezpieczenie OC. Więcej o wyborze dostawcy i budżetowaniu znajdziesz w tekście Testy penetracyjne dla firm – kompleksowy przewodnik, a całościowe spojrzenie na weryfikację bezpieczeństwa daje nasz audyt cyberbezpieczeństwa.

Zanim zdecydujesz się na pełny pentest, wykonamy bezpłatny, nieinwazyjny skan Twojego perimetru (usługi wystawione do internetu, konfiguracja TLS, ślad OSINT) i pokażemy, co widzi napastnik — oraz przygotujemy wycenę testu dopasowanego do zakresu i budżetu.

Kancelaria Cyberpolex
Kamil Kołodziejczak, radca prawny
📞 (+48) 665 805 912
✉️ kontakt@cyberpolex.pl
🌐 cyberpolex.pl
📍 ul. Stare Miasto 29/32 lok. 3, 10-026 Olsztyn

Źródła prawne i normatywne

  1. Norma ISO/IEC 27001:2022 (z Amd 1:2024) — klauzule 6.1.2–6.1.3, 7.5, 8.1, 9.1–9.3; Załącznik A: A.5.7, A.5.12, A.5.15, A.5.35, A.8.8, A.8.16, A.8.28, A.8.29.
  2. Rozporządzenie (UE) 2016/679 (RODO) — art. 32 ust. 1 lit. d; art. 35.
  3. Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (t.j. Dz. U. z 2026 r. poz. 20, z późn. zm.) — art. 2 pkt 4j; art. 8 ust. 1; art. 41; art. 73 ust. 3.
  4. Ustawa z dnia 26 kwietnia 2007 r. o zarządzaniu kryzysowym (t.j. Dz. U. z 2026 r. poz. 574 i 815) — art. 6zt ust. 1 pkt 1–2 i ust. 8; art. 6zu ust. 5; art. 6zv ust. 1 pkt 4; art. 6zzb; art. 6zzq.
  5. Rozporządzenie (UE) 2022/2554 (DORA) — art. 24 ust. 1; art. 25 ust. 1; art. 26 ust. 1–3; art. 27.
  6. Rozporządzenie (UE) 2019/881 (akt o cyberbezpieczeństwie) — art. 48–49; rozporządzenie wykonawcze Komisji (UE) 2024/482 (schemat EUCC).
  7. Kodeks karny (t.j. Dz. U. z 2025 r. poz. 383, z późn. zm.) — art. 266 § 1; art. 267; art. 268a; art. 269a; art. 269b § 1 i 1a; art. 269c.
  8. Ustawa z dnia 12 lipca 2024 r. — Prawo komunikacji elektronicznej (Dz. U. z 2024 r. poz. 1221, z późn. zm.) — art. 39 ust. 1.
  9. Metodyki: NIST SP 800-115; PTES; OSSTMM; OWASP WSTG/MASVS/MASTG; OWASP Top 10 (Web/API); CVSS v3.1/v4.0.

 

Artykuł ma charakter informacyjny i nie stanowi porady prawnej; każdy test penetracyjny wymaga indywidualnej oceny prawnej zakresu i upoważnienia.