PCI DSS 4.0: wymagania dla firm przyjmujących płatności kartą

Czym jest PCI DSS i kto go egzekwuje

Payment Card Industry Data Security Standard rozwija PCI Security Standards Council, organizacja założona przez główne marki kartowe. Standard określa wymagania techniczne i organizacyjne dla ochrony danych posiadacza karty (numer karty, imię i nazwisko, data ważności) oraz wrażliwych danych uwierzytelniających (pełne dane z paska magnetycznego lub chipu, kod CVV2, PIN).

Rada PCI SSC nie nakłada kar i nie decyduje, kto musi przejść jaką ocenę. Robią to marki kartowe i agenci rozliczeniowi w umowach z akceptantami. W praktyce wymóg trafia do firmy przez umowę z agentem rozliczeniowym lub dostawcą bramki płatniczej, który co roku prosi o potwierdzenie zgodności.

Aktualną wersją jest PCI DSS v4.0.1, opublikowana w czerwcu 2024 r. Wprowadziła ona poprawki redakcyjne i doprecyzowania do wersji 4.0, bez nowych wymagań. Wersja 3.2.1 została wycofana 31 marca 2024 r., a wersja 4.0 pod koniec 2024 r.

12 wymagań w sześciu celach

Struktura standardu jest stała od lat: sześć celów i dwanaście głównych wymagań, każde z wieloma wymaganiami szczegółowymi. Wersja 4.0 zmieniła sformułowania, aby lepiej opisywały cel, a nie konkretną technologię.

• 1. Instalacja i utrzymanie mechanizmów kontroli bezpieczeństwa sieci
• 2. Stosowanie bezpiecznych konfiguracji wszystkich komponentów systemu
• 3. Ochrona przechowywanych danych konta
• 4. Ochrona danych posiadacza karty silną kryptografią podczas transmisji przez otwarte, publiczne sieci
• 5. Ochrona wszystkich systemów i sieci przed złośliwym oprogramowaniem
• 6. Tworzenie i utrzymywanie bezpiecznych systemów i oprogramowania
• 7. Ograniczenie dostępu do komponentów systemu i danych do zasady niezbędnej wiedzy
• 8. Identyfikacja użytkowników i uwierzytelnianie dostępu
• 9. Ograniczenie fizycznego dostępu do danych posiadacza karty
• 10. Rejestrowanie i monitorowanie dostępu do komponentów systemu i danych
• 11. Regularne testowanie bezpieczeństwa systemów i sieci
• 12. Wspieranie bezpieczeństwa informacji politykami i programami organizacyjnymi

Co zmieniło się 31 marca 2025 r.

Wersja 4.0 zawierała kilkadziesiąt nowych wymagań oznaczonych jako przyszłe, które były tylko dobrą praktyką do 31 marca 2025 r. Od tej daty są obowiązkowe w każdej ocenie zgodności. Wiele firm, które przeszły ocenę w 2024 r. bez problemów, odkryło luki dopiero przy kolejnej rocznej ocenie.

Najbardziej odczuwalne zmiany dotyczą uwierzytelniania wieloskładnikowego, stron płatności w e-commerce oraz formalnego zarządzania ryzykiem. Wersja 4.0 wprowadziła też podejście dostosowane (customized approach), w którym firma może spełnić cel wymagania inną metodą niż opisana, pod warunkiem udokumentowania analizy ryzyka i zatwierdzenia przez asesora.

• MFA dla wszystkich dostępów do środowiska danych posiadacza karty, nie tylko administracyjnych (8.4.2)
• Minimum 12 znaków w hasłach, o ile system to obsługuje (8.3.6)
• Inwentarz i autoryzacja skryptów na stronach płatności oraz wykrywanie nieautoryzowanych zmian (6.4.3, 11.6.1)
• Ukierunkowane analizy ryzyka uzasadniające częstotliwość wybranych czynności (12.3.1)
• Mechanizmy ochrony przed phishingiem (5.4.1)
• Zautomatyzowany przegląd logów (10.4.1.1)
• Coroczne potwierdzenie zakresu oceny przez akceptanta (12.5.2)

Poziomy akceptantów i sposób potwierdzania zgodności

Poziom akceptanta zależy od rocznej liczby transakcji i jest ustalany przez marki kartowe, z możliwością podwyższenia przez agenta rozliczeniowego, na przykład po incydencie. Progi różnią się między markami, dlatego zawsze sprawdź, co mówi Twoja umowa i agent rozliczeniowy.

Akceptanci najwyższego poziomu zwykle muszą przejść coroczny audyt zakończony raportem ROC (Report on Compliance), przygotowanym przez kwalifikowanego asesora QSA albo, za zgodą agenta, przez wewnętrznego asesora ISA. Mniejsze firmy najczęściej wypełniają kwestionariusz samooceny SAQ i podpisują deklarację AOC (Attestation of Compliance). Systemy dostępne z internetu wymagają też kwartalnych skanów zewnętrznych wykonywanych przez zatwierdzonego dostawcę ASV (11.3.2).

Jak wybrać właściwy typ SAQ

Typ kwestionariusza zależy od sposobu przyjmowania płatności. To najważniejsza decyzja, bo wyznacza liczbę wymagań do spełnienia: od kilkudziesięciu w SAQ A do pełnego zestawu w SAQ D. Błędne dopasowanie SAQ jest jednym z najczęstszych problemów wychodzących przy incydencie.

Dla e-commerce różnica między SAQ A a SAQ A-EP sprowadza się do tego, kto kontroluje stronę, na której klient wpisuje dane karty. Przekierowanie lub osadzony formularz w iframe dostawcy zgodnego z PCI DSS zwykle oznacza SAQ A. Jeśli strona sklepu wpływa na to, jak dane karty są przekazywane, na przykład przez własny JavaScript, zwykle mówimy o SAQ A-EP. Wymagania i kryteria kwalifikacji do SAQ A były w 2025 r. aktualizowane, dlatego pobierz aktualną wersję dokumentu z biblioteki PCI SSC.

• SAQ A: e-commerce lub MOTO w pełni zlecone na zewnątrz, firma nie przechowuje danych kart
• SAQ A-EP: e-commerce, gdzie strona firmy może wpływać na bezpieczeństwo transakcji
• SAQ B i B-IP: samodzielne terminale wdzwaniane lub IP bez elektronicznego przechowywania danych
• SAQ C-VT: ręczne wprowadzanie transakcji w wirtualnym terminalu przez przeglądarkę
• SAQ C: systemy płatności połączone z internetem bez przechowywania danych
• SAQ P2PE: wyłącznie terminale w zatwierdzonym rozwiązaniu P2PE
• SAQ D: wszystkie pozostałe przypadki, a także dostawcy usług

Najczęstsze luki w małych i średnich firmach

Wiele firm sądzi, że skoro korzysta z zewnętrznej bramki płatniczej, PCI DSS ich nie dotyczy. Zlecenie przetwarzania zmniejsza zakres, ale go nie eliminuje: akceptant nadal odpowiada za swoją stronę, za relacje z dostawcami (12.8) i za to, czy dane kart nie trafiają do miejsc, których nikt nie kontroluje.

Drugi typowy problem to zakres. Sieć płaska, w której terminal płatniczy, komputer księgowej i serwer plików są w tym samym segmencie, rozszerza środowisko danych kartowych na całą firmę. Segmentacja sieci nie jest formalnie obowiązkowa, ale bez niej zakres oceny i koszt zgodności rosną.

• Numery kart zapisane w e-mailach, arkuszach lub nagraniach rozmów telefonicznych
• Brak aktualnej listy dostawców usług z podziałem odpowiedzialności za wymagania
• Wspólne konta administracyjne bez MFA
• Zewnętrzne skrypty marketingowe na stronie płatności bez inwentarza i autoryzacji
• Brak skanów ASV po zmianach na serwerach widocznych z internetu
• Polityka bezpieczeństwa niezaktualizowana od lat i nieznana pracownikom

Jak się przygotować do kolejnej oceny

Zacznij od mapy przepływu danych kartowych: skąd dane przychodzą, przez jakie systemy przechodzą, gdzie mogą być zapisane i kto ma do nich dostęp. To podstawa do ustalenia zakresu i typu SAQ. Następnie usuń wszystko, czego nie musisz przechowywać. Wrażliwych danych uwierzytelniających, takich jak CVV2, nie wolno przechowywać po autoryzacji.

Wyznacz też właściciela tematu po stronie firmy. Wymaganie 12.4.1 oczekuje, że kierownictwo wykonawcze ustali odpowiedzialność za ochronę danych posiadaczy kart i program zgodności z PCI DSS. W małej firmie może to być dyrektor operacyjny lub szef IT, ale powinno to wynikać z dokumentu, a nie z domysłów. Taka osoba pilnuje kalendarza: kwartalnych skanów, corocznego testu penetracyjnego, przeglądu dostawców i terminu złożenia AOC u agenta rozliczeniowego.

Kolejny krok to zebranie dowodów: zrzuty konfiguracji, raporty ze skanów ASV, potwierdzenia zgodności od dostawców usług (ich AOC), listy dostępów, zapisy ze szkoleń i wyniki testów. Asesor lub agent rozliczeniowy oczekuje dowodów, a nie deklaracji. PCI DSS nie ma odpowiednika w katalogu norm ISO na baltum.ai, ale ogólna bezpłatna samoocena pomaga sprawdzić dojrzałość bezpieczeństwa informacji, na której opiera się zgodność z PCI DSS.

Artykuł ma charakter informacyjny i nie stanowi porady prawnej. baltum.ai to niezależne oprogramowanie, a nie jednostka certyfikująca.