Checklist zgodności PCI DSS dla startupów fintech

Każdy założyciel fintechu prędzej czy później zadaje sobie pytanie: czy naprawdę musimy martwić się o PCI DSS, czy to problem kogoś innego, skoro korzystamy ze Stripe? Uczciwa odpowiedź leży pośrodku. Jeśli twoja aplikacja w jakikolwiek sposób dotyka danych karty, nawet przez bramkę zwalidowaną pod kątem PCI, PCI DSS cię dotyczy. Ignorowanie tego do momentu, aż zapyta o to partner bankowy, to prosta droga do gorączkowych poprawek na kilka tygodni przed startem. Ten przewodnik prowadzi przez praktyczną checklistę zgodności PCI DSS: kogo dotyczy, co oznacza 12 wymagań, jak działają typy SAQ i co zmieniło się w PCI DSS 4.0. Nic z tego nie zastąpi formalnej walidacji przeprowadzonej przez certyfikowanego audytora (Qualified Security Assessor, QSA), ale powinno dać ci więcej niż strona marketingowa dostawcy.

PCI DSS to skrót od Payment Card Industry Data Security Standard, czyli zbioru wymagań stworzonych do ochrony danych posiadaczy kart, utrzymywanych przez PCI Security Standards Council (założoną w 2006 roku przez Visa, Mastercard, American Express, Discover i JCB). To, co zaskakuje większość założycieli: PCI DSS wynika z umowy, a nie z przepisów prawa, i jest zapisane w umowach, które podpisujesz z bankiem, procesorem płatności lub bramką płatniczą. Jeśli go nie dopilnujesz, konsekwencją są kary finansowe nakładane przez organizacje kartowe, wyższe stawki za przetwarzanie transakcji, a w najgorszym razie utrata możliwości przyjmowania kart w ogóle. Standard obejmuje twoje środowisko danych posiadaczy kart, czyli CDE: ludzi, procesy i technologię, które przechowują, przetwarzają lub przesyłają dane posiadaczy kart, a także wszystko, co jest z nimi na tyle blisko powiązane, że może wpłynąć na ich bezpieczeństwo.

PCI DSS dotyczy każdej organizacji, która przechowuje, przetwarza lub przesyła dane posiadaczy kart, albo może wpłynąć na bezpieczeństwo środowiska danych posiadaczy kart. To celowo szeroko zakrojona definicja: obejmuje sprzedawców, procesorów płatności, bramki płatnicze i dostawców oprogramowania, których produkt w jakimkolwiek momencie dotyka danych karty. Wielkość firmy cię nie zwalnia: dwuosobowy startup przetwarzający swoje pierwsze sto transakcji przez Stripe wchodzi w zakres regulacji w momencie, gdy przez jego system przepłynie prawdziwy numer karty. Wielkość i wolumen wpływają na to, jak dowodzisz zgodności, o czym więcej za chwilę. Jeśli już analizujesz wymagania KYC i AML dla swojego MVP w fintechu, PCI DSS to równoległy tor dotyczący danych karty. Oba tematy zwykle pojawiają się w tej samej rozmowie z partnerem bankowym albo w szerszym planowaniu rozwoju oprogramowania fintech.

Sieci kartowe dzielą sprzedawców na cztery poziomy zgodności, głównie na podstawie rocznego wolumenu transakcji (progi nieznacznie różnią się w zależności od marki karty): Poziom 1 to ponad sześć milionów transakcji rocznie albo dowolny sprzedawca, który miał wcześniej wyciek danych, Poziom 2 to od jednego do sześciu milionów, Poziom 3 to od dwudziestu tysięcy do miliona transakcji e-commerce, Poziom 4 to wszystko poniżej tego progu. Niemal każdy startup zaczyna na Poziomie 4. To, co musisz zrobić, by udowodnić zgodność, zależy od twojego poziomu. Sprzedawcy z Poziomu 1 zwykle potrzebują corocznej oceny na miejscu przeprowadzanej przez certyfikowanego audytora (Qualified Security Assessor, QSA). Wszyscy pozostali zazwyczaj przeprowadzają samoocenę za pomocą kwestionariusza samooceny (Self-Assessment Questionnaire, SAQ): pytań typu tak/nie dopasowanych do wymagań pasujących do twojej konfiguracji. To, który SAQ wypełniasz, zależy od tego, jak dane karty do ciebie docierają, a nie od twojej branży czy liczby pracowników. Istnieje też kilka węższych typów (B, B-IP, C, P2PE), a poniższa tabela pokazuje te, z którymi styka się większość startupów.

Jeśli odrzucić prawniczy język, checklist zgodności PCI DSS sprowadza się do dwunastu wymagań ułożonych wokół sześciu celów. Nie wdrożysz osobiście wszystkich dwunastu; spora część leży po stronie twojej bramki płatniczej, dostawcy chmury albo partnera BaaS. Mimo to warto wiedzieć, czego dotyczy każde z nich. „Nasz dostawca się tym zajmuje” jest prawdą tylko do momentu, aż ktoś poprosi cię o dowód.

Najszybszy sposób na zmniejszenie zakresu PCI: nigdy nie pozwól, by surowe dane karty dotarły do twoich własnych serwerów. Hosted fields (iframe lub przekierowanie kontrolowane przez bramkę płatniczą) oraz tokenizacja robią dokładnie to. Numer karty klienta trafia bezpośrednio do bramki; twój backend widzi tylko token, bezużyteczny dla kogokolwiek, kto go wykradnie. Zrobione dobrze, to przenosi cię z najcięższego kwestionariusza, SAQ D, do najkrótszego, SAQ A. Sposób, w jaki to działa, wraz z tokenizacją, opisujemy w naszym przewodniku po integracji bramki płatniczej. Redukcja zakresu ma swoje granice. Segmentacja sieci nadal ma znaczenie nawet przy hostowanym procesie płatności; słabo zsegmentowana sieć może wciągnąć z powrotem do zakresu systemy, które nie mają z tym nic wspólnego. Outsourcing procesu płatności nie oznacza outsourcingu wszystkiego: narzędzie do zwrotów albo arkusz kalkulacyjny z wklejonym numerem karty potrafi po cichu zniweczyć tę korzyść.

PCI DSS 3.2.1 zostało wycofane w marcu 2024 roku. Jeśli dostawca albo stary wpis na blogu wciąż mówi o wersji 3.2.1, to znak, że ta porada jest nieaktualna. Obowiązującą wersją jest 4.0.1, czyli wydanie doprecyzowujące 4.0, a każde wymaganie jest teraz obowiązkowe, łącznie z tymi, które początkowo były jedynie „najlepszą praktyką” (ten okres przejściowy zakończył się 31 marca 2025 roku). Kilka zmian ma dla startupu większe znaczenie niż reszta. Uwierzytelnianie wieloskładnikowe obejmuje teraz cały dostęp do środowiska danych posiadaczy kart, a nie tylko dostęp zdalny czy administracyjny, a minimalna długość hasła wzrosła z siedmiu do dwunastu znaków. Prowadzisz płatności e-commerce? Nowe wymagania dotyczące zarządzania skryptami po stronie klienta i ochrony strony płatności przed manipulacją, wymierzone w ataki typu JavaScript skimming, warto sprawdzić nawet przy hostowanej bramce. Standard wprowadził też „podejście dostosowane” (customized approach), pozwalające spełnić wymagania w inny sposób, poparte udokumentowaną analizą ryzyka. Elastyczne na papierze; większość startupów na etapie MVP nadal lepiej wychodzi na standardowym, zdefiniowanym podejściu.

Garść błędów powtarza się raz za razem, gdy analizujemy stos płatniczy MVP w fintechu. Na czele listy jest przechowywanie CVV po autoryzacji, zwykle wewnątrz narzędzia wsparcia zbudowanego, by przyspieszyć zwroty. Przechowywanie CVV po autoryzacji nie jest dozwolone nigdy, zaszyfrowane czy nie, kropka. Tuż za tym plasują się numery kart wklejone do logów, narzędzi do śledzenia błędów albo współdzielonego arkusza kalkulacyjnego, rzadko celowo: stack trace przechwytuje surową treść zapytania, albo agent wsparcia wkleja numer do wątku czatu, by rozwiązać problem z nieudaną transakcją. Kolejnym częstym błędem jest założenie, że bramka zwalidowana pod kątem PCI automatycznie czyni cię zgodnym. To realna korzyść, znacząco zmniejsza zakres, ale wciąż musisz wypełnić odpowiedni SAQ i go zaatestować. Jest też pełzający wzrost zakresu: CDE, które zaczyna się czysto, a po kilku miesiącach dzieli sieć z połową narzędzi firmy, bo nikt nie wyznaczył granicy. Szersze praktyki bezpieczeństwa wokół tego wszystkiego opisujemy w naszym przewodniku po bezpieczeństwie i skalowalności MVP.

Nie każde wymaganie zasługuje na tyle samo uwagi pierwszego dnia. Jeśli planujesz płatności dla MVP w fintechu, oto z grubsza gdzie najpierw zainwestować swój ograniczony czas:

• Od pierwszego dnia kieruj wszystkie dane karty przez hosted fields albo przekierowanie. Dorabianie tego później, gdy twój własny kod już dotykał surowych numerów, kosztuje znacznie więcej niż zrobienie tego dobrze od razu.
• Potwierdź, który SAQ cię dotyczy, zanim zapyta o to partner bankowy.
• Ustaw ogólnofirmowy standard MFA i haseł już teraz, nawet przy zespole liczącym trzy osoby. Tanie na wczesnym etapie, kosztowne do doklejenia później.
• Trzymaj dane karty z dala od logów, narzędzi wsparcia i arkuszy kalkulacyjnych jako twardą zasadę od pierwszej linijki kodu płatności.
• Udokumentuj granicę swojego CDE, nawet jeśli to tylko pojedynczy diagram.
• Wracaj do oceny zakresu za każdym razem, gdy nowa funkcja inaczej dotyka płatności: subskrypcje, wypłaty czy ręczne zwroty potrafią po cichu poszerzyć zakres.
• Zbuduj relację z QSA, zanim będziesz jej potrzebować, zwłaszcza jeśli wzrost może pchnąć cię w stronę Poziomu 1.

Dopilnuj pierwszych trzech punktów, a reszta stanie się zauważalnie prostsza.