PCI DSS

Z PCI DSS firmy spotykają się zwykle wtedy, gdy acquirer, operator płatności lub klient prosi o dowód, że dane kart są chronione. Standard pisze PCI Security Standards Council, który założyły i do którego należą główne organizacje płatnicze (marki kart). Strony rady opisują standard i programy zgodności prowadzone przez organizacje płatnicze. Nie opisują przepisu prawa.

Praktyczna różnica dotyczy tego, kto decyduje. Rada pisze standard i formularze. Organizacje płatnicze i Twój acquirer (bank lub agent rozliczeniowy, który obsługuje Twoje płatności kartami) decydują, czy musisz przejść walidację, w jakiej formie i co im wysyłasz. Pierwsze pytanie brzmi więc: o co prosił mnie acquirer.

Rada pisze, że standard jest przeznaczony dla wszystkich podmiotów, które przechowują, przetwarzają lub przesyłają dane posiadacza karty albo wrażliwe dane uwierzytelniające, lub mogą wpłynąć na bezpieczeństwo środowiska danych posiadacza karty. Dane posiadacza karty to numer karty, imię i nazwisko posiadacza, data ważności i kod usługi. Wrażliwe dane uwierzytelniające to pełne dane ze ścieżki, kod weryfikacyjny karty i numery PIN. Razem tworzą dane konta.

Zasięg jest szerszy niż sklep, który przyjmuje płatność. W zakresie może być firma, która prowadzi stronę, hostuje serwer, przyjmuje zamówienia telefonicznie albo zarządza siecią stykającą się z systemami płatności. Dostawca usług, który obsługuje dane kart dla innych, podlega standardowi w zakresie tej usługi. To, czy musisz przejść walidację i na jakim poziomie, ustalają acquirer i organizacje płatnicze. Ta strona nie czytała ich zasad o poziomach i progach.

Biblioteka dokumentów rady wyróżnia 2 listopada 2026 wersję PCI DSS v4.0.1. Ogłoszono ją 11 czerwca 2024 jako ograniczoną rewizję wersji 4.0: poprawiono błędy i doprecyzowano część intencji, bez dodawania i usuwania wymagań. Rada wycofała wersję 4.0 w dniu 31 grudnia 2024, więc wspieraną wersją jest v4.0.1. Spośród 64 wymagań dodanych w v4.x 51 miało datę odroczoną, a rada podaje 31 marca 2025 jako dzień, w którym zaczęły obowiązywać. Ta data minęła, więc dzisiejsza ocena je obejmuje.

Zanim zaczniesz, sprawdź w bibliotece dokumentów, czy nie ma nowszej wersji, bo ta strona nie wie, co opublikowano po podanej dacie.

Rada grupuje dwanaście głównych wymagań w sześć celów. Poniżej są tytuły rady, a po nich to, co znaczą dla firmy bez zespołu bezpieczeństwa. Polskie sformułowania są opisem autora strony, bo oficjalnego polskiego tłumaczenia standardu nie czytano.

Zbuduj i utrzymuj bezpieczną sieć i systemy

1. Install and maintain network security controls. Ustal, co może rozmawiać z czym, i postaw między tym zapory lub ich odpowiedniki.
2. Apply secure configurations to all system components. Usuń ustawienia domyślne producenta i wyłącz to, czego nie używasz.

Chroń dane konta 3. Protect stored account data. Przechowuj jak najmniej i chroń to, co przechowujesz. 4. Protect cardholder data with strong cryptography during transmission over open, public networks. Szyfruj dane kart, gdy przechodzą przez internet.

Utrzymuj program zarządzania podatnościami 5. Protect all systems and networks from malicious software. 6. Develop and maintain secure systems and software. Instaluj poprawki oraz buduj lub kupuj oprogramowanie napisane w bezpieczny sposób.

Wdróż silne środki kontroli dostępu 7. Restrict access to system components and cardholder data by business need to know. Dostęp tylko wtedy, gdy wymaga go praca. 8. Identify users and authenticate access to system components. Każda osoba ma własne konto i silne uwierzytelnianie. 9. Restrict physical access to cardholder data.

Regularnie monitoruj i testuj sieci 10. Log and monitor all access to system components and cardholder data. 11. Test security of systems and networks regularly. Skanuj, testuj i sprawdzaj zmiany.

Utrzymuj politykę bezpieczeństwa informacji 12. Support information security with organizational policies and programs. Pisemna polityka, nazwani właściciele, szkolenia, reagowanie na incydenty i kontrola dostawców usług.

Każde wymaganie ma wiele podwymagań. Ta strona nie czytała pełnego tekstu standardu, więc szczegółów szukaj w aktualnym dokumencie i w formularzu wskazanym przez acquirera.

Są dwie drogi, a o wyborze decyduje acquirer lub organizacja płatnicza.

Kwestionariusz samooceny (SAQ). Rada publikuje kilka wersji dla różnych sposobów przyjmowania kart, na przykład dla strony, która odsyła klienta do operatora płatności, dla samodzielnego terminala albo dla akceptanta, który nie spełnia kryteriów krótszych formularzy. Rada radzi zapytać acquirera, organizacje płatnicze lub inny podmiot ds. zgodności, który formularz dotyczy Ciebie, a najdłuższy, SAQ D, jest dla akceptantów niespełniających kryteriów żadnego innego. Dostawcy usług, którzy kwalifikują się do samooceny, używają własnej wersji SAQ D.

Raport o zgodności (ROC). Oceniający testuje Twoje środowisko względem standardu i pisze raport. Formularze rady odnotowują, czy brał udział Qualified Security Assessor (QSA) albo wewnętrzny oceniający i co zrobił. Czy potrzebujesz takiego raportu, rozstrzygają organizacje płatnicze i acquirer.

Obie drogi kończą się oświadczeniem o zgodności (attestation of compliance, AOC), które podpisuje członek kierownictwa firmy. Oświadczenie mówi, czy ocena była pełna czy częściowa, i podaje jeden z trzech wyników: zgodny, niezgodny albo zgodny z wyjątkiem prawnym. Odpowiedź w kwestionariuszu jest jedną z sześciu: wdrożone; wdrożone ze środkiem kompensującym; wdrożone po naprawie; nie dotyczy; nie testowano; niewdrożone. Każde „nie testowano” czyni ocenę częściową. Formularz i inne wymagane dokumenty, na przykład raporty ze skanów podatności zewnętrznych, wysyłasz do podmiotu, który o nie poprosił.

Rada pisze, że oświadczenie jest przeznaczone do udostępniania podmiotom, które o nie proszą, na zasadach organizacji płatniczych.

W zakresie jest każdy system, który przechowuje, przetwarza lub przesyła dane kart, i każdy, który może na te systemy wpłynąć. Wytyczne rady o zakresie zaczynają od założenia, że wszystko jest w zakresie, dopóki nie zweryfikowano inaczej. Najtańszym zabezpieczeniem jest system, który wyprowadzisz poza zakres.

Trzy ruchy robią większość pracy. Przestań przechowywać dane kart, których nie potrzebujesz, bo wymagania dotyczące przechowywanych danych przestają Cię dotyczyć, gdy niczego nie trzymasz. Odeślij klientów na stronę płatności prowadzoną przez dostawcę usług, żeby dane kart nie trafiały na Twoje serwery. Oddziel systemy stykające się z danymi kart od reszty sieci, żeby reszta została poza zakresem. Rada opisuje segmentację jako sposób ograniczenia liczby systemów w zakresie, a jej wytyczne każą sprawdzić, że systemy pozostawione na zewnątrz nie mają dostępu do tych w środku.

Dwie przestrogi. Skorzystanie z dostawcy usług nie zdejmuje obowiązku: nadal zarządzasz tym dostawcą, a standard mówi to o każdym dostawcy z Twojej listy. Zakres trzeba też potwierdzać na nowo co najmniej raz w roku i przy zmianie środowiska.

Oświadczenie pokazuje, że podpisujący zadeklarowali w danym dniu, że ocenę wykonano zgodnie z instrukcją i że rzetelnie przedstawia wyniki. W raporcie oceniającego widać też, co oceniający przetestował. Oświadczenie pokazuje zakres, który opisałeś: kanały płatności, systemy i wymienionych dostawców usług. Ocena częściowa pokazuje tylko wymagania, które przetestowano.

Nie pokazuje, że Twoje systemy są dziś bezpieczne ani że były bezpieczne dzień po dacie na formularzu. Samoocena jest Twoim własnym opisem siebie, chyba że uczestniczył w niej oceniający. Nie obejmuje kanału płatności pominiętego w zakresie ani dostawcy, którego nie wymieniono. Nie dowodzi zgodności z RODO: dane karty dotyczące osoby są danymi osobowymi, a obowiązek RODO stosowania odpowiednich środków bezpieczeństwa istnieje samodzielnie. Wreszcie oświadczenie jest tyle warte, ile reguła acquirera, który o nie prosi.

Kolejność, która się sprawdza: najpierw zakres, potem budowa, na końcu dowód. Kroki opisuje plan wdrożenia. W skrócie:

1. Zapytaj. Weź od acquirera wymaganie na piśmie: który formularz, które kanały, jak często, kto podpisuje.
2. Zmapuj dane kart. Znajdź każde miejsce, w którym dane kart są przechowywane, przetwarzane lub wysyłane, także papier, nagrania rozmów i logi. To inwentarz zasobów z dodatkową kolumną o danych kart.
3. Zmniejsz. Wyprowadź z zakresu to, co się da, jak opisano wyżej.
4. Buduj wymaganie po wymaganiu. Sieć i konfiguracja (wymagania 1 i 2) z zarządzaniem stacjami roboczymi i urządzeniami; dane przechowywane i przesyłane (3 i 4) z kluczami szyfrującymi; złośliwe oprogramowanie, poprawki i oprogramowanie (5 i 6) z zarządzaniem podatnościami i bezpiecznym wytwarzaniem; dostęp (7 do 9) z dostępem uprzywilejowanym i MFA; logi i testy (10 i 11) z logowaniem i monitorowaniem; polityka, ludzie, incydenty i dostawcy (12) z zarządzaniem dostawcami i szkoleniami uświadamiającymi.
5. Udowodnij. Wypełnij formularz na podstawie dowodów, daj go do przeczytania osobie, która podpisuje, i wyślij.
6. Powtarzaj. Potwierdzaj zakres co roku i przy każdej zmianie przepływu płatności.

Sam standard to dokument rady, który trzeba pobrać. Ta strona przeczytała publiczne strony rady, FAQ, wpisy na blogu i jeden formularz kwestionariusza z oświadczeniem. Nie czytała pełnych wymagań i procedur testowych, przewodników dla oceniających i acquirerów, zasad samych organizacji płatniczych, poziomów walidacji ani żadnej umowy z acquirerem. Numery podwymagań podano tylko tam, gdzie pokazuje je strona rady. Nie dodano warstwy krajowej, bo nie czytano żadnego polskiego źródła o PCI DSS. Sprawdź aktualny standard i zapytaj acquirera, zanim wybierzesz drogę.