---
title: "PCI DSS checklist dla startupów"
slug: "pci-dss-compliance-checklist-startups"
url: "https://mvp-development.io/pl/blog/pci-dss-compliance-checklist-startups"
type: post
lang: pl
date: "2026-05-21"
last_modified: "2026-05-21"
version: "1.0"
summary: "Praktyczna checklist zgodności PCI DSS dla startupów fintech: 12 wymagań w prostych słowach, typy SAQ, redukcja zakresu i zmiany w PCI DSS 4.0."
author: "MVP Development"
tags: ["checklist zgodności pci dss", "kogo dotyczy pci dss", "co to jest cde w pci dss", "pci dss 4.0", "oprogramowanie do zgodności pci dss", "saq pci dss", "redukcja zakresu pci dss"]
use:
  training: allow
  rag: allow
  embedding: allow
attribution: required
---

# PCI DSS checklist dla startupów

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](https://mvp-development.io/blog/kyc-aml-compliance-fintech-mvp) 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](https://mvp-development.io/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.

### Typy SAQ w skrócie

| 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.

### 12 wymagań PCI DSS w prostych słowach

| # | 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](https://mvp-development.io/blog/payment-gateway-integration-guide).

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ść.

## 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](https://mvp-development.io/blog/mvp-security-scalability-guide).

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.

## FAQ

**Czy PCI DSS dotyczy startupu, który nie przetworzył jeszcze ani jednej transakcji?**

W praktycznym sensie jeszcze nie. Obowiązki zaczynają obowiązywać w momencie, gdy przez twoje systemy zaczynają przepływać prawdziwe dane posiadaczy kart, nawet w ograniczonej becie. Mimo to większości startupów lepiej wychodzi projektowanie pod kątem zgodności jeszcze przed pierwszą transakcją, niż przerabianie później płatności zbudowanej bez PCI DSS na uwadze.

**Co dokładnie wchodzi w skład CDE, jeśli korzystam z hostowanej bramki płatniczej?**

Pipeline CI/CD, który wdraża twoją płatność, panel do zwrotów albo laptop kontraktora używany do debugowania nieudanej transakcji, wszystkie mogą wejść w zakres, mimo że żadne z nich nie jest miejscem, gdzie żyją numery kart. Liczy się też wszystko, co może wpłynąć na bezpieczeństwo systemów, które faktycznie je przechowują. Hostowana bramka zmniejsza ten obszar, ale go nie usuwa.

**Mój QSA wspomniał o wymaganiach wersji 3.2.1 w starym dokumencie. Czy powinienem się martwić?**

Warto to sprawdzić, tak. Ta wersja została wycofana już w marcu 2024 roku, więc każda ocena, która wciąż się na nią powołuje, jest nieaktualna. Nie oznacza to automatycznie, że rada jest błędna; wiele podstawowych mechanizmów kontrolnych przeszło do wersji 4.0 z jedynie drobnymi zmianami w treści.

**Na co właściwie zwracać uwagę przy wyborze oprogramowania do zgodności PCI DSS?**

Pomiń wszystko, co obiecuje „automatyczną zgodność”. Żadne oprogramowanie tego nie robi. Ważniejsze jest to, czy narzędzie mapuje się na konkretny SAQ, który wypełniasz, i czy odróżnia ogólne narzędzia bezpieczeństwa od akredytacji dostawcy autoryzowanych skanów (Approved Scanning Vendor, ASV) potrzebnej do skanów zewnętrznych. Pomylenie tych dwóch rzeczy kosztuje zespoły realny czas podczas pierwszego cyklu oceny.

**Czym w prostych słowach jest SAQ?**

Osoba na stanowisku kierowniczym w twojej firmie podpisuje go i przekazuje bankowi rozliczeniowemu albo procesorowi płatności, w zależności od tego, kto o niego poprosił. Ten podpis to formalne oświadczenie, więc traktuj go jak każdy dokument podpisywany prawnie wiążąco. Samoocena przestaje wystarczać, gdy osiągniesz wolumen Poziomu 1, gdzie jej miejsce zajmuje audyt prowadzony przez QSA.

**Jaki jest najszybszy sposób na redukcję zakresu PCI, jeśli jesteśmy w trakcie budowy i już dotykamy surowych danych karty?**

Przede wszystkim przełącz swój proces płatności na hosted fields albo przekierowanie. To większy refaktoring w trakcie budowy, ale wciąż szybszy niż utwardzanie samodzielnie zarządzanego CDE do standardów SAQ D. Każdy tydzień spędzony na własnej obsłudze danych karty to tydzień niespędzony na produkcie.

**Czy muszę zatrudnić QSA, jeśli tylko wypełniam samoocenę?**

Dla większości typów SAQ nie jest to wymagane; oceny prowadzonej przez QSA potrzebują tylko sprzedawcy z Poziomu 1. Mimo to kilka godzin pracy QSA nad przeglądem twojej konfiguracji przed samodzielną atestacją to dobrze wydane pieniądze, zwłaszcza przy pierwszym SAQ.

**Co właściwie się dzieje, gdy w startupie dojdzie do wycieku danych, a okazuje się, że nie był on zgodny z PCI?**

Zależy to od wagi incydentu i tego, jak doszło do wycieku, więc do każdej konkretnej kwoty znalezionej w sieci podchodź ze sceptycyzmem. Możesz spodziewać się kar finansowych od organizacji kartowych, przekazywanych przez twój bank, skalowanych do wolumenu i skali niedopełnienia wymagań, wyższych stawek za przetwarzanie transakcji oraz realnego ryzyka utraty możliwości przyjmowania kart, jeśli luka była poważna albo wcześniej złożono fałszywą atestację. Większy koszt zwykle jest mniej widoczny: powiadomienie o naruszeniu, dochodzenie śledcze i godziny założycieli spędzone na sprzątaniu skutków zamiast na produkcie. Zapobieganie jest zauważalnie tańsze.