Test penetracyjny PCI-DSS: Wymóg 11.3, zmiany v4.0 i zakres CDE

PCI-DSS (Payment Card Industry Data Security Standard), wersja 4.0 opublikowana w marcu 2022 r., obowiązkowa od 31 marca 2024 r., zawiera jeden z najbardziej preskryptywnych mandatów testowania penetracyjnego w jakichkolwiek globalnych ramach zgodności. Wymóg 11.3 wymaga corocznych wewnętrznych i zewnętrznych testów penetracyjnych wszystkich komponentów systemu w Środowisku Danych Posiadaczy Kart (CDE). Wymóg 11.4.4 nakazuje testowanie segmentacji - weryfikację, że kontrole sieciowe redukujące zakres faktycznie uniemożliwiają systemom spoza CDE dotarcie do danych kartowych. Ta strona wyjaśnia mandaty metodyczne Wymogu 11.3, kluczowe zmiany w v4.0 vs v3.2.1, jak prawidłowo zakresować CDE, kiedy skan ASV nie jest wystarczający i jak przygotować dokumentację, która spełni Qualified Security Assessor (QSA).

Uruchom skan PCI-DSS

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

Co PCI-DSS v4.0 faktycznie zmieniło dla testów penetracyjnych

PCI-DSS v4.0 wprowadziła kilka istotnych zmian w wymaganiach testowania penetracyjnego w porównaniu do v3.2.1. Najważniejsze zmiany: (1) Wymóg 11.3.1 wprost wymaga teraz, aby metodyka testu 'obejmowała cały perymetr CDE i krytyczne systemy' - niejasne coroczne testowanie 'ważnych systemów' już nie wystarcza, zakres musi być wprost udokumentowany i uzasadniony. (2) Wymóg 11.3.1.1 dodaje nowy obowiązek dla aplikacji webowych skierowanych do internetu, aby były testowane przy użyciu metodyki OWASP Testing Guide lub równoważnej. Wcześniej Wymóg 6.6 dawał podmiotom opcję wyboru WAF lub testowania aplikacji - v4.0 usuwa opcję WAF-jako-substytutu dla aplikacji PCI skierowanych do internetu. (3) Wymóg 11.3.2 (wewnętrzne testowanie penetracyjne) musi teraz wprost testować ruch z systemów spoza CDE do systemów CDE - symulując scenariusz zagrożenia wewnętrznego. (4) Wymóg 11.4.4 dodaje formalną weryfikację segmentacji: podmioty używające segmentacji sieci do redukcji zakresu PCI muszą testować skuteczność tej segmentacji co najmniej raz w roku, używając konkretnie technik testowania penetracyjnego, a nie tylko przeglądu konfiguracji firewalla. QSA przeglądający Państwa ocenę PCI bez zadowalającej dokumentacji testów penetracyjnych obejmującej wszystkie cztery te wymagania znajdzie niezgodność z Wymogiem 11, blokując zakończenie Raportu o Zgodności (RoC) lub Kwestionariusza Samooceny (SAQ).

PCI-DSS v4.0 Wymóg 11.3.1: coroczny zewnętrzny test penetracyjny perymetru CDE, używając metodyki testowania akceptowanej w branży (OWASP, PTES, NIST SP 800-115), prowadzony przez wykwalifikowanego wewnętrznego lub zewnętrznego testera z organizacyjną niezależnością.
PCI-DSS v4.0 Wymóg 11.3.1.1 (NOWY w v4.0): aplikacje webowe w CDE skierowane do internetu muszą być testowane metodyką OWASP corocznie - sam WAF już nie spełnia tego wymogu.
PCI-DSS v4.0 Wymóg 11.3.2: coroczny wewnętrzny test penetracyjny obejmujący wszystkie komponenty systemu CDE, wprost włączając testy ruchu z segmentów sieci spoza CDE do segmentów CDE.
PCI-DSS v4.0 Wymóg 11.4.4 (testowanie segmentacji): wszelka segmentacja sieci używana do redukcji zakresu PCI musi być weryfikowana przez testowanie penetracyjne co najmniej raz w roku. Awaria segmentacji - gdy tester może przejść z segmentu sieci wykluczonego z zakresu do zasobów CDE - jest najczęstszą przyczyną eksplozji zakresu PCI.
Kwalifikacja testera: PCI-DSS nie wymaga QSA do przeprowadzenia testu, ale tester musi być 'wykwalifikowany' z 'wystarczającym zrozumieniem' Wymogu 11.3 PCI-DSS v4.0. Praktyczne oczekiwanie od QSA: certyfikacja OSCP lub równoważne doświadczenie, znajomość zakresu i kontroli PCI-DSS.
ASV vs Pentest: kwartalne skany Approved Scanning Vendor (ASV) (Wymóg 11.2.2) pokrywają zewnętrzne skanowanie podatności - nie zastępują testowania penetracyjnego. Skany ASV identyfikują znane podatności; testy penetracyjne weryfikują możliwość eksploitacji, ścieżki eskalacji uprawnień i błędy logiki biznesowej, których skany ASV nie wykrywają.
Naprawa i retest: wszelkie eksploitowalne podatności znalezione podczas testów penetracyjnych muszą być naprawione, a test powtórzony w celu weryfikacji naprawy (Wymóg 11.3.3). Ten wymóg retestu jest często pomijany i sygnalizowany przez QSA w czasie oceny.

Co musi obejmować test penetracyjny PCI-DSS Wymóg 11.3

Zewnętrzne testowanie perymetru CDE (Wymóg 11.3.1): wszystkie adresy IP w CDE skierowane do internetu, eksponowane usługi, konfiguracja TLS (PCI-DSS wymaga minimum TLS 1.2, zalecane 1.3 - RC4 i 3DES zabronione), ważność certyfikatów, eksponowane interfejsy administracyjne
Testowanie aplikacji webowej (Wymóg 11.3.1.1): pełne pokrycie OWASP Top 10 - A01 Broken Access Control (IDOR, BOLA), A02 Cryptographic Failures (słabe szyfry, ekspozycja wrażliwych danych), A03 Injection (SQL injection jest głównym wektorem kradzieży danych kartowych), A07 Identification and Authentication Failures
Bezpieczeństwo przepływu płatności: testowanie stron przechwytywania danych kart pod kątem wstrzyknięcia skryptów skimming (ataki łańcucha dostaw w stylu CVE-2023-46604 przez Magecart), integralność JavaScript (SRI), skuteczność Content Security Policy przeciwko wstrzyknięciu skryptu
Wewnętrzne testowanie penetracyjne i ruch lateralny (Wymóg 11.3.2): symulacja atakującego, który skompromitował stację roboczą lub serwer spoza CDE i próbuje dotrzeć do CDE - testowanie reguł firewalla, segmentacji VLAN, ACL i kontroli ruchu east-west
Testowanie segmentacji (Wymóg 11.4.4): aktywne próby przekroczenia kontroli segmentacji ze wszystkich segmentów sieci wykluczonych z zakresu do zasobów CDE - w tym punkty dostępu sieci bezprzewodowej, sieci dostawców zewnętrznych, środowiska call center i sieci zarządzania chmurą
Bezpieczeństwo API (zakres Wymogu 11.3.1.1): API płatności akceptujące dane kart lub tokeny muszą być testowane względem OWASP API Security Top 10 (2023): API1 BOLA, API2 Broken Authentication, API3 Broken Property Level Authorization, API4 Unrestricted Resource Consumption
Uwierzytelnianie i zarządzanie sesjami: kontrole Wymogu 8 PCI-DSS - obejście MFA dla dostępu administracyjnego, testowanie timeoutu sesji, obsługa JWT i kluczy API, egzekwowanie polityki haseł
Korelacja zarządzania podatnościami (Wymóg 6.3.3): weryfikacja, że wszystkie znane CVE dotyczące komponentów CDE są załatane - CVE-2024-4577 (PHP-CGI, CVSS 9.8), CVE-2024-21626 (runc container escape, CVSS 8.6), CVE-2023-3519 (Citrix Bleed, CVSS 9.4)
Integracje z zewnętrznymi dostawcami płatności: weryfikacja zakresu przechwytywania kart w iframe (Stripe, Braintree, Adyen), potwierdzenie, że numery PAN nigdy nie dotykają warstwy aplikacji handlowca
Walidacja logowania i monitoringu (Wymóg 10): weryfikacja, że aktywność ataku podczas testowania generuje alerty SIEM - 'zaatakowaliśmy i nie zostało to zalogowane' jest wynikiem zarówno w ramach Wymogu 11, jak i Wymogu 10

Sample finding

Critical

SQL injection w endpoincie historii zamówień ujawnia numery PAN - naruszenie Wymogu 6.2.4 PCI-DSS

Endpoint historii zamówień /api/orders/search?customer_id= akceptuje niesanityzowany parametr integer, który jest konkatenowany bezpośrednio do zapytania SQL. Używając time-based blind SQL injection payload, tester potwierdził pełny dostęp do odczytu bazy danych. Tabela orders zawiera ostatnie 4 cyfry numerów PAN przechowywane jako tekst jawny (naruszenie Wymogu 3.3), a tabela transactions zawiera tokenizowane PAN-y z mapowaniem token-do-PAN dostępnym przez JOIN. Choć PAN-y są tokenizowane, tabela tokenizacji była dostępna z tego samego konta użytkownika bazy danych. Pełna lista wszystkich PAN-ów klientów mogłaby zostać zrekonstruowana przez atakującego, który wykorzystał ten endpoint. Narusza to PCI-DSS v4.0 Wymóg 6.2.4 (zapobieganie atakom injection) oraz Wymóg 11.3.1.1 (wymóg testowania metodyką OWASP dla aplikacji skierowanych do internetu).

Fix: Używać sparametryzowanych zapytań lub prepared statements dla wszystkich interakcji z bazą danych - nigdy nie konkatenować danych wejściowych użytkownika do ciągów SQL. Dla tego konkretnego endpointa: zastąpić surowy SQL sparametryzowanym zapytaniem ORM lub procedurą składowaną. Przeprowadzić audyt SQL injection całego kodu (SAST z regułą Semgrep p/sql-injection lub równoważną). Dodatkowo: przejrzeć model uprawnień użytkownika bazy danych - konto aplikacji powinno mieć dostęp do odczytu tylko do danych wymaganych do jej funkcji, bez dostępu do tabeli mapowania tokenizacji. Wdrożyć monitorowanie aktywności bazy danych w celu wykrywania anomalnych wzorców zapytań. Zaplanować retest tego endpointa po wdrożeniu poprawki, aby spełnić wymóg weryfikacji naprawy PCI-DSS Wymóg 11.3.3.

Reference: Klasa CVE: CWE-89 SQL Injection · OWASP A03:2021 Injection · PCI-DSS v4.0 Wymóg 6.2.4 · PCI-DSS v4.0 Wymóg 3.3 (przechowywanie skróconego PAN) · PCI-DSS v4.0 Wymóg 11.3.3 (retest naprawy)

Opcje testów penetracyjnych dla PCI-DSS

—	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 PCI-DSS Wymóg 11.3

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 PCI-DSS

Jaka jest różnica między skanem ASV PCI-DSS a testem penetracyjnym?

To dwa oddzielne, niewymienne wymagania PCI-DSS. Skany ASV (Approved Scanning Vendor) w ramach Wymogu 11.2.2 to automatyczne zewnętrzne skany podatności prowadzone kwartalnie przez ASV zatwierdzonego przez PCI-SSC. Identyfikują znane podatności przez dopasowanie sygnatur do baz CVE i testują systemy dostępne zewnętrznie. Testy penetracyjne w ramach Wymogu 11.3 to aktywne testy eksploitacji: wykwalifikowany tester próbuje wykorzystać podatności, połączyć je w łańcuch i wykazać wpływ biznesowy (np. dostęp do danych kartowych). Testy penetracyjne ujawniają błędy logiki, źle skonfigurowane kontrole dostępu, awarie segmentacji i ataki łańcuchowe, których skan ASV nigdy nie znajdzie. Oba są wymagane i służą różnym celom. PCI-DSS wprost stwierdza w wytycznych v4.0, że skany ASV nie spełniają Wymogu 11.3.

Kto może wykonać test penetracyjny PCI-DSS?

PCI-DSS v4.0 Wymóg 11.3.1 wymaga, aby testowanie było wykonywane przez wykwalifikowaną stronę wewnętrzną lub zewnętrzną, która posiada 'wystarczające zrozumienie' wymagań PCI-DSS, używa metodyki akceptowanej w branży i jest 'organizacyjnie niezależna' od testowanych systemów. Nie ma konkretnej certyfikacji PCI-SSC dla testerów penetracyjnych (w przeciwieństwie do QSA czy ASV). W praktyce QSA oceniają kwalifikację testera na podstawie: odpowiednich certyfikacji (OSCP, OSWE, GPEN, CREST CRT), udokumentowanej metodyki (OWASP, PTES lub NIST SP 800-115) oraz oświadczenia o niezależności. Testerzy wewnętrzni nie mogą być odpowiedzialni za testowane systemy. Wiele organizacji używa zewnętrznej firmy testów penetracyjnych do corocznego testu PCI dla niezależności i łatwości akceptacji przez QSA.

Czym jest testowanie segmentacji w PCI-DSS i dlaczego jest krytyczne?

Segmentacja sieci - izolowanie systemów CDE od innych stref sieci - nie jest wymagana przez PCI-DSS, ale drastycznie redukuje zakres PCI. Jeśli macie odpowiednio segmentowane CDE, tylko systemy w tym segmencie muszą być ocenione PCI. Wymóg 11.4.4 nakazuje, aby każdy podmiot używający segmentacji do redukcji zakresu zweryfikował, że segmentacja jest skuteczna przez testowanie penetracyjne. Test musi potwierdzić, że z każdej strefy sieci wykluczonej z zakresu w zakresie (DMZ, korporacyjny LAN, sieć bezprzewodowa, sieć call center, płaszczyzna zarządzania chmurą, VPN dostawcy zewnętrznego), atakujący nie może dotrzeć do zasobów CDE. Awarie segmentacji są wśród najbardziej konsekwentnych wyników PCI: jeśli tester może przejść z sieci korporacyjnej do CDE, Państwa zakres PCI może nagle rozszerzyć się o całą sieć korporacyjną - potencjalnie wymagając pełnej oceny PCI dla tysięcy systemów zamiast setek.

Czym różni się PCI-DSS v4.0 od v3.2.1 dla testów penetracyjnych?

Najbardziej istotne zmiany to: (1) Wymóg 11.3.1.1 (nowy): aplikacje webowe skierowane do internetu muszą być testowane metodyką OWASP - sam WAF już nie spełnia tego dla testowania aplikacji webowej. (2) Wymóg 11.3.2 wprost wymaga teraz testowania ruchu między segmentami spoza CDE i CDE. (3) Wymóg 11.4.4 (zmieniona nazwa z 11.3.5): testowanie segmentacji musi używać technik testowania penetracyjnego, a nie tylko przeglądu konfiguracji. (4) Wymóg 6.4.2: WAF-y są teraz 'automatycznymi rozwiązaniami technicznymi', które muszą wykrywać i zapobiegać atakom webowym - pozostają wymagane, ale już nie zastępują testowania metodyką OWASP. (5) Koncepcja 'customised approach' (nowa w v4.0) pozwala podmiotom wdrożyć alternatywne kontrole, jeśli mogą wykazać równoważne lub lepsze bezpieczeństwo - ale wymaga to znacznie więcej dokumentacji i zatwierdzenia przez QSA. Dla większości podmiotów defined approach (zgodny ze standardowymi wymaganiami) pozostaje prostszy.

Jaką dokumentację QSA musi zobaczyć dla Wymogu 11.3?

Aby QSA podpisał Wymóg 11.3 jako 'spełniony', zazwyczaj wymagają: (1) podpisanego dokumentu zakresu testowania penetracyjnego uzgodnionego z QSA przed testowaniem, wymieniającego wszystkie zakresy IP CDE, aplikacje i wszelkie wykluczone segmenty podlegające testowaniu segmentacji, (2) pełnego raportu z testu penetracyjnego zawierającego użytą metodykę, kwalifikacje testera, wszystkie wyniki z ocenami CVSS i dowodami eksploitacji, (3) dziennika napraw pokazującego status każdego wyniku (eksploitowalne podatności muszą być naprawione zgodnie z Wymogiem 11.3.3), (4) raportu z retestu potwierdzającego, że eksploitowalne podatności zostały naprawione, (5) dla testowania segmentacji: raportu wprost dokumentującego testowane segmenty i wyniki każdej próby przekroczenia segmentu, (6) CV testera lub dowodu certyfikacji wykazującego kwalifikację. Brak któregokolwiek z tych elementów skutkuje wynikiem dotyczącym Wymogu 11 w RoC.

Czy PCI-DSS wymaga testowania penetracyjnego zewnętrznych procesorów płatności?

Jeśli korzystacie z zewnętrznego procesora płatności lub strony płatności (hosted payment page, rozwiązanie iframe), a Państwa środowisko danych posiadaczy kart jest rzeczywiście wykluczone z zakresu w rezultacie, ocena PCI może być prowadzona na podstawie SAQ A - co w ogóle nie wymaga testów penetracyjnych Państwa systemów. Jednak musicie zweryfikować, że poprawnie wdrożyliście redukcję zakresu przez outsourcing (żadne dane PAN nie dotykają Państwa systemów) oraz że Państwa zewnętrzny dostawca utrzymuje własną certyfikację PCI. Dla handlowców używających hybrydowych podejść - hostujących własne strony checkout, ale tokenizujących przez zewnętrzną bramkę - redukcja zakresu może być częściowa, a obowiązki testowania penetracyjnego PCI pozostają dla części środowiska dotykających przepływu płatności.

Jaka jest właściwa kadencja testów penetracyjnych PCI-DSS?

Wymóg 11.3 PCI-DSS nakazuje testowanie 'co najmniej raz w roku' oraz 'po wszelkich istotnych zmianach infrastruktury lub aplikacji'. Istotne zmiany obejmują: nowe komponenty systemu w CDE, aktualizacje oprogramowania wpływające na systemy w zakresie, zmiany infrastruktury (nowe segmenty sieci, modyfikacje reguł firewalla), nowe zewnętrzne połączenia z CDE oraz zmiany mechanizmów uwierzytelniania aplikacji. W praktyce organizacje z aktywnym rozwojem (wiele wydań miesięcznie) powinny wdrożyć ciągłe testowanie automatyczne (Matproof Sentinel) w celu wychwytywania regresji bezpieczeństwa między corocznymi ustrukturyzowanymi testami. Coroczny ustrukturyzowany test u zewnętrznego wykwalifikowanego dostawcy spełnia wymóg dokumentacyjny Wymogu 11.3; ciągłe skanowanie zapewnia pewność między cyklami.

Czy Matproof Sentinel może spełnić PCI-DSS Wymóg 11.3?

Testowanie Matproof Sentinel obejmuje techniczny zakres Wymogu 11.3 (OWASP Top 10, bezpieczeństwo API, uwierzytelnianie, TLS, konfiguracja). Raport wyjściowy zawiera: udokumentowaną metodykę, oceny CVSS, dowód eksploitacji, zalecenia naprawcze i zdolność retestu - wszystkie elementy dokumentacji, których potrzebują QSA. Dla ocen na poziomie SAQ D i RoC, QSA zazwyczaj oczekują, że zewnętrzny komponent testu penetracyjnego będzie prowadzony przez identyfikowalnego wykwalifikowanego testera-człowieka (nie wyłącznie automatyczne narzędzia). Podejście najbardziej akceptowane przez QSA to: Matproof Sentinel do ciągłego testowania i testowania przed wydaniem, uzupełnione corocznym zewnętrznym testem penetracyjnym u wykwalifikowanego dostawcy, który podpisuje dokumentację zlecenia. Raporty Sentinel mogą służyć jako dowody wspierające dla przeglądu QSA nawet w tym połączonym podejściu.

Go deeper — related blog articles

Rozpocznij test penetracyjny PCI-DSS Wymóg 11.3

Matproof Sentinel dostarcza testowanie metodyką OWASP z dokumentacją akceptowaną przez QSA - wyniki w zakresie CDE, oceny CVSS, dowód eksploitacji i śledzenie napraw. Zacznij od darmowego skanu lub uzyskaj pełny raport gotowy do audytu od €149.