Pułapki certyfikacji PCI DSS v4.0.1

Zaktualizowano: 3 lipca 2026

Czym są pułapki certyfikacji PCI DSS? To obszary, w których firmy przystępujące do audytu PCI DSS najczęściej otrzymują findings (niezgodności) – mimo że przed audytem były przekonane, że spełniają wymogi. Wynikają zwykle z różnicy między literalnym brzmieniem wymogu a tym, jak QSA interpretuje go w praktyce, lub z zmian wprowadzonych przez PCI DSS v4.0.1 (obowiązujące w pełni od 31 marca 2025). Każde finding oznacza projekt remediacji, opóźnienie certyfikacji i dodatkowe koszty. Poniżej 7 pułapek zidentyfikowanych podczas wieloletnich audytów PCI DSS.

PCI DSS v4.0.1 – najczęstsze pułapki certyfikacji PCI DSS w skrócie:

Firmy zakładają, że nie przetwarzają danych kartowych i są poza zakresem – podczas gdy systemy connected-to do CDE wchodzą w zakres bez wyjątków
MFA (wieloskładnikowe uwierzytelnianie) jest wymagane od 31 marca 2025 dla wszystkich dostępów do CDE – nie tylko dla zdalnych
Skany uwierzytelnione (11.3.1.2) są obowiązkowe od 31 marca 2025 – wiele firm nadal dostarcza skany nieuwierzytelnione
AOC i Responsibility Matrix wszystkich dostawców TPSP musi być zebrane i zaktualizowane co roku (wymóg 12.8)
Metodyka pentestów musi być udokumentowana i zaaprobowana przed testem (wymóg 11.4.1 – nowy od v4.0.1)
Skrypty, iFramy i kody śledzące na stronach płatniczych e-commerce muszą być zarządzane i monitorowane (wymóg 6.4.3)
Patronusec jako QSA wykonuje pre-audit gap analysis, by klient znał pułapki przed właściwym audytem, nie w jego trakcie

Spis treści

Dlaczego „nie przechowujemy danych kartowych” nie oznacza bycia poza zakresem PCI DSS?

To pierwsza i najkosztowniejsza pułapka. Firma przekonana, że „nie przechowuje kart, więc PCI DSS ich nie dotyczy” może zostać zaskoczona podczas audytu rozległością zakresu.

Dlaczego systemy non-CHD mogą być w zakresie:

PCI DSS v4.0.1 wyróżnia trzy kategorie systemów w zakresie:

Systemy przechowujące, przetwarzające lub przesyłające CHD
Systemy connected-to – mające łączność sieciową z systemami CHD lub mogące wpłynąć na ich bezpieczeństwo
Systemy dostarczające usługi bezpieczeństwa dla CDE

Kategoria 2 (connected-to) to pułapka. Serwery Active Directory zarządzające kontami dostępu do CHD serwerów, systemy SIEM zbierające logi z CDE, helpdesk z dostępem do ticketów zawierających informacje o systemach CDE – wszystkie te systemy są connected-to i wchodzą w zakres.

Jak sprawdzić, czy system jest connected-to:

Czy ten system może inicjować połączenie sieciowe z systemem CHD?
Czy ten system może odebrać połączenie z systemu CHD?
Czy kompromitacja tego systemu mogłaby dać atakującemu dostęp lub informacje przydatne do ataku na CHD?

Jeśli odpowiedź na któreś z pytań brzmi „tak” – system jest connected-to.

Patronusec Insight: Scenariusz, który powtarza się w naszych projektach: fintech certyfikujący się po raz pierwszy zakłada, że zakres to 3 serwery aplikacji płatniczej. Po scope assessment okazuje się, że Active Directory, system MDM zarządzający laptopami z dostępem do CDE, system monitoringu sieci i platforma helpdesk to wszystko connected-to. Realny zakres to 12-15 systemów. Bez scope assessment klient dostałby to odkrycie podczas Stage 2 audytu, czyli w najgorszym możliwym momencie. Przeprowadzamy scope assessment PCI DSS zanim zaczniemy wyceniać audyt.

Jakie są wymogi MFA w PCI DSS v4.0.1 i kiedy są obowiązkowe?

Wieloskładnikowe uwierzytelnianie (MFA) to jedna z najważniejszych zmian PCI DSS v4.0.1 obowiązujących od 31 marca 2025.

PCI DSS v4.0.1 wymóg 8.4:

8.4.2: MFA jest wymagane dla wszystkich dostępów do CDE – nie tylko zdalnych. Zmiana względem v3.2.1, która wymagała MFA tylko dla dostępu zdalnego.
8.4.3: MFA jest wymagane dla wszystkich dostępów zdalnych do sieci spoza CDE (nawet jeśli nie prowadzą bezpośrednio do CDE)

Kogo dotyczy wymóg MFA:

Administratorzy IT z dostępem do serwerów i urządzeń w CDE
Deweloperzy z dostępem do środowisk produkcyjnych CDE
Dostawcy i podwykonawcy z dostępem zdalnym do sieci lub systemów organizacji
Wszyscy użytkownicy z dostępem do konsol zarządzania (AWS Console, Azure Portal, VMware vCenter) w zakresie CDE

Akceptowalne metody MFA:

Aplikacje TOTP (Google Authenticator, Microsoft Authenticator, Duo)
Klucze sprzętowe FIDO2/WebAuthn (YubiKey, Titan Key)
Push notification (Duo Push, Okta Verify)
SMS/voice – niezalecane i coraz częściej odrzucane przez QSA jako słaba metoda ze względu na ryzyko SIM swapping

Nie jesteś pewien, czy Twój obecny system MFA spełnia wymóg 8.4 PCI DSS v4.0.1?

Patronusec przeprowadza techniczny review konfiguracji MFA pod kątem wymogów PCI DSS. W ciągu 5 dni roboczych dostarczamy pisemną ocenę i rekomendacje – zanim QSA zidentyfikuje problem podczas audytu.

Zamów review konfiguracji MFA

Dlaczego skany nieuwierzytelnione nie spełniają wymogu 11.3.1.2 PCI DSS v4.0.1?

PCI DSS v4.0.1 wymóg 11.3.1.2 (obowiązkowy od 31 marca 2025) nakłada wymóg stosowania skanów uwierzytelnionych (ang. authenticated scans) dla skanowania wewnętrznego środowiska CDE.

Różnica między skanem uwierzytelnionym a nieuwierzytelnionym:

Skan nieuwierzytelniony (ang. unauthenticated lub non-credentialed scan) łączy się z hostem jak anonim – skanuje otwarte porty, banery usług i zewnętrznie widoczne podatności. Wykrywa to, co widać z zewnątrz.

Skan uwierzytelniony (ang. authenticated lub credentialed scan) loguje się do systemu z poświadczeniami – weryfikuje brakujące patche, konfiguracje systemu operacyjnego, zainstalowane oprogramowanie i podatności niewidoczne z zewnątrz. Wykrywa 3-5 razy więcej podatności.

Dlaczego to ważne:

QSA oceniając raport ze skanu pyta: czy skan był uwierzytelniony? Jeśli nie – skan nie spełnia wymogu 11.3.1.2 i jest finding. Firma musi powtórzyć skany z prawidłową konfiguracją.

Jak poprawnie skonfigurować skany uwierzytelnione:

Stwórz dedykowane konto skanera z minimalnym dostępem (read-only wystarczy dla większości scannerów)
Skonfiguruj poświadczenia w platformie skanującej (Tenable, Qualys, Rapid7)
Zweryfikuj, że skaner loguje się do hostów (w raporcie powinna być informacja o sukcesie logowania)
Przechowuj poświadczenia skanera zgodnie z wymogami zarządzania kluczami

Patronusec Insight: Z naszych audytów QSA wynika, że ok. 70% firm, które przychodzą na pierwszy audyt PCI DSS v4.0.1 z wynikami skanów, ma skany nieuwierzytelnione – co jest bezpośrednim wynikiem tego, że wymóg 11.3.1.2 był „future-dated” do 31 mar 2025 i wiele firm nie zaktualizowało procedur. Finding przy skanach nieuwierzytelnionych opóźnia audyt o 4-8 tygodni (czas konfiguracji + nowe skany + re-review). W ramach naszych skanów podatności konfigurujemy i weryfikujemy uwierzytelnianie skanerów na początku każdego projektu.

Jak prawidłowo zarządzać dostawcami (TPSP) zgodnie z wymogiem 12.8 PCI DSS v4.0.1?

Zarządzanie dostawcami to jeden z wymogów z najwyższą liczbą findings w audytach PCI DSS – szczególnie dla firm korzystających z chmury i zewnętrznych usług IT.

Co wymaga PCI DSS v4.0.1 od zarządzania TPSP (12.8):

12.8.1: Lista wszystkich TPSP z opisem usług i zakresem dostępu do CHD
12.8.2: Pisemna umowa z każdym TPSP zawierająca wymagania bezpieczeństwa PCI DSS
12.8.3: Ustalony proces due diligence przed zaangażowaniem nowego TPSP
12.8.4: Monitorowanie statusu zgodności PCI DSS wszystkich TPSP co roku
12.8.5: Udokumentowany podział odpowiedzialności za kontrole PCI DSS między organizacją a TPSP

Typowe findings przy zarządzaniu TPSP:

Brak listy TPSP (lub lista niekompletna)
Brak pisemnych umów zawierających wymagania PCI DSS
Brak aktualnych AOC od kluczowych dostawców (chmura, procesor płatności)
Brak Responsibility Matrix z podziałem kontroli

Dlaczego wymóg 6.4.3 PCI DSS v4.0.1 zaskakuje sklepy e-commerce?

Wymóg 6.4.3 (obowiązkowy od 31 marca 2025) dotyczy zarządzania skryptami i kodem ładowanym na strony płatnicze e-commerce – w tym skryptów analitycznych, chat widgetów, reklam i iFrame’ów.

Co wymaga 6.4.3:

Inwentarz wszystkich skryptów załadowanych na stronach płatniczych z uzasadnieniem każdego
Metoda potwierdzenia integralności każdego skryptu (np. Subresource Integrity, CSP)
Pisemna zgoda na każdy skrypt (authorization)

Dlaczego to zaskakuje:

Wiele sklepów e-commerce używa dziesiątek skryptów na stronach checkout – Google Analytics, Facebook Pixel, Hotjar, chat support, reklamy. Żaden z tych skryptów nie był dotychczas „problemem PCI DSS”. Od v4.0.1 każdy musi być zinwentaryzowany, uzasadniony i monitorowany pod kątem integralności – bo skompromitowany skrypt może przechwycić dane kartowe (tzw. skimming/formjacking, jak atak Magecart).

FAQ – Pułapki certyfikacji PCI DSS

Jakie zmiany PCI DSS v4.0.1 obowiązują od 31 marca 2025?

Od 31 marca 2025 obowiązują wszystkie tzw. „future-dated” wymagania PCI DSS v4.0.1, w tym: skany uwierzytelnione (11.3.1.2), rozszerzone MFA (8.4.2 dla wszystkich dostępów do CDE), zarządzanie skryptami e-commerce (6.4.3 i 11.6.1), udokumentowana metodyka pentestów (11.4.1) i kilkadziesiąt innych nowych lub zmienionych wymagań.

Czym różni się finding minor od major w audycie PCI DSS?

Finding minor (obserwacja) to niepełne spełnienie wymogu przy ogólnie dobrym kierunku – może nie blokować certyfikacji, ale wymaga planu naprawczego. Finding major to brak spełnienia kluczowego wymogu – blokuje wystawienie AOC do czasu remediacji i re-audytu obszaru.

Czy można uzyskać certyfikat PCI DSS z otwartymi findings?

Nie dla findings kategorii major. QSA może wystawić AOC dopiero po potwierdzeniu remediacji wszystkich wymagań. W praktyce klienci z findings major wdrażają poprawki i przechodzą re-audit konkretnego obszaru – nie całego audytu od nowa.

Jak długo trzeba przechowywać dowody na potrzeby audytu PCI DSS?

PCI DSS wymaga przechowywania logów przez 12 miesięcy z dostępnością ostatnich 3 miesięcy (wymóg 10.7). Dokumenty polityk i procedur muszą być przechowywane przez czas ich obowiązywania plus odpowiedni bufor po ich wycofaniu. Raporty z audytów i pentestów – minimum 12 miesięcy.

Jak Patronusec pomaga unikać pułapek certyfikacji PCI DSS?

Przeprowadzamy pre-audit gap analysis, podczas której identyfikujemy wszystkie typowe pułapki przed właściwym audytem. Klient dostaje listę obszarów do poprawy z priorytetami i harmonogramem remediacji – i ma 2-3 miesiące na zamknięcie braków zanim QSA zacznie właściwy audit. Po bezpłatnej konsultacji wstępnej określamy, ile pułapek dotyczy konkretnej organizacji.

Ile kosztuje pre-audit gap analysis PCI DSS w Patronusec?

Koszt zależy od zakresu i złożoności środowiska. Patron usec przedstawia stałą wycenę po bezpłatnej rozmowie wstępnej. Inwestycja w gap analysis jest zwykle kilkukrotnie niższa niż koszt remediacji findings odkrytych podczas właściwego audytu. Dla klientów zamawiających u nas gap analysis + audyt + pentesty oferujemy preferencyjne ceny pakietowe.

Certyfikacja PCI DSS – bezpłatna konsultacja

Patronusec jako akredytowany QSA widział setki findings w audytach PCI DSS – wiemy, gdzie firmy popełniają błędy i jak ich unikać. Pre-audit gap analysis to usługa, która przenosi odkrycia z audytu na etap przygotowań.

W bezpłatnej 30-minutowej konsultacji pomożemy Ci:

Zidentyfikować, które z 7 pułapek prawdopodobnie dotyczy Twojej organizacji
Ocenić, czy Twoje środowisko jest gotowe na wymagania PCI DSS v4.0.1 od 31 marca 2025
Zaplanować pre-audit gap analysis i harmonogram remediacji przed właściwym audytem
Wybrać model współpracy adekwatny do Twojego harmonogramu certyfikacji

Bezpłatna konsultacja | Certyfikacja PCI DSS | Analiza luk PCI DSS | Testy penetracyjne | Skany podatności ASV