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.
Czym jest PCI DSS
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.
Kogo dotyczy PCI DSS
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.
Poziomy zgodności i typy SAQ
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.
| Typ SAQ | Dla kogo | Co to dla ciebie oznacza |
|---|---|---|
| SAQ A | W pełni zewnętrzny, hostowany proces płatności; dane karty nigdy nie trafiają na twoje serwery | Najkrótszy kwestionariusz; cel większości startupów |
| SAQ A-EP | Proces płatności częściowo hostowany, ale twój kod nadal ma kontakt ze stroną płatności | Więcej wymagań kontrolnych oraz zabezpieczenia przed manipulacją |
| SAQ C-VT | Transakcje wpisywane ręcznie przez wirtualny terminal, bez przechowywania danych | Częste przy zwrotach realizowanych telefonicznie |
| SAQ D (Sprzedawca) | Nie pasuje do żadnej węższej kategorii albo przechowuje dane karty bezpośrednio | Najdłuższy kwestionariusz; wszystkie 12 kategorii w pełnym zakresie |
Szybki test: jeśli numer karty klienta nigdy nie trafił nigdzie poza hostowane pole bramki płatniczej, najprawdopodobniej jesteś w obszarze SAQ A. W chwili gdy twój własny kod zaczyna dotykać lub przechowywać surowy numer karty, twój zakres rośnie. Potwierdź, który SAQ faktycznie pasuje, nie zakładaj z góry, że to ten najprostszy.
Checklist zgodności PCI DSS (12 wymagań w prostych słowach)
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.
| # | Wymaganie | Co to oznacza w praktyce |
|---|---|---|
| 1 | Wdróż i utrzymuj zabezpieczenia sieci | Firewalle lub równoważne mechanizmy między systemami a niezaufanymi sieciami |
| 2 | Stosuj bezpieczne konfiguracje | Żadnych domyślnych haseł ani pozostawionych ustawień producenta |
| 3 | Chroń przechowywane dane kont | Nie przechowuj danych, których nie potrzebujesz; nigdy nie przechowuj CVV po autoryzacji |
| 4 | Chroń dane posiadaczy kart podczas przesyłania | Silne szyfrowanie danych karty przesyłanych przez sieci publiczne |
| 5 | Chroń się przed złośliwym oprogramowaniem | Narzędzia antymalware na systemach, które mogłyby zostać zainfekowane |
| 6 | Twórz i utrzymuj bezpieczne systemy oraz oprogramowanie | Łatanie, bezpieczne kodowanie i kontrola zmian w obrębie CDE |
| 7 | Ogranicz dostęp do niezbędnego minimum | Dostęp ograniczony do tego, czego dana rola faktycznie wymaga |
| 8 | Identyfikuj użytkowników i uwierzytelniaj dostęp | Unikalne loginy i uwierzytelnianie wieloskładnikowe przy dostępie do CDE |
| 9 | Ogranicz dostęp fizyczny | Fizyczne zabezpieczenia wokół sprzętu obsługującego dane karty |
| 10 | Rejestruj i monitoruj dostęp | Dzienniki audytowe obejmujące dostęp do danych karty, przechowywane i regularnie przeglądane |
| 11 | Regularnie testuj bezpieczeństwo | Skany podatności oraz, tam gdzie to wymagane, kwartalne skany ASV |
| 12 | Wesprzyj to politykami organizacyjnymi | Udokumentowana polityka bezpieczeństwa i formalna ocena ryzyka |
Redukcja zakresu PCI (tokenizacja, hosted fields)
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ść.
Otrzymaj wycenę o stałym zakresie dla swojego MVP gotowego pod PCI
Podaj nam docelową bramkę płatniczą, wymagania zgodności i datę startu. W odpowiedzi dostaniesz jedną kwotę, jeden harmonogram i jasną granicę między tym, co zbudujemy my, a tym, co podłączysz sam.
Odbierz wycenęCo zmieniło się w PCI DSS 4.0
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.
Oprogramowanie do zgodności nie wypełni za ciebie SAQ, ale narzędzia takie jak Vanta, Drata i Secureframe realnie skracają czas potrzebny na zbieranie dowodów: przeglądy dostępów i dokumenty polityk są śledzone automatycznie zamiast ręcznie wyszukiwane. Niektóre oferują teraz wspomagany przez AI przegląd dowodów, który szybciej wyłapuje luki. Przydatne przy żmudnej pracy, ale nie zastąpi oceny QSA.
Najczęstsze błędy startupów w PCI DSS
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.
Błąd, który widzimy często: zespół zakłada, że do SAQ trzeba wracać tylko raz w roku, przy odnowieniu. W rzeczywistości to żywy dokument. Wystarczy dodać narzędzie do zwrotów, zmienić bramkę płatniczą albo pozwolić kontraktorowi dotknąć CDE bez aktualizacji odpowiedzialności, a środowisko już odbiega od tego, co zostało zaatestowane.
Priorytety PCI na etapie 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.
Tags
