Zaktualizowano: 29 września 2026
Czym jest PCI DSS i po co istnieje? PCI DSS (Payment Card Industry Data Security Standard) to zbiór wymagań bezpieczeństwa stworzony przez Visa, Mastercard, American Express, Discover i JCB za pośrednictwem PCI SSC (Security Standards Council) dla organizacji przetwarzających, przechowujących lub przesyłających dane kart płatniczych. Naruszenie danych kartowych ma wymierny ko szt finansowy: kary acquirera (10 000-500 000 USD za incydent), utrata prawa do akceptacji kart, odszkodowania dla banków za fałszywe transakcje, koszty incydentu.
PCI DSS nie jest opcją dla organizacji obsługujących karty – jest warunkiem umowy z acquirerem. Aktualna wersja to v4.0.1 (minor revision do v4.0 z czerwca 2024). Wszystkie nowe wymagania wprowadzone jako „best practice” w v4.0 stały się obowiązkowe od 31 marca 2025.
Wymagania PCI DSS v4.0.1 – w skrócie:
- 12 wymagań PCI DSS pogrupowanych w 6 celów: bezpieczna sieć, ochrona danych, zarządzanie podatnościami, kontrola dostępu, monitoring i testowanie, polityki bezpieczeństwa
- 31 marca 2025: nowe wymagania stały się obowiązkowe – w tym 11.3.1.2 (uwierzytelnione skany wewnętrzne), 6.4.3 (inwentarz i integralność skryptów na stronach płatności), 11.4.1 (dokumentacja metodologii pentestów)
- SAQ (Self-Assessment Questionnaire) vs ROC (Report on Compliance): Level 1 merchantci i Level 1 service providerzy wymagają ROC od QSA; pozostali mogą korzystać z SAQ odpowiedniego dla modelu przetwarzania
- CDE (Cardholder Data Environment) definiuje zakres certyfikacji – systemy poza CDE nie podlegają PCI DSS; redukcja zakresu przez tokenizację lub P2PE jest najpopularniejszą strategią obniżenia kosztu compliance
- PCI DSS compliance nie gwarantuje bezpieczeństwa – TJX, Target i Equifax były certyfikowane w czasie naruszeń; compliance to minimum, nie cel sam w sobie
- Patronusec jako akredytowany QSA przeprowadza certyfikacje PCI DSS dla merchantów i service providerów – od scope assessment przez gap analysis po Attestation of Compliance
Spis treści
Co oznaczają wymagania PCI DSS v4.0.1 w praktyce?
Wymaganie 1 – Bezpieczna konfiguracja sieci
Firewalle, Network Access Control, dokumentacja reguł z uzasadnieniem biznesowym, segmentacja CDE od reszty sieci. Najtrudniejszy element: recertyfikacja reguł firewall co 6 miesięcy i aktualność diagramu sieciowego na dzień audytu.
Wymaganie 2 – Bezpieczne konfiguracje systemów
Zmień domyślne hasła, wyłącz niepotrzebne serwisy i protokoły, dokumentuj konfigurację bazową per typ systemu. Najtrudniejszy element: utrzymanie aktualności konfiguracji bazowych przez cały rok certyfikacyjny.
Wymaganie 3 – Ochrona przechowywanych danych kont
Nie przechowuj SAD po autoryzacji, zaszyfruj PAN w bazach danych, maskuj PAN na wyświetlaczach. Najtrudniejszy element: zinwentaryzowanie WSZYSTKICH miejsc gdzie PAN może być przechowywany – logi, backupy, pliki tymczasowe, bazy testowe.
Wymaganie 4 – Ochrona danych w transmisji
TLS 1.2+ dla wszystkich połączeń przesyłających CHD, zakaz SSL, TLS 1.0, TLS 1.1, WEP. Najtrudniejszy element: zinwentaryzowanie wszystkich ścieżek transmisji i potwierdzenie szyfrowania end-to-end w integracji z dostawcami.
Wymaganie 5 – Ochrona przed złośliwym oprogramowaniem
Anti-malware na systemach powszechnie atakowanych przez malware, regularne aktualizacje sygnatur, logi audytu z antimalware. Od v4.0.1: wymagana ocena ryzyka dla wszystkich systemów (nie tylko „popularnych” typów).
Wymaganie 6 – Bezpieczne systemy i oprogramowanie
Zarządzanie podatnościami, SDLC, code review dla aplikacji płatniczych, WAF i nowe w v4.0.1: inwentarz skryptów na stronach płatności z weryfikacją integralności (6.4.3). To najczęstszy blocking finding po 31 marca 2025.
Wymaganie 7 – Ograniczenie dostępu
Least privilege dla każdego konta, role-based access control, dokumentacja uzasadnienia biznesowego dla każdego poziomu dostępu. Najtrudniejszy element: regularne przeglądy i usuwanie kont nieaktywnych lub zbędnych.
Wymaganie 8 – Identyfikacja i uwierzytelnianie
Nowe w v4.0.1: MFA dla WSZYSTKICH dostępów do CDE (8.4.2) – nie tylko zdalnych jak w v3.2.1. To najczęściej zaskakuje organizacje re-certyfikowane w v4.0.1. Najtrudniejszy element: wdrożenie MFA dla dostępu administracyjnego z sieci wewnętrznej.
Wymaganie 9 – Fizyczne bezpieczeństwo
Kontrola dostępu do datacenter i serwerowni, CCTV przy terminalach, zabezpieczenie terminali przed skimmerami, inwentaryzacja urządzeń. Najtrudniejszy element dla sieci retailowych: zarządzanie terminalami w setkach lokalizacji.
Wymaganie 10 – Logowanie i monitoring
Audit logi dla wszystkich operacji na CHD, centralny SIEM, retencja 12 miesięcy (3 miesiące online). Najtrudniejszy element: kompletność logowania – organizacje często logują aplikację, ale nie infrastrukturę sieciową lub nie logują dostępu do baz danych.
Wymaganie 11 – Testowanie bezpieczeństwa
Kwartalne skany ASV (zewnętrzne), kwartalne skany wewnętrzne (uwierzytelnione od 31 marca 2025 – wymaganie 11.3.1.2), roczny pentest z dokumentowaną metodologią (11.4.1), coroczne testowanie segmentacji. Trzy nowe wymagania obowiązujące od 31 marca 2025.
Wymaganie 12 – Polityki i programy bezpieczeństwa
Polityka bezpieczeństwa przeglądana co roku, program awareness, zarządzanie TPSP (12.8), zarządzanie incydentami (12.10). Najtrudniejszy element: 12.8 – aktualny AOC dla każdego Tier 1 TPSP, Responsibility Matrix.
Patronusec Insight: Wymaganie 6.4.3 jest najczęstszym blocking findingiem w pierwszych audytach po 31 marca 2025. Typowa strona płatności e-commerce ładuje dziesiątki skryptów stron trzecich – Google Analytics, Meta Pixel, chat widget, A/B testing, cookie consent, CDN – każdy musi być zinwentaryzowany z uzasadnieniem biznesowym i weryfikacją integralności (SRI hash lub CSP nonce). W ramach scope assessment analizujemy strony płatności klienta i identyfikujemy wszystkie skrypty wymagające inventory i integrity controls zanim QSA to odkryje podczas audytu.
Jak określić zakres CDE i kiedy opłaca się go redukować?
Zakres PCI DSS (CDE – Cardholder Data Environment) obejmuje wszystkie systemy, które przechowują, przetwarzają lub transmitują dane kart płatniczych, ORAZ systemy, które mogą wpłynąć na ich bezpieczeństwo (connected-to systemy). Im szerszy CDE, tym więcej systemów podlega wszystkim 12 wymaganiom i tym droższy audyt.
Trzy strategie redukcji zakresu CDE:
Tokenizacja przez certyfikowanego PSP: Jeśli Twoja platforma e-commerce używa elementu płatności w iFrame (Stripe, Adyen, PayU) i Twoje systemy nigdy nie widzą PAN – Twój zakres może spaść z SAQ D (300+ pytań) do SAQ A (ok. 22 pytania). To najczęstsza i najbardziej efektywna kosztowo redukcja zakresu.
P2PE (Point-to-Point Encryption) przez certyfikowane rozwiązanie: Dla środowisk z fizycznymi terminalami – certyfikowane P2PE redukuje zakres wymagań dla handlowca obsługującego terminale. Szyfrowanie danych kartowych od terminala do HSM procesora – Twoje systemy widzą wyłącznie zaszyfrowane dane.
Segmentacja sieciowa: Systemy CDE izolowane od reszty infrastruktury przez firewalle i ścisłe reguły ruchu sieciowego. Segmentacja musi być weryfikowana technicznie przez testy penetracyjne (Wymaganie 11.4.4) – dokumentacja segmentacji bez technicznego testu nie spełnia wymagania.
Patronusec Insight: Najczęstszy błąd w scope assessment, który widzimy: organizacja zakłada że jej systemy są poza CDE, bo nie „widzą” numeru karty. Ale serwer webowy serwujący stronę płatności (nawet z iFrame innego dostawcy) może być connected-to CDE jeśli może wpłynąć na bezpieczeństwo środowiska płatniczego – np. przez kompromitację i wstrzyknięcie złośliwego skryptu. Wymaganie 6.4.3 (inwentarz skryptów na stronie płatności) istnieje właśnie z tego powodu. W ramach scope assessment mapujemy rzeczywisty zakres CDE uwzględniając connected-to systemy, które organizacja często pomija.
Nie jesteś pewien jaki jest rzeczywisty zakres Twojego CDE i ile systemów podlega PCI DSS?
Patronusec jako akredytowany QSA przeprowadza scope assessment – mapujemy CDE, identyfikujemy connected-to systemy i oceniamy możliwości redukcji zakresu przed formalnym audytem.
Jakie zmiany v4.0.1 vs v3.2.1 są najważniejsze operacyjnie?
| Wymaganie | Co się zmieniło | Data obowiązywania |
|---|---|---|
| 6.4.3 | Inwentarz i integralność skryptów na stronach płatności | 31 marca 2025 |
| 8.4.2 | MFA dla wszystkich dostępów do CDE (nie tylko zdalnych) | 31 marca 2025 |
| 11.3.1.2 | Wewnętrzne skany podatności muszą być uwierzytelnione | 31 marca 2025 |
| 11.4.1 | Metodologia pentestów musi być udokumentowana przed testem | 31 marca 2025 |
| 12.3.4 | Przegląd sprzętu i oprogramowania pod kątem EOL co 12 mies. | 31 marca 2025 |
| Customised approach | Nowa opcja: własne kontrole spełniające intent wymagania | Od v4.0 (marzec 2022) |
Nie wiesz, które nowe wymagania v4.0.1 dotyczą Twojego środowiska i jak je spełnić przed audytem?
Patronusec jako akredytowany QSA przeprowadza gap analysis specyficznie dla wymagań v4.0.1, które weszły w życie 31 marca 2025 – z priorytetyzacją według ryzyka audytowego i planem remediation.
Zamów gap analysis PCI DSS v4.0.1
FAQ – PCI DSS 12 wymagań
Czy muszę spełnić wszystkie 12 wymagań?
Tak i nie. Wszystkie 12 wymagań potencjalnie obowiązuje, ale które aspekty są stosowalne – zależy od zakresu CDE i modelu przetwarzania kart. SAQ A (pełny outsourcing) ma ok. 22 pytań i wyklucza wiele wymagań jako inapplicable. SAQ D ma 300+ pytań. Odpowiedni SAQ lub konieczność ROC określa Twój acquirer lub schemat kartowy.
Czym różni się SAQ od ROC?
SAQ (Self-Assessment Questionnaire) to samocertyfikacja – organizacja sama ocenia zgodność i podpisuje dokument. ROC (Report on Compliance) to formalny raport wystawiany przez akredytowanego QSA po niezależnym audycie. Level 1 merchantci i Level 1 service providerzy wymagają ROC. Pozostali mogą korzystać z SAQ, o ile ich acquirer to akceptuje.
Co to jest tokenizacja i jak redukuje zakres PCI DSS?
Tokenizacja zastępuje PAN (numer karty) tokenem niemającym matematycznego związku z oryginalną kartą. Jeśli Twoje systemy widzą wyłącznie tokeny – nigdy PAN – te systemy mogą być wyłączone z CDE. Skuteczna tokenizacja przez certyfikowanego PSP może drastycznie zredukować zakres certyfikacji – nawet z SAQ D do SAQ A.
Jak długo ważny jest AOC (Attestation of Compliance)?
12 miesięcy. Certyfikacja musi być odnawiana co roku. W trakcie roku: kwartalne skany ASV i wewnętrzne muszą być utrzymywane przez cały rok – nie tylko przed audytem rocznym.
Co się zmieniło w wymaganiu 8 (uwierzytelnianie) w v4.0.1?
Kluczowa zmiana: MFA jest teraz wymagane dla WSZYSTKICH dostępów do CDE (Wymaganie 8.4.2) – nie tylko dla dostępów zdalnych jak w v3.2.1. Oznacza to, że administratorzy logujący się do systemów CDE z sieci wewnętrznej również muszą używać MFA. To jest najczęstszy gap w organizacjach re-certyfikowanych po raz pierwszy w v4.0.1.
Ile kosztuje certyfikacja PCI DSS z Patronusec?
Cena zależy od poziomu merchanty lub service providera i środowiska. Po bezpłatnej 30-minutowej rozmowie scope-assessment przedstawiamy stałą wycenę z podziałem na etapy (gap analysis, audyt, wsparcie po-audytowe). Dla klientów realizujących u nas i pentest i audyt PCI DSS oferujemy preferencyjne pakiety.
Certyfikacja PCI DSS – bezpłatna konsultacja
Patronusec jako akredytowany QSA certyfikuje merchantów i service providerów PCI DSS na każdym poziomie – od SAQ A po ROC Level 1 – w sektorach fintech, e-commerce i finansowym.
W bezpłatnej 30-minutowej konsultacji pomożemy Ci:
- Określić poziom merchanty i właściwy SAQ lub ROC dla Twojego środowiska
- Ocenić zakres CDE i możliwości jego redukcji przed certyfikacją
- Zidentyfikować które nowe wymagania v4.0.1 wymagają natychmiastowego działania
- Przedstawić transparentną wycenę projektu certyfikacyjnego
Bezpłatna konsultacja | Certyfikacja PCI DSS | Analiza luk PCI DSS | Testy penetracyjne | Skany podatności
