Zgodność z PCI DSS jest jednym z podstawowych wymogów bezpieczeństwa dla firm, które akceptują, przetwarzają, przechowują lub w inny sposób uczestniczą w obsłudze danych kart płatniczych. W przypadku sprzedawców, firm FinTech, dostawców płatności, platform SaaS i marketplace'ów wpływa ona na znacznie więcej niż sam formularz płatności.
PCI DSS może wpływać na architekturę płatności, wybór dostawców, infrastrukturę, rozwój oprogramowania, kontrolę dostępu, monitoring, procesy operacyjne i reagowanie na incydenty. Może również zdecydować o tym, jak skomplikowane i kosztowne będzie późniejsze utrzymanie środowiska płatniczego.
Kiedy mówi się o PCI compliance, zazwyczaj chodzi o zgodność z Payment Card Industry Data Security Standard, czyli PCI DSS. Jest to globalny standard bezpieczeństwa określający wymagania służące ochronie danych dotyczących rachunków płatniczych w ekosystemie kartowym.
Według stanu na 2026 rok aktualną wersją standardu jest PCI DSS v4.0.1. PCI DSS v4.0 został wycofany 31 grudnia 2024 roku, a wymagania, które wcześniej miały charakter odroczony, zaczęły obowiązywać 31 marca 2025 roku. Aktualne dokumenty standardu publikuje PCI Security Standards Council.
Najważniejsze pytanie nie brzmi jednak wyłącznie: „jak spełnić PCI DSS?”. Dla wielu firm znacznie ważniejsze jest inne:
Jak bardzo nasza architektura niepotrzebnie komplikuje zgodność z PCI DSS?
Dwie firmy mogą oferować klientowi niemal identyczny checkout, a jednocześnie mieć zupełnie inny zakres PCI DSS, liczbę systemów podlegających kontroli, obowiązki dokumentacyjne i koszt przygotowania do walidacji. Właśnie dlatego PCI DSS powinno być uwzględniane już podczas projektowania produktu i architektury płatniczej.
Zgodność z PCI DSS oznacza spełnianie wymagań PCI DSS mających zastosowanie do konkretnej organizacji i jej środowiska.
PCI DSS, czyli Payment Card Industry Data Security Standard, to globalny standard bezpieczeństwa opracowany dla organizacji uczestniczących w obsłudze płatności kartowych. Określa techniczne i operacyjne wymagania dotyczące ochrony danych rachunków płatniczych.
Standard obejmuje między innymi bezpieczeństwo sieci, ochronę danych, kryptografię, zarządzanie podatnościami, bezpieczny rozwój oprogramowania, kontrolę dostępu, uwierzytelnianie, logowanie, monitoring, testowanie bezpieczeństwa i zarządzanie dostawcami zewnętrznymi.
PCI DSS nie jest jednak instrukcją budowy produktu płatniczego. Nie mówi firmie, którego PSP powinna wybrać, czy checkout powinien działać przez redirect, iframe czy własny formularz ani jaki model zapewni najlepszą konwersję.
Firma może posiadać bardzo bezpieczny technicznie formularz płatności, a jednocześnie mieć źle zarządzane środowisko PCI z powodu zbyt szerokich uprawnień, niekontrolowanych dostawców, słabego monitoringu albo danych kartowych pojawiających się w miejscach, w których nigdy nie powinny się znaleźć.
PCI DSS jest przeznaczony dla podmiotów, które przechowują, przetwarzają lub przesyłają dane posiadaczy kart albo mogą wpływać na bezpieczeństwo Cardholder Data Environment.
Dotyczy to między innymi sprzedawców akceptujących karty, procesorów płatności, agentów rozliczeniowych, issuerów oraz wielu dostawców usług.
Wielkość firmy sama w sobie nie powoduje, że PCI DSS przestaje mieć zastosowanie. Mały sklep internetowy i duży procesor płatności mogą podlegać standardowi, ale ich zakres obowiązków i sposób walidacji będą zupełnie inne.
Niewielki sklep korzystający z pełnego przekierowania do hostowanej strony płatniczej PSP może mieć stosunkowo ograniczony zakres. Firma, której własne systemy przyjmują, przesyłają lub przechowują PAN, może posiadać znacznie szersze środowisko objęte kontrolami.
Istotną kategorią są również dostawcy usług. Firma nie musi sama przechowywać numerów kart, aby znaleźć się w zakresie PCI. Jeżeli świadczona przez nią usługa może wpływać na bezpieczeństwo CDE klienta, część jej środowiska i kontroli może podlegać wymaganiom PCI DSS.
Dlatego w przypadku firm SaaS, FinTech i technologicznych pytanie „czy przechowujemy numery kart?” jest zbyt wąskie. Należy również sprawdzić, czy systemy, administratorzy, procesy lub usługi firmy mogą wpływać na środowisko, w którym dane kartowe są chronione.
PCI DSS posługuje się pojęciem danych rachunku płatniczego, które obejmuje przede wszystkim Cardholder Data oraz Sensitive Authentication Data.
Cardholder Data (CHD) obejmuje Primary Account Number, czyli PAN. W zależności od sposobu przechowywania i przetwarzania wraz z PAN mogą występować również takie informacje jak imię i nazwisko posiadacza karty, data ważności czy kod serwisowy.
Sensitive Authentication Data (SAD), czyli dane wrażliwe wykorzystywane do uwierzytelniania, obejmują między innymi pełne dane ścieżki magnetycznej lub ich odpowiednik z chipa, kody weryfikacyjne karty takie jak CVV2, CVC2 czy CID oraz PIN i PIN block.
Rozróżnienie to jest ważne, ponieważ PCI DSS zabrania przechowywania SAD po autoryzacji transakcji, nawet jeśli dane są zaszyfrowane. Dotyczy to między innymi kodów CVV/CVC. Zgoda klienta nie tworzy wyjątku od tej zasady. PCI SSC opisuje tę kwestię między innymi w oficjalnym FAQ dotyczącym przechowywania kodów weryfikacyjnych.
Z punktu widzenia architektury firma powinna zbierać i przetwarzać tylko te dane kartowe, które są rzeczywiście potrzebne do działania produktu. Każdy niepotrzebny przepływ PAN zwiększa powierzchnię ataku, liczbę systemów wymagających ochrony oraz potencjalny zakres PCI DSS.
Jedną z najważniejszych części przygotowania do PCI DSS jest prawidłowe określenie zakresu.
Cardholder Data Environment (CDE) obejmuje ludzi, procesy i technologie, które przechowują, przetwarzają lub przesyłają Cardholder Data lub Sensitive Authentication Data.
CDE jest jednak punktem wyjścia do ustalenia zakresu, a nie jego pełnym synonimem.
Poza samym CDE w zakresie PCI DSS mogą znajdować się również systemy połączone z CDE lub takie, które mogą wpływać na jego bezpieczeństwo. PCI SSC opisuje zasady określania zakresu również w materiale pomocniczym dotyczącym zakresu i segmentacji. Dokument ten pomaga wyjaśnić zasady architektoniczne i sposób myślenia o zakresie, ale nie zastępuje aktualnych wymagań PCI DSS v4.0.1 ani bieżących wytycznych PCI SSC.
Przykładowo serwer przechowujący PAN należy bezpośrednio do CDE. System zarządzania tożsamością może natomiast sam nie przechowywać danych kartowych, ale nadal znajdować się w zakresie PCI, jeżeli kontroluje dostęp administratorów do systemów CDE.
Podobnie system do dystrybucji poprawek, centralny serwer logów, firewall zapewniający segmentację albo jump host administracyjny mogą pozostawać w zakresie ze względu na funkcję, którą pełnią.
Dlatego analiza PCI zwykle zaczyna się od mapowania przepływu danych. Firma musi rozumieć, gdzie dane kartowe pojawiają się po raz pierwszy, jak przepływają pomiędzy systemami, gdzie są przechowywane, kto ma do nich dostęp oraz którzy dostawcy uczestniczą w obsłudze płatności.
Błędne określenie zakresu prowadzi do dwóch przeciwnych problemów. Zbyt wąski zakres może pozostawić istotne systemy bez odpowiednich kontroli. Zbyt szeroki może sprawić, że firma będzie chronić i oceniać dziesiątki systemów, które przy lepszej architekturze mogłyby w ogóle nie znaleźć się w zakresie PCI.
PCI DSS v4.0.1 opiera się na 12 głównych wymaganiach pogrupowanych wokół sześciu celów bezpieczeństwa. Ich pełna treść i aktualne wytyczne znajdują się w oficjalnej bibliotece dokumentów PCI SSC.
Wymaganie 1: instalowanie i utrzymywanie mechanizmów kontroli bezpieczeństwa sieci.
Wymaganie 2: stosowanie bezpiecznych konfiguracji wszystkich komponentów systemowych.
Celem jest ograniczenie niepotrzebnej ekspozycji systemów i eliminowanie konfiguracji, które mogą niepotrzebnie zwiększać powierzchnię ataku.
Wymaganie 3: ochrona przechowywanych danych rachunków.
Wymaganie 4: ochrona danych posiadaczy kart za pomocą silnej kryptografii podczas transmisji przez otwarte, publiczne sieci.
Wymagania te regulują sposób ochrony danych podczas przechowywania oraz przesyłania.
Wymaganie 5: ochrona systemów i sieci przed złośliwym oprogramowaniem.
Wymaganie 6: rozwijanie i utrzymywanie bezpiecznych systemów i oprogramowania.
Dla organizacji technologicznych Wymaganie 6 jest szczególnie ważne, ponieważ łączy PCI DSS bezpośrednio z procesem developmentu, zarządzaniem zmianą, podatnościami oraz bezpieczeństwem aplikacji.
Wymaganie 7: ograniczenie dostępu do komponentów systemowych i danych posiadaczy kart zgodnie z rzeczywistą potrzebą biznesową.
Wymaganie 8: identyfikacja użytkowników i uwierzytelnianie dostępu do komponentów systemowych.
Wymaganie 9: ograniczenie fizycznego dostępu do danych posiadaczy kart.
Nie chodzi wyłącznie o to, czy dane są szyfrowane. Równie ważne jest to, kto może dostać się do systemu, w jaki sposób się uwierzytelnia i czy jego uprawnienia odpowiadają rzeczywistej roli.
Wymaganie 10: logowanie i monitorowanie dostępu do komponentów systemowych i danych posiadaczy kart.
Wymaganie 11: regularne testowanie bezpieczeństwa systemów i sieci.
PCI DSS zakłada więc nie tylko zapobieganie incydentom, ale również możliwość wykrywania nieprawidłowości, analizowania zdarzeń i regularnego sprawdzania, czy zabezpieczenia rzeczywiście działają.
Wymaganie 12: wspieranie bezpieczeństwa informacji poprzez polityki i programy organizacyjne.
Obejmuje ono między innymi odpowiedzialności, zarządzanie ryzykiem, nadzór nad dostawcami zewnętrznymi oraz działania potrzebne do utrzymywania bezpieczeństwa w całej organizacji.
Firma może próbować ograniczać koszty zgodności poprzez lepszą dokumentację, automatyzację kontroli czy sprawniejszy proces audytowy. Dużo większy efekt może jednak przynieść wcześniejsza decyzja architektoniczna, dzięki której wrażliwe dane kartowe nie trafią do części infrastruktury.
Jeżeli własny backend sklepu odbiera PAN, zapisuje go w bazie lub umożliwia jego odszyfrowanie, wiele elementów infrastruktury może znaleźć się w zakresie PCI.
Jeżeli natomiast klient przekazuje dane bezpośrednio do odpowiednio zwalidowanego dostawcy płatności, a system sprzedawcy otrzymuje jedynie token lub identyfikator transakcji, potencjalny zakres może być znacząco mniejszy. Nie oznacza to jednak, że każda integracja z PSP automatycznie redukuje zakres do minimum. Kluczowe znaczenie ma sposób jej implementacji.
Dlatego przy projektowaniu integracji z bramkami płatniczymi warto analizować nie tylko UX, dostępne metody płatności i conversion rate, ale również konsekwencje dla PCI DSS.
W e-commerce sposób implementacji checkoutu może w dużej mierze zdecydować o tym, jak szeroki będzie zakres PCI i jaka ścieżka walidacji będzie potencjalnie dostępna.
Poniższa tabela przedstawia uproszczone scenariusze. Nie jest substytutem formalnego ustalenia zakresu. Organizacja musi spełniać wszystkie kryteria kwalifikacyjne konkretnego SAQ, a właściwą ścieżkę walidacji należy potwierdzić z podmiotem przyjmującym wynik zgodności, na przykład agentem rozliczeniowym.
| Model checkoutu | Jak obsługiwane są dane karty? | Potencjalna ścieżka walidacji | Typowy wpływ na zakres |
|---|---|---|---|
| Pełny redirect do PSP | Klient opuszcza stronę sprzedawcy i wprowadza dane na stronie dostawcy płatności | Potencjalnie SAQ A, jeśli spełnione są wszystkie kryteria | Relatywnie ograniczony zakres |
| Iframe dostawcy płatności | Elementy zbierające dane karty są dostarczane przez zgodnego dostawcę w osadzonym iframe | Potencjalnie SAQ A, jeśli spełnione są wszystkie kryteria | Ograniczony, ale bezpieczeństwo strony sprzedawcy nadal ma znaczenie |
| Direct Post / strona płatnicza tworzona przez sprzedawcę | Strona sprzedawcy generuje część lub całość formularza, a dane są przesyłane z przeglądarki bezpośrednio do PSP | Potencjalnie SAQ A-EP | Szerszy niż w typowym SAQ A |
| Przetwarzanie danych kartowych we własnej infrastrukturze | Systemy sprzedawcy odbierają, przetwarzają lub przechowują dane kartowe | Szersza ocena PCI DSS, dokumentowana poprzez SAQ D lub ROC, zależnie od obowiązującej ścieżki walidacji | Znacznie szerszy |
PCI SSC wyraźnie rozróżnia Direct Post od iframe i redirectu. W przypadku Direct Post sprzedawca tworzy co najmniej część strony służącej do przyjmowania danych płatniczych. Przy poprawnie zaprojektowanym iframe lub redirectcie elementy przyjmujące dane karty pochodzą natomiast od zwalidowanego dostawcy. Różnicę tę PCI SSC opisuje w FAQ dotyczącym SAQ A i SAQ A-EP.
Jeżeli chcesz szerzej zrozumieć rolę samej bramki płatniczej, jej miejsce w przepływie transakcji opisujemy również w artykule co to jest bramka płatnicza i jak działa.
Wybór SAQ nie powinien zaczynać się od pytania „który formularz jest najkrótszy?”. Powinien zaczynać się od rzeczywistego modelu przepływu danych oraz spełnienia wszystkich kryteriów kwalifikacyjnych.
SAQ A jest przeznaczony dla określonych środowisk, w których funkcje związane z przyjmowaniem danych kartowych są odpowiednio outsourcowane do zgodnych z PCI DSS dostawców.
W e-commerce potencjalnymi przykładami są pełny redirect do strony PSP oraz właściwie zaimplementowany iframe dostawcy płatności.
Nie wystarczy jednak sam fakt używania iframe. PCI SSC wskazuje, że aby model mógł kwalifikować się do SAQ A, elementy strony płatniczej służące do przyjmowania danych kartowych muszą pochodzić bezpośrednio od zgodnego dostawcy. Jeżeli w zbieraniu danych uczestniczy element pochodzący od sprzedawcy, sytuacja może wyglądać inaczej.
SAQ A-EP może mieć zastosowanie do określonych środowisk e-commerce, w których dane kartowe nie są elektronicznie przechowywane, przetwarzane ani przesyłane przez systemy sprzedawcy, ale jego strona internetowa może wpływać na bezpieczeństwo procesu płatności.
Typowym przykładem wykorzystywanym przez PCI SSC jest Direct Post, gdzie sprzedawca generuje stronę przyjmującą dane, a przeglądarka przesyła informacje bezpośrednio do dostawcy płatności.
Zakres kontroli jest wtedy większy niż w typowym środowisku kwalifikującym się do SAQ A, ponieważ kompromitacja strony sprzedawcy może bezpośrednio wpłynąć na sposób pozyskiwania danych płatniczych.
SAQ D jest najszerszym Self-Assessment Questionnaire. Może mieć zastosowanie do organizacji kwalifikujących się do samooceny, które nie spełniają kryteriów innych, bardziej wyspecjalizowanych SAQ.
ROC, czyli Report on Compliance, jest natomiast szczegółowym raportem dokumentującym formalną ocenę PCI DSS. Nie jest alternatywnym „typem architektury” wobec SAQ D.
Bardziej złożone środowisko może więc wymagać szerokiej oceny PCI DSS, ale sposób jej udokumentowania zależy od obowiązującej ścieżki walidacji. Dla jednej organizacji może to oznaczać SAQ D, podczas gdy dla innej wymagany będzie ROC.
Właściwy sposób walidacji wynika z architektury, roli organizacji oraz zasad programu compliance określonych przez właściwy podmiot przyjmujący potwierdzenie zgodności.
W obszarze SAQ A pojawiły się w ostatnich latach ważne doprecyzowania dotyczące bezpieczeństwa stron e-commerce.
PCI SSC wprowadziła kryterium kwalifikacyjne wymagające od określonych merchantów korzystających z SAQ A potwierdzenia, że ich strona nie jest podatna na ataki skryptowe mogące wpłynąć na środowisko płatnicze.
Kluczowy jest jednak szczegół: zgodnie z FAQ 1588 PCI SSC kryterium to dotyczy merchantów, których strona zawiera osadzoną stronę lub formularz płatniczy zewnętrznego dostawcy, na przykład iframe.
Nie stosuje się go w ten sam sposób do klasycznego scenariusza, w którym klient jest przekierowywany ze strony sprzedawcy do zewnętrznego PSP.
Nie oznacza to jednak, że strona wykorzystująca redirect pozostaje poza wymaganiami bezpieczeństwa.
W opublikowanym w 2026 roku FAQ dotyczącym skanów ASV w SAQ A PCI SSC potwierdziła, że wymagania dotyczące zewnętrznych skanów podatności przez Approved Scanning Vendor obejmują odpowiednie strony e-commerce zarówno w przypadku redirectów, jak i osadzonych iframe.
Outsourcing samego przyjmowania danych kartowych może więc znacząco ograniczyć zakres PCI, ale nie powoduje, że bezpieczeństwo strony sprzedawcy przestaje mieć znaczenie.
Nie.
Outsourcing płatności może radykalnie ograniczyć zakres techniczny, ale nie usuwa odpowiedzialności firmy za prawidłowe zarządzanie modelem płatniczym i dostawcami.
PCI SSC wskazuje wprost, że merchant korzystający z zewnętrznego dostawcy nadal odpowiada między innymi za sprawdzenie jego statusu zgodności, określenie współdzielonych obowiązków oraz zarządzanie relacją z dostawcą.
Przykładowo sklep może przekierować klienta do zgodnego z PCI DSS PSP i dzięki temu nie przyjmować PAN we własnym środowisku. Nadal musi jednak wiedzieć, czy dany dostawca ma potwierdzoną zgodność z PCI DSS w zakresie usług rzeczywiście świadczonych na rzecz sprzedawcy, monitorować jego status oraz realizować obowiązki pozostające po swojej stronie.
Największym błędem jest więc założenie: „nasz PSP jest zgodny z PCI, więc PCI już nas nie dotyczy”.
Self-Assessment Questionnaire to zestaw formularzy służących określonym kwalifikującym się organizacjom do samooceny i raportowania zgodności z PCI DSS.
Istnieje kilka typów SAQ odpowiadających różnym środowiskom płatniczym. Firma musi spełniać wszystkie kryteria konkretnego formularza. Nie można wybrać SAQ wyłącznie dlatego, że wymaga odpowiedzi na mniejszą liczbę pytań.
Report on Compliance to szczegółowy raport dokumentujący formalną ocenę PCI DSS. Może być wymagany przez określony program zgodności w zależności od charakteru organizacji, skali i innych kryteriów.
Qualified Security Assessor to kwalifikowany assessor działający w ramach programu PCI SSC. W określonych przypadkach formalna ocena PCI DSS jest wykonywana przez uprawniony podmiot QSA.
Attestation of Compliance to formalne potwierdzenie wyniku oceny lub samooceny PCI DSS.
To, jaka ścieżka walidacji jest wymagana od konkretnej organizacji, zależy od zasad podmiotu przyjmującego potwierdzenie zgodności, na przykład agenta rozliczeniowego lub organizacji kartowej.
Jedną z najbardziej efektywnych strategii ograniczania ryzyka PCI jest minimalizowanie liczby systemów, które mają dostęp do rzeczywistych danych kartowych.
Tokenizacja może pomóc ograniczyć zakres PCI DSS, jeżeli jej implementacja rzeczywiście eliminuje dostęp określonych systemów do PAN i nie pozwala im wpływać na bezpieczeństwo danych rachunków płatniczych lub środowiska, w którym są one przetwarzane.
Samo zastąpienie PAN tokenem nie gwarantuje automatycznie wyłączenia systemu z zakresu.
Znaczenie ma między innymi charakter samego tokenu, sposób jego tworzenia i wykorzystania, lokalizacja mapowania token-PAN, możliwość detokenizacji, dostęp systemów do usługi tokenizacyjnej oraz inne połączenia i funkcje, które mogą pozwalać systemowi wpływać na bezpieczeństwo danych rachunków płatniczych.
PCI SSC opublikowała również materiał pomocniczy dotyczący tokenizacji, który wyjaśnia część zasad architektonicznych związanych z tokenami, systemami tokenizacyjnymi i detokenizacją. Dokument ten pochodzi sprzed PCI DSS 4.x i nie zastępuje aktualnych wymagań PCI DSS v4.0.1. Może być jednak pomocny przy zrozumieniu podstawowych zależności architektonicznych.
Szyfrowanie jest podstawowym mechanizmem ochrony danych, ale samo w sobie nie powoduje automatycznie wyłączenia środowiska z PCI DSS.
PCI SSC potwierdziła tę zasadę ponownie w marcu 2026 roku w FAQ dotyczącym zaszyfrowanych danych posiadaczy kart.
Jeżeli system przechowuje zaszyfrowany PAN i organizacja kontroluje możliwość odszyfrowania danych lub odpowiednie klucze, środowisko może nadal pozostawać w zakresie PCI.
Zweryfikowane rozwiązania Point-to-Point Encryption mogą w określonych środowiskach znacząco ograniczać ekspozycję danych i zakres obowiązków po stronie merchanta.
Kluczowe jest jednak rozróżnienie pomiędzy dowolnym rozwiązaniem wykorzystującym szyfrowanie a rozwiązaniem spełniającym odpowiednie wymagania programu PCI P2PE.
Porównajmy dwie hipotetyczne firmy e-commerce.
Sklep przekierowuje klienta na stronę płatniczą PSP. Dane karty są wprowadzane w środowisku dostawcy. Backend sklepu otrzymuje informację o transakcji, ale nie otrzymuje PAN.
Przy odpowiedniej implementacji i spełnieniu pozostałych kryteriów firma może potencjalnie kwalifikować się do SAQ A. Nadal pozostają po jej stronie określone obowiązki dotyczące własnego środowiska i dostawców, ale liczba systemów bezpośrednio związanych z danymi kartowymi może być stosunkowo niewielka.
Sklep posiada własny formularz. PAN trafia do infrastruktury firmy, jest obsługiwany przez aplikację, przekazywany pomiędzy komponentami i potencjalnie przechowywany.
W takim modelu do zakresu mogą wejść między innymi frontend, backend, sieci, bazy danych, infrastruktura administracyjna, logowanie, systemy bezpieczeństwa, konta uprzywilejowane oraz komponenty wspierające te elementy.
| Obszar | Hosted checkout | Przetwarzanie danych kartowych we własnej infrastrukturze |
|---|---|---|
| Dane PAN w systemach sprzedawcy | Zwykle nie | Tak lub potencjalnie tak |
| Liczba systemów potencjalnie w zakresie | Relatywnie mniejsza | Znacznie większa |
| Złożoność kontroli bezpieczeństwa | Mniejsza | Większa |
| Znaczenie zarządzania dostawcami | Bardzo wysokie | Wysokie |
| Potencjalna ścieżka walidacji | Możliwy SAQ A | Szersza ocena PCI DSS, dokumentowana poprzez SAQ D lub ROC, zależnie od obowiązującej ścieżki walidacji |
| Kontrola nad własnym procesem | Mniejsza | Większa |
| Koszt zapewnienia i utrzymania zgodności z PCI DSS | Zwykle niższy | Potencjalnie znacznie wyższy |
Dla klienta oba procesy mogą wyglądać podobnie. Z perspektywy bezpieczeństwa, odpowiedzialności, kosztów i przygotowania do PCI DSS są to jednak dwa bardzo różne modele.
Nie istnieje jedna wiarygodna odpowiedź na pytanie „ile kosztuje zgodność z PCI DSS?”. Koszt zależy przede wszystkim od zakresu i złożoności środowiska.
Najważniejsze czynniki kosztotwórcze to między innymi:
Firma może zaoszczędzić na implementacji własnego komponentu płatniczego, a następnie przez lata ponosić wyższe koszty kontroli bezpieczeństwa, testów, dokumentacji i walidacji.
Z drugiej strony outsourcing większej części procesu do odpowiedniego dostawcy może zwiększyć koszty transakcyjne lub ograniczyć elastyczność produktu, ale jednocześnie zmniejszyć liczbę systemów i procesów wymagających objęcia kontrolami PCI DSS.
Dlatego koszt zapewnienia i utrzymania zgodności z PCI DSS powinien być częścią analizy TCO architektury płatniczej, a nie osobnym wydatkiem analizowanym dopiero po zakończeniu developmentu.
Dobre przygotowanie nie zaczyna się od pobrania SAQ. Zaczyna się od zrozumienia środowiska.
Należy sprawdzić nie tylko system płatności, ale również logi, bazy danych, narzędzia analityczne, systemy obsługi klienta, wiadomości e-mail, zgłoszenia supportowe i procesy operacyjne.
Trzeba ustalić, w którym miejscu dane trafiają do środowiska, przez jakie systemy przechodzą, gdzie są przechowywane i komu są przekazywane.
Nie należy kończyć analizy na komponentach przechowujących PAN. Trzeba również uwzględnić systemy połączone z CDE, wpływające na jego bezpieczeństwo i dostarczające kluczowe mechanizmy ochronne.
Firma powinna sprawdzić, które obowiązki realizuje PSP, dostawca hostingu, dostawca usług security, platforma e-commerce czy inni partnerzy oraz jakie dowody zgodności mogą przedstawić.
Dopiero po zrozumieniu środowiska można określić, czy organizacja potencjalnie kwalifikuje się do SAQ A, SAQ A-EP, SAQ D lub innej ścieżki oraz czy wymagane będzie przygotowanie ROC.
Następny krok to porównanie istniejących mechanizmów z wymaganiami PCI DSS mającymi zastosowanie do danego środowiska.
Luki należy przełożyć na konkretne działania dotyczące infrastruktury, konfiguracji, dostępu, developmentu, polityk, monitoringu, zarządzania dostawcami i dokumentacji.
Jednym z częstych problemów nie jest brak kontroli, lecz brak możliwości udowodnienia, że kontrola rzeczywiście działała przez wymagany okres. Zbieranie dowodów powinno więc zostać uwzględnione w procesach operacyjnych, a nie pozostawione na tydzień przed oceną.
Przed właściwą oceną warto przeprowadzić wewnętrzny przegląd gotowości i upewnić się, że architektura, dokumentacja oraz dowody tworzą spójną całość.
W z3x pomagamy firmom określić zakres PCI DSS, analizować architekturę płatności, przeprowadzać gap analysis, przygotowywać działania naprawcze i organizować przygotowanie do walidacji. Jeżeli wymagane jest formalne potwierdzenie przez QSA, możemy wspierać przygotowanie organizacji i koordynację procesu z właściwym kwalifikowanym assessorem. Więcej informacji znajduje się na stronie naszej usługi doradztwa i przygotowania do zgodności z PCI DSS.
PCI DSS bywa traktowane jako odpowiedzialność działu security albo compliance. W firmach FinTech, SaaS i e-commerce taki podział jest zbyt wąski, ponieważ decyzje zespołów product i engineering bezpośrednio wpływają na późniejsze obowiązki związane z PCI DSS.
Przykładowo przechowywanie PAN we własnej infrastrukturze tworzy inne wymagania niż wykorzystywanie tokenizacji dostawcy. Podobnie własna strona zbierająca dane karty może prowadzić do innego zakresu i ścieżki walidacji niż w pełni hostowany checkout.
Znaczenie ma również sposób budowy narzędzi wewnętrznych. Jeżeli pracownicy obsługi klienta mogą zobaczyć pełny PAN, więcej systemów, stanowisk i procesów może znaleźć się w zakresie. Jeżeli dane są maskowane, a użytkownicy pracują wyłącznie na tokenach lub końcowych cyfrach numeru karty, sytuacja może wyglądać inaczej.
Podobnie jest z logami. Aplikacja może działać zgodnie z założonym modelem płatności, a jednocześnie przypadkowo zapisywać dane kartowe w logach debugowych. Taki błąd może rozszerzyć zakres o systemy, które pierwotnie nie miały przetwarzać danych kartowych.
W bardziej złożonych środowiskach warto więc połączyć analizę PCI DSS z szerszym doradztwem w płatnościach, obejmującym architekturę, dostawców, procesy płatnicze i model operacyjny.
PCI DSS jest globalnym standardem branżowym, a nie rozporządzeniem Unii Europejskiej ani prawem Wielkiej Brytanii.
Nie należy więc utożsamiać PCI DSS ze zgodnością z GDPR, UK GDPR, PSD2 ani innymi przepisami regulującymi bezpieczeństwo lub płatności.
Obowiązki te mogą się jednak częściowo pokrywać na poziomie praktycznych mechanizmów bezpieczeństwa. Kontrola dostępu, zarządzanie tożsamością, logowanie, reagowanie na incydenty, ochrona danych, zarządzanie dostawcami czy zarządzanie podatnościami mogą wspierać jednocześnie kilka różnych obowiązków.
Nie oznacza to jednak, że jeden framework zastępuje drugi. Firma może spełniać wymagania PCI DSS i jednocześnie naruszać obowiązki dotyczące ochrony danych osobowych. Regulowana instytucja płatnicza może spełniać określone wymagania regulacyjne, ale nadal posiadać luki z perspektywy PCI DSS.
Dla firm działających w kilku reżimach praktycznym podejściem jest więc budowanie wspólnej architektury bezpieczeństwa i kontroli, a następnie mapowanie poszczególnych wymagań do odpowiednich standardów i przepisów.
Zgodność nie powstaje raz w roku podczas wypełniania SAQ. Systemy, pracownicy, dostawcy i aplikacje zmieniają się stale. Kontrole bezpieczeństwa również muszą działać stale.
Dostawca może być zgodny z PCI DSS w zakresie swoich usług, ale sprzedawca nadal ma własne obowiązki związane z architekturą, stroną internetową, zarządzaniem dostawcami i walidacją.
Firmy często patrzą wyłącznie na system, w którym fizycznie znajduje się PAN. Tymczasem zakres może obejmować również systemy administracyjne, bezpieczeństwa, uwierzytelniania czy segmentacji.
Numery kart mogą pojawić się w logach, zgłoszeniach do działu obsługi klienta, zrzutach ekranów, narzędziach analitycznych albo ręcznie tworzonych bazach danych. W każdym takim przypadku firma może nieświadomie rozszerzyć własny zakres PCI.
Organizacja nie wybiera SAQ według wygody. Musi spełniać wszystkie kryteria kwalifikacyjne danego formularza.
Pomyślne zakończenie oceny oznacza, że w określonym zakresie organizacja wykazała spełnienie odpowiednich wymagań. Nie oznacza, że atak stał się niemożliwy.
Dobre bezpieczeństwo wymaga ciągłego monitorowania, odpowiedzialnego developmentu, zarządzania podatnościami, reagowania na incydenty i podejmowania decyzji wykraczających poza samą walidację PCI.
PCI compliance zazwyczaj oznacza zgodność z odpowiednimi wymaganiami Payment Card Industry Data Security Standard, czyli PCI DSS. Standard służy ochronie danych dotyczących rachunków płatniczych i ma zastosowanie do podmiotów przechowujących, przetwarzających lub przesyłających dane kartowe, a także do określonych organizacji mogących wpływać na bezpieczeństwo Cardholder Data Environment.
PCI oznacza Payment Card Industry. PCI DSS oznacza Payment Card Industry Data Security Standard.
PCI DSS jest branżowym standardem bezpieczeństwa, a nie ogólną ustawą czy rozporządzeniem państwowym. W praktyce sprzedawcy i dostawcy usług są zobowiązywani do jego spełniania w ramach relacji z organizacjami kartowymi, agentami rozliczeniowymi i innymi uczestnikami ekosystemu płatności.
Szczegółowe wymagania dotyczące sposobu walidacji i raportowania określa właściwy program compliance.
PCI DSS jest przeznaczony dla podmiotów uczestniczących w obsłudze danych kartowych, w tym sprzedawców akceptujących płatności kartowe. Sposób walidacji oraz zakres wymagań mogą jednak bardzo istotnie różnić się zależnie od modelu płatności i architektury.
PCI DSS v4.0.1 jest aktualną wersją PCI Data Security Standard według stanu na 2026 rok. Została opublikowana jako ograniczona rewizja PCI DSS v4.0. Wersja 4.0 została wycofana 31 grudnia 2024 roku, a odroczone wymagania PCI DSS v4.x zaczęły obowiązywać 31 marca 2025 roku.
Self-Assessment Questionnaire to narzędzie walidacyjne PCI DSS dostępne dla organizacji spełniających odpowiednie kryteria. Istnieje kilka różnych SAQ odpowiadających różnym środowiskom płatniczym.
W dużym uproszczeniu SAQ A może mieć zastosowanie do określonych środowisk, w których elementy przyjmujące dane kartowe są odpowiednio outsourcowane do zgodnego dostawcy, na przykład poprzez redirect lub właściwie zaimplementowany iframe.
SAQ A-EP obejmuje określone środowiska e-commerce, w których sprzedawca nie przechowuje elektronicznie danych kartowych, ale jego strona uczestniczy w tworzeniu strony płatniczej i może wpływać na bezpieczeństwo procesu, jak w niektórych implementacjach Direct Post.
W każdym przypadku trzeba spełnić pełne kryteria kwalifikacyjne właściwego SAQ.
SAQ D jest kwestionariuszem samooceny dla kwalifikujących się organizacji. ROC jest natomiast szczegółowym raportem dokumentującym formalną ocenę PCI DSS. To, czy dana organizacja dokumentuje szeroką ocenę za pomocą SAQ D czy ROC, zależy od obowiązującej ją ścieżki walidacji.
Nie. Korzystanie ze zgodnego z PCI DSS PSP może bardzo istotnie zmniejszyć zakres, ale nie eliminuje wszystkich obowiązków sprzedawcy. Firma nadal musi rozumieć własne środowisko, zarządzać dostawcami i realizować właściwą ścieżkę walidacji.
Nie. Może znacznie ograniczyć techniczny zakres, ale sprzedawca nadal ma obowiązki. W aktualnym SAQ A istnieją między innymi wymagania dotyczące określonych mechanizmów bezpieczeństwa strony e-commerce, a PCI SSC potwierdziła w 2026 roku stosowanie odpowiednich skanów ASV również do stron wykorzystujących redirect.
Potencjalnie tak, jeżeli spełnione są wszystkie kryteria SAQ A, w tym odpowiednie wymagania dotyczące pochodzenia elementów strony płatniczej. Dla osadzonych formularzy obowiązuje również kryterium związane z ochroną strony przed atakami skryptowymi.
Może go znacząco ograniczyć, ale zależy to od konkretnej implementacji. Znaczenie ma nie tylko to, czy system przechowuje token zamiast PAN, ale również charakter tokenu, możliwość jego zamiany na PAN, dostęp do systemu tokenizacyjnego oraz inne połączenia lub funkcje mogące wpływać na bezpieczeństwo danych rachunków płatniczych.
Nie można więc przyjąć, że każdy system korzystający wyłącznie z tokenów automatycznie znajduje się poza zakresem PCI DSS. Ostateczne określenie zakresu wymaga analizy konkretnej architektury i sposobu wykorzystania tokenu.
Nie. Szyfrowanie jest bardzo ważnym mechanizmem ochronnym, ale w środowisku sprzedawcy samo zaszyfrowanie danych nie oznacza automatycznie, że przestają one podlegać PCI DSS.
Nie. PCI DSS wpływa również na product, engineering, operations, procurement, obsługę klienta, finanse i zarządzanie dostawcami. Decyzja produktowa dotycząca sposobu przyjmowania kart może zmienić zakres obowiązków całej organizacji.
Jednym z najskuteczniejszych sposobów jest ograniczenie zakresu już na poziomie architektury. Outsourcing odpowiednich elementów do zwalidowanych dostawców, właściwie zaprojektowana tokenizacja, segmentacja, ograniczenie liczby osób posiadających dostęp oraz unikanie niepotrzebnego przechowywania danych mogą zmniejszyć liczbę systemów podlegających wymaganiom.
PCI compliance nie powinno być traktowane wyłącznie jako coroczny proces wypełniania formularzy lub przygotowania do audytu. W praktyce jest konsekwencją sposobu, w jaki firma zaprojektowała swoją infrastrukturę płatniczą, przepływ danych, integracje i procesy operacyjne.
Najważniejszym etapem jest prawidłowe określenie zakresu. Firma musi wiedzieć nie tylko, gdzie znajduje się PAN, ale również które systemy są połączone z CDE, które mogą wpływać na jego bezpieczeństwo i jakie obowiązki realizują dostawcy zewnętrzni.
W e-commerce szczególne znaczenie ma wybór modelu checkoutu. Redirect, iframe, Direct Post i przetwarzanie danych kartowych we własnej infrastrukturze mogą wyglądać dla klienta podobnie, ale prowadzić do bardzo różnych konsekwencji z perspektywy zakresu, ścieżki walidacji, kontroli bezpieczeństwa i kosztów.
Tokenizacja, szyfrowanie i outsourcing mogą znacząco ograniczyć ekspozycję na dane kartowe, ale żadnego z tych mechanizmów nie należy traktować jako automatycznego sposobu na wyłączenie systemów z zakresu PCI DSS. Liczy się konkretna implementacja i faktyczna możliwość wpływania na bezpieczeństwo danych rachunków płatniczych.
Najtańszy sposób na zgodność z PCI DSS? Nie budować architektury, która niepotrzebnie zwiększa jej koszt.
W z3x pomagamy firmom zrozumieć ich zakres PCI DSS, analizować architekturę płatności, identyfikować luki, ograniczać niepotrzebną złożoność i przygotowywać organizację do właściwej ścieżki walidacji. Nie zastępujemy formalnej oceny wykonywanej przez QSA tam, gdzie jest ona wymagana. Pomagamy natomiast sprawić, aby firma, jej infrastruktura i dokumentacja były do takiej oceny dobrze przygotowane.
Więcej informacji o takim wsparciu znajdziesz w naszej ofercie doradztwa i przygotowania do zgodności z PCI DSS.
Karol Zielinski
Karol Zielinski
Karol Zielinski
