Test penetracyjny ISO 27001: Załącznik A.8.29, A.8.8 i dowody certyfikacyjne

ISO/IEC 27001:2022 wprowadziła istotne zmiany do kontroli technologicznych w Załączniku A, które bezpośrednio wpływają na obowiązki w zakresie testów penetracyjnych. Kontrola A.8.29 (Testowanie bezpieczeństwa w fazie rozwoju i akceptacji) wymaga udokumentowanych testów bezpieczeństwa przed uruchomieniem produkcyjnym systemów. Kontrola A.8.8 (Zarządzanie podatnościami technicznymi) wymaga systematycznego procesu zarządzania podatnościami, który wprost obejmuje testy penetracyjne jako metodę oceny. Razem te dwie kontrole stanowią techniczny kręgosłup ISMS zgodnego z ISO 27001 w zakresie bezpieczeństwa ofensywnego. Ta strona wyjaśnia, czego oczekują audytorzy jednostek certyfikujących, jak ustrukturyzować program testowania, który przetrwa audyty nadzoru i recertyfikacji, oraz jak zintegrować ciągłe testowanie automatyczne z zaplanowanymi zewnętrznymi zleceniami.

Uruchom skan ISO 27001

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

Czego faktycznie wymaga ISO 27001:2022 od programu testów penetracyjnych

ISO 27001:2013 obejmowała zarządzanie podatnościami w ramach A.12.6, ale była mniej preskryptywna w kwestii testów penetracyjnych. Wersja z 2022 r. znacznie wzmocniła kontrole technologiczne. Załącznik A zawiera obecnie 93 kontrole w 4 obszarach (organizacyjne, ludzkie, fizyczne, technologiczne), zastępując 114 kontroli wersji z 2013 r. Wydanie z 2022 r. dodało 11 nowych kontroli, w tym A.8.29 (Testowanie bezpieczeństwa w fazie rozwoju i akceptacji) jako całkowicie nowy wymóg. Audytorzy jednostek certyfikujących, niezależnie od tego czy akredytowani przez UKAS w Wielkiej Brytanii, DAkkS w Niemczech, COFRAC we Francji czy ACCREDIA we Włoszech, dostosowali swoje programy audytowe do badania, czy A.8.29 i A.8.8 są rzeczywiście wdrożone. 'Przeprowadzamy roczne skanowanie podatności' nie jest już wystarczającym dowodem. Audytorzy coraz częściej proszą o wgląd w rzeczywiste raporty z testów penetracyjnych, zapisy śledzenia napraw oraz dowody retestu potwierdzające, że poprawki zostały zweryfikowane. Praktyczny próg ustanowiony przez doświadczonych audytorów wiodących ISO 27001 w latach 2024-2025: (1) zakres testów penetracyjnych musi obejmować aktywa krytyczne ISMS, (2) testy muszą korzystać z udokumentowanej metodyki (OWASP Testing Guide, PTES lub NIST SP 800-115), (3) wyniki muszą być oceniane pod względem ryzyka przy użyciu CVSS 3.1 lub równoważnego systemu, (4) naprawy muszą być śledzone wraz z decyzjami o akceptacji lub leczeniu dla każdego wyniku oraz (5) wyniki wysokie i krytyczne muszą być retestowane w celu potwierdzenia ich rozwiązania.

ISO 27001:2022 Załącznik A.8.29 (Testowanie bezpieczeństwa w fazie rozwoju i akceptacji) - nowa kontrola w wersji z 2022 r. - wymaga, aby testowanie bezpieczeństwa nowych aplikacji i istotnych zmian było zdefiniowane i wdrożone w procesach rozwojowych. Testowanie penetracyjne przed głównymi wdrożeniami produkcyjnymi to standardowa implementacja.
ISO 27001:2022 Załącznik A.8.8 (Zarządzanie podatnościami technicznymi) wymaga terminowej identyfikacji i naprawy podatności technicznych. Wytyczne wdrożeniowe ISO 27002:2022 wprost odwołują się do testów penetracyjnych jako środka identyfikacji podatności technicznych uzupełniającego automatyczne skanowanie podatności.
ISO 27001:2022 Załącznik A.8.25 (Bezpieczny cykl życia rozwoju) oraz A.8.26 (Wymagania bezpieczeństwa aplikacji) tworzą szerszy obowiązek testowania bezpieczeństwa w całym cyklu rozwojowym - nie tylko przy wdrożeniu. Testowanie penetracyjne zintegrowane z CI/CD bezpośrednio spełnia te kontrole.
Audytorzy jednostek certyfikujących podczas audytów nadzoru (corocznych) i audytów recertyfikacji (co 3 lata) badają, czy program testowania penetracyjnego działał w sposób ciągły - pojedynczy test wykonany dwa miesiące przed audytem to czerwona flaga grożąca zawieszeniem certyfikatu.
Certyfikacja ISO 27001 jest coraz częściej wymagana w korporacyjnych zamówieniach B2B. Jeśli certyfikat wygaśnie lub audyt znajdzie A.8.29/A.8.8 jako poważne niezgodności, tracicie certyfikat - a wraz z nim potencjalnie znaczące przychody korporacyjne zablokowane za kryteriami kwalifikacji dostawców 'wymagana certyfikacja ISO 27001'.
Ubezpieczyciele cyber oferujący polisy z premium-discount za ISO 27001 wymagają, aby certyfikowany ISMS faktycznie obejmował aktywne testowanie penetracyjne. Certyfikaty 'duchów' (utrzymywane na papierze bez aktywnego testowania) są coraz częściej kwestionowane w momencie roszczenia.
Zarówno DORA, jak i NIS2 wprost uznają certyfikację ISO 27001 jako dowód podstawowej zgodności z cyberbezpieczeństwem, ale tylko wtedy gdy kontrole ISMS (w tym A.8.29) są rzeczywiście wdrożone. Certyfikat ISO 27001 ze stwierdzeniem poważnej niezgodności na A.8.29 nie spełniłby audytu zgodności z Art. 24 DORA.

Co testuje Matproof, aby wesprzeć Państwa kontrole Załącznika A ISO 27001

A.8.29 - testowanie bezpieczeństwa w fazie rozwoju: skanowanie środowisk staging przed wydaniem, testy zintegrowane z CI/CD blokujące wdrożenie przy obecności krytycznych/wysokich wyników, testowanie specyficzne dla stosu (Next.js CVE-2024-43481, Django CVE-2024-43990, Spring4Shell CVE-2022-22965)
A.8.8 - zarządzanie podatnościami technicznymi: ciągły monitoring CVE względem odciskanego palca stosu technologicznego, korelacja z bazami NVD/GHSA, automatyczne alerty gdy publikowane są nowe CVE dotyczące Państwa konkretnych zależności
A.8.26 - wymagania bezpieczeństwa aplikacji: pełne pokrycie OWASP Top 10 (2021) - A01 Broken Access Control, A02 Cryptographic Failures, A03 Injection, A07 Authentication Failures, A09 Security Logging and Monitoring Failures
A.8.9 - zarządzanie konfiguracją: sprawdzanie nagłówków bezpieczeństwa (HSTS RFC 6797, CSP W3C Level 2, X-Frame-Options, Referrer-Policy, Permissions-Policy), audyt konfiguracji TLS (RFC 8446), przegląd polityki CORS
A.5.30 - gotowość ICT do ciągłości działania: dostępność i odporność krytycznych punktów końcowych aplikacji, odporność na DoS HTTP/2 rapid reset (środki łagodzące CVE-2023-44487), skuteczność rate limiting
A.8.23 - filtrowanie webowe oraz A.8.28 - bezpieczne kodowanie: SQL injection (CWE-89), przechowywany i odbity XSS (CWE-79), SSRF (CWE-918), command injection (CWE-78), XML external entity injection XXE (CWE-611)
A.8.3 - ograniczenia dostępu do informacji: testowanie IDOR (OWASP API1:2023 Broken Object Level Authorization), weryfikacja izolacji multi-tenancy, pozioma i pionowa eskalacja uprawnień
A.8.2 - prawa dostępu uprzywilejowanego oraz A.5.17 - informacje uwierzytelniające: wykrywanie słabości JWT (CWE-347), analiza przepływu resetu hasła, obejście MFA przez fiksację sesji lub replay tokena
A.8.7 - ochrona przed złośliwym oprogramowaniem: analiza komponentów łańcucha dostaw (npm, PyPI, Maven, Cargo) względem znanych złośliwych pakietów, wsparcie generowania SBOM
A.5.7 - integracja threat intelligence: wyniki mapowane do MITRE ATT&CK Enterprise, umożliwiające zespołom SOC tworzenie reguł wykrywania na podstawie zaobserwowanych technik ataku

Sample finding

High

Naruszenie A.8.8: krytyczne CVE w produkcyjnej zależności niewykryte przez 8 miesięcy

Matproof Sentinel zidentyfikował, że aplikacja produkcyjna klienta używa Spring Framework 5.3.26, która jest podatna na CVE-2022-22965 ('Spring4Shell', CVSS 9.8) - podatność zdalnego wykonania kodu w aplikacjach Spring MVC/WebFlux działających na JDK 9+. Podatność została publicznie ujawniona w marcu 2022 r., a poprawka była dostępna w ciągu 48 godzin. Wersja zależności klienta nie była aktualizowana od 8 miesięcy. Sentinel potwierdził możliwość eksploitacji, tworząc żądanie manipulacji ClassLoader, które zapisało JSP webshell w dostępnym katalogu aplikacji. ISO 27001:2022 A.8.8 wymaga terminowej identyfikacji i naprawy podatności technicznych - 8 miesięcy stanowi istotną awarię kontroli, którą audytor certyfikujący zgłosiłby jako poważną niezgodność.

Fix: Natychmiast: uaktualnić Spring Framework do ≥5.3.18 (lub ≥6.0.0 jeśli Spring 6.x). Zweryfikować poprawkę przez próbę użycia payloadu eksploitującego CVE-2022-22965 przeciwko załatanemu środowisku staging. Naprawa procesu dla zgodności z A.8.8: wdrożyć automatyczne SCA (Software Composition Analysis) w pipeline'ach CI/CD przy użyciu Dependabot, Renovate lub ciągłego skanowania Matproof Sentinel. Ustawić politykę: krytyczne i wysokie CVE muszą być załatane w ciągu 7 dni od ujawnienia przez dostawcę; średnie w ciągu 30 dni. Udokumentować politykę zarządzania podatnościami, śledzić naprawy w rejestrze ryzyk i przedstawić oś czasu audytorowi ISO 27001. Skonfigurować alerty e-mail Matproof Sentinel, aby uruchamiały się w ciągu 24 godzin od nowego CVE dotyczącego odciskanego palca stosu.

Reference: CVE-2022-22965 Spring4Shell (CVSS 9.8) · ISO 27001:2022 A.8.8 Zarządzanie podatnościami technicznymi · CWE-94 Improper Control of Code Generation · OWASP A06:2021 Vulnerable and Outdated Components

Opcje testów penetracyjnych dla ISO 27001

—	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 ISO 27001

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 ISO 27001

Czy ISO 27001:2022 wprost wymaga testu penetracyjnego?

ISO 27001 nie używa frazy 'test penetracyjny' wprost w normatywnym tekście normy. Jednak Kontrola A.8.29 (Testowanie bezpieczeństwa w fazie rozwoju i akceptacji) wymaga zdefiniowania i wdrożenia działań testowania bezpieczeństwa, a ISO 27002:2022 (wytyczne implementacyjne dla kontroli ISO 27001) wprost wymienia testy penetracyjne jako mechanizm wdrożeniowy dla A.8.29 i A.8.8. W praktyce audytorzy jednostek certyfikujących traktują brak jakiegokolwiek programu testów penetracyjnych jako poważną niezgodność dla organizacji, których zakres ISMS obejmuje znaczące aktywa cyfrowe. 'Wykonujemy skanowanie podatności' bez żadnego ustrukturyzowanego testowania penetracyjnego jest konsekwentnie sygnalizowane jako niewystarczające przez doświadczonych audytorów wiodących ISO 27001.

Czego szuka audytor certyfikujący podczas audytu A.8.29 ISO 27001?

Doświadczeni audytorzy wiodący ISO 27001 prowadzący audyty A.8.29 zazwyczaj przeglądają: (1) udokumentowaną politykę lub procedurę testowania bezpieczeństwa nazywającą testy penetracyjne jako wymagane działanie, (2) rzeczywiste raporty z testów penetracyjnych z poprzednich 12 miesięcy (dla audytów nadzoru) lub wykazujące ciągłą aktywność w 3-letnim okresie certyfikacji (dla recertyfikacji), (3) dowody, że testy zostały zakresowane w celu pokrycia aktywów krytycznych ISMS - a nie tylko systemów perymetru, (4) ocenę ryzyka CVSS 3.1 lub równoważną dla wszystkich wyników, (5) mechanizm śledzenia napraw (rejestr ryzyk, system ticketów lub dedykowane narzędzie) pokazujący dyspozycję każdego wyniku, (6) dla wyników krytycznych/wysokich: raporty z retestów potwierdzających naprawę, (7) komunikację wyników testów do zarządu. Audytor pobierze próbkę z listy wyników i porówna z rejestrem napraw - rozbieżności to terytorium poważnych niezgodności.

Jak 3-letni cykl recertyfikacji ISO 27001 wpływa na wymagania testów penetracyjnych?

Jednostki certyfikujące zazwyczaj prowadzą wstępny audyt certyfikacyjny (Etap 1 przegląd dokumentacji + Etap 2 na miejscu), a następnie dwa coroczne audyty nadzoru (lata 1 i 2) oraz audyt recertyfikacyjny w roku 3. Dla zgodności z A.8.29 i A.8.8: audyty nadzoru badają, czy testowanie penetracyjne zostało przeprowadzone od ostatniego audytu i wyniki naprawione. Audyty recertyfikacyjne patrzą na pełny 3-letni program - potrzebujecie dowodów testowania w regularnych odstępach, a nie tylko nagłej aktywności w miesiącu przed recertyfikacją. Najlepsza praktyka: zaplanować testowanie w Q2 i Q4 corocznie, dzięki czemu zawsze macie aktualne dowody testów dla audytów nadzoru zaplanowanych w Q1 lub Q3 oraz kompleksową historię testowania na recertyfikację.

Czy uruchomienie Matproof Sentinel spełnia ISO 27001 A.8.29 i A.8.8?

Automatyczne testowanie penetracyjne Matproof Sentinel bezpośrednio adresuje A.8.29 (testowanie w fazie rozwoju/akceptacji - przez integrację z CI/CD i skanowanie przed wydaniem) oraz A.8.8 (zarządzanie podatnościami - przez ciągły monitoring CVE i ustrukturyzowane wyniki ze śledzeniem napraw). Dla wielu organizacji z aplikacjami webowymi i API jako głównym aktywem cyfrowym, automatyczne testowanie Sentinel połączone z corocznym ustrukturyzowanym zewnętrznym pentestem spełni oczekiwania audytorów certyfikujących. Raport PDF Sentinel jest ustrukturyzowany, aby dostarczyć artefakty dowodowe, których szukają audytorzy: zakresowane wyniki, oceny CVSS, dowód eksploitacji, zalecenia naprawcze i zdolność do retestu. Jednak dla organizacji ze złożonymi środowiskami (segmentacja sieci wewnętrznych, systemy OT/SCADA, kontrole dostępu fizycznego w zakresie ISMS), samo automatyczne testowanie aplikacji webowych nie pokryje wszystkich istotnych kontroli - zalecana jest szersza ekspertyza.

Jaka jest różnica między ISO 27001 A.8.29 a A.8.8?

A.8.29 (Testowanie bezpieczeństwa w fazie rozwoju i akceptacji) koncentruje się na cyklu życia rozwoju oprogramowania - zapewniając, że bezpieczeństwo jest testowane przed wdrożeniem kodu na produkcję. Stosuje się do oprogramowania rozwijanego wewnętrznie i nabywanego. A.8.8 (Zarządzanie podatnościami technicznymi) jest szersza - obejmuje ciągłą identyfikację i naprawę podatności we wszystkich aktywach technicznych przez cały ich okres operacyjny, nie tylko przy wdrożeniu. A.8.29 jest spełniana przez testy penetracyjne przed wydaniem oraz SAST/DAST w CI/CD. A.8.8 jest spełniana przez ciągły monitoring CVE, regularne skanowanie podatności, okresowe testy penetracyjne systemów produkcyjnych i udokumentowany proces naprawczy. Obie kontrole muszą być wdrożone - jedna obejmuje 'testuj przed wdrożeniem', druga obejmuje 'monitoruj i naprawiaj na produkcji'.

Czy certyfikacja ISO 27001 może zastąpić zgodność z Art. 21 NIS2 lub Art. 24 DORA?

Certyfikacja ISO 27001 jest międzynarodowo uznawanym dowodem dojrzałości cyberbezpieczeństwa i wiele właściwych organów traktuje ją jako pozytywny wskaźnik podczas ocen nadzorczych NIS2. Jednak nie zastępuje zgodności z NIS2 lub DORA. Art. 21 NIS2 wymaga środków i obowiązków raportowania specyficznych dla sektora, których ISO 27001 nie obejmuje (np. powiadomienie o incydencie w ciągu 24 godzin, Art. 23 NIS2). Art. 24 DORA wymaga testowania konkretnych systemów ICT dla podmiotów finansowych, które wykracza poza to, co pokryłby standardowy zakres ISMS ISO 27001. Najskuteczniejsza postawa to traktowanie ISO 27001 jako ramy zarządzania, a zgodności z NIS2/DORA jako rozszerzeń wymagających konkretnych dodatkowych technicznych procedur testowania i raportowania.

Jaki zakres testu penetracyjnego jest odpowiedni dla ISMS ISO 27001?

Zakres testu penetracyjnego dla ISO 27001 powinien być spójny z definicją zakresu ISMS. Jeśli ISMS obejmuje 'bezpieczeństwo informacji dla naszej platformy SaaS skierowanej do klientów', wtedy zakres testu penetracyjnego musi obejmować aplikację webową tej platformy, API, infrastrukturę uwierzytelniania oraz wszelkie usługi chmurowe wspierające. Jeśli zakres ISMS jest organizacyjny, zakres powinien być oparty na ryzyku: aktywa krytyczne (te obsługujące najwrażliwsze dane lub zapewniające najbardziej krytyczne funkcje biznesowe) powinny być testowane corocznie; mniej krytyczne aktywa mogą być w cyklu 2-letnim. Dla celów certyfikacji ISO 27001 lepiej mieć dobrze zakresowany i regularnie testowany zakres niż nominalnie kompleksowy zakres testowany rzadko. Audytorzy bardziej interesują się dowodami ciągłego działania kontroli niż szerokością zakresu.

Jak obsłużyć wyniki testu penetracyjnego ISO 27001 podczas audytu certyfikacyjnego?

Podczas audytu certyfikacyjnego otwarte wyniki nie są same w sobie problemem - audytorzy rozumieją, że testy penetracyjne generują wyniki i że naprawa zajmuje czas. Audytorzy szukają dowodów działającego procesu: (1) wyniki są udokumentowane i ocenione pod względem ryzyka, (2) każdy wynik ma decyzję leczenia (naprawa z harmonogramem, akceptacja ryzyka z uzasadnieniem lub kontrola kompensująca), (3) wyniki krytyczne/wysokie zostały naprawione i retestowane w rozsądnym czasie (zazwyczaj 30-60 dni dla krytycznych, 90 dni dla wysokich), (4) wyniki o niskiej krytyczności są śledzone i adresowane w kolejności priorytetowej, (5) zarząd przejrzał ogólny status wyników. Czysty rejestr wyników bez zaległych pozycji krytycznych/wysokich to cel. Funkcja śledzenia napraw Matproof Sentinel eksportuje te dane w formacie gotowym do audytu.

Go deeper — related blog articles

Uzyskaj dowody testu penetracyjnego gotowe do audytu ISO 27001

Matproof Sentinel generuje ustrukturyzowane raporty z testów penetracyjnych zmapowane do ISO 27001:2022 Załącznik A.8.29 i A.8.8 - gotowe dla audytorów jednostek certyfikujących. Zacznij od darmowego 3-minutowego skanu lub uzyskaj pełny raport gotowy do audytu od €149.