PCI DSS i RODO w sklepie internetowym — co musisz spełnić, zanim przyjmiesz płatność kartą

PCI DSS, RODO i NIS2/KSC to trzy osobne obowiązki o zupełnie różnym zakresie, choć łatwo wrzucić je do jednego worka z napisem „bezpieczeństwo sklepu”. PCI DSS dotyczy tylko sklepów przyjmujących płatność kartą, a jego faktyczny zakres zależy od sposobu podłączenia płatności: przekierowanie na stronę operatora daje najmniejszy zakres, osadzony iframe wymaga więcej. RODO dotyczy każdego sklepu, który przetwarza dane klientów, niezależnie od metody płatności. NIS2/KSC, choć ostatnio głośny, typowego sklepu internetowego z jednym sprzedawcą nie dotyczy wcale. Poniżej każdy z tych obowiązków po kolei, z odesłaniem do źródeł.

PCI DSS — co to jest, kto sprawdza zgodność

PCI DSS (Payment Card Industry Data Security Standard) to standard bezpieczeństwa danych kart płatniczych, opracowany przez organizacje płatnicze i zarządzany przez PCI Security Standards Council (PCI SSC); jego aktualna wersja to v4.0.1. Pod tym tytułem figuruje w oficjalnej bibliotece dokumentów PCI SSC, razem z dokumentem „PCI DSS Summary of Changes v4.0 to v4.0.1” (odczyt 5.10.2026). PCI SSC opublikował v4.0.1 w czerwcu 2024 r. jako ograniczoną rewizję v4.0 — z poprawkami redakcyjnymi i doprecyzowaniami, przy czym „There are no additional or deleted requirements in this revision” (blog PCI SSC, 11.06.2024, odczyt 5.10.2026).

Zgodność weryfikuje nie sam PCI SSC — organizacja publikuje standard, ale sprawdza go podmiot akceptujący zgodność, zwykle acquirer (bank obsługujący płatności sprzedawcy) albo organizacja płatnicza. Oficjalne FAQ PCI SSC mówi to wprost: „Merchants should continue to consult with their compliance-accepting entity, the entity to which the SAQ will be submitted (typically, an acquirer (merchant bank) or the payment brands), to determine if the merchant is required to submit an SAQ, and if so, which SAQ is appropriate for the merchant's environment” (pcisecuritystandards.org/faqs/1588, odczyt 5.10.2026). O tym, który dokument musisz wypełnić, decyduje więc Twój acquirer albo operator płatności, z którym współpracujesz — nie Ty sam i nie ten artykuł.

Elavon Polska, jeden z acquirerów działających w Polsce, formułuje obowiązek sprzedawcy wprost: standard PCI DSS „Muszą go spełniać wszystkie organizacje przetwarzające lub przechowujące takie dane”, a „Gdy przyjmujesz płatności bezgotówkowe, masz obowiązek zadbać, by były bezpieczne” (elavon.pl, odczyt 5.10.2026). PayU i Przelewy24 komunikują z kolei własną certyfikację. PayU deklaruje „zgodność z certyfikatem PCI DSS Poziom 1” (poland.payu.com, odczyt 5.10.2026), a Przelewy24 pisze: „Certyfikat gwarantuje spełnianie przez Przelewy24 standardu Payment Card Industry (PCI) Data Security Standard (DSS)” (przelewy24.pl/bezpieczenstwo, odczyt 5.10.2026). Żaden z tych dwóch operatorów nie pisze na tych stronach, że korzystanie z jego przekierowania zwalnia sklep z własnego SAQ — obaj potwierdzają swoją certyfikację, nie zakres obowiązków klienta.

Który SAQ dotyczy Twojego sklepu

SAQ (Self-Assessment Questionnaire) to kwestionariusz samooceny, którym sprzedawca potwierdza zgodność z PCI DSS, a jego zakres zależy od tego, jak płatność kartą jest podłączona na Twojej stronie.

Jeśli przekierowujesz klienta na stronę operatora płatności (przekierowanie HTTP 30x, meta-redirect albo przekierowanie JavaScript) albo w pełni zlecasz płatność zewnętrznemu dostawcy (TPSP, np. link do zapłaty w mailu), masz najmniejszy zakres. Zwykle kwalifikujesz się do najprostszego SAQ A — o ile spełniasz pozostałe kryteria, a acquirer to potwierdzi — a dodatkowe kryterium ochrony przed skryptami Cię nie dotyczy. PCI SSC FAQ #1588 mówi to wprost: kryterium skryptów SAQ A „does not apply to e-commerce merchants with a webpage that redirects customers from the merchant's webpage to a TPSP/payment processor […] or e-commerce merchants that fully outsource payment functions to a TPSP/payment processor”. Najmniejszy zakres nie oznacza jednak zerowego. Osobne FAQ #1604 potwierdza, że SAQ A „includes requirements for external vulnerability scanning by a PCI SSC Approved Scanning Vendor (ASV)… even where payment processing is fully outsourced to a third party” (odczyt 5.10.2026). Nawet przy pełnym przekierowaniu musisz więc zlecić zatwierdzonemu dostawcy (ASV) skan podatności swojej strony.

Jeśli osadzasz formularz płatności operatora w iframe na swojej stronie (klient płaci, nie opuszczając Twojej domeny, a pole karty wyświetla iframe operatora), kryterium skryptów SAQ A Cię dotyczy. FAQ #1588: „The above SAQ A eligibility criteria only applies to e-commerce merchants with a webpage that includes a TPSP's/payment processor's embedded payment page/form (for example, one or more inline frame(s) (iframes))”. To samo FAQ wskazuje dwie drogi spełnienia kryterium: zastosować techniki ochrony strony przed atakami skryptów na dane karty, w tym te z wymagań 6.4.3 i 11.6.1 PCI DSS, albo uzyskać od zgodnego z PCI DSS dostawcy iframe'a potwierdzenie, że jego rozwiązanie już takie techniki zawiera.

„PCI 4.0” — co się zmieniło i dlaczego data 31 marca 2025 jest ważna

Od 31 marca 2025 r. obowiązują wszystkie wymogi, które PCI DSS v4.0 ogłosił z wyprzedzeniem, w tym 6.4.3, 11.6.1 i 12.3.1 dotyczące bezpieczeństwa strony płatności i skryptów. Wersja 4.0 wprowadziła mechanizm wymogów „future-dated”: nowe wymagania ogłoszone z wyprzedzeniem można było przed datą wejścia w życie oznaczyć w ocenie zgodności jako „Not Applicable”, a od tej daty muszą być w pełni uwzględnione (FAQ #1564). Wydanie v4.0.1 tej daty nie zmieniło (blog PCI SSC z 11.06.2024). PCI SSC potwierdza wprost, że wymagania 6.4.3, 11.6.1 i 12.3.1 obowiązują od 31 marca 2025 r. W tym samym komunikacie usunął je z SAQ A, zastępując opisanym wyżej kryterium kwalifikacji dotyczącym skryptów, i zaznaczył, że zmiana nie usuwa ani nie osłabia tych wymogów w samym standardzie (blog PCI SSC, 30.01.2025, odczyt 5.10.2026).

FAQ #1593 (marzec 2025) dotyczy węższej kwestii: trzech wymogów, które 31 marca 2025 r. zastąpiły swoje poprzedniczki (te od tej daty oznacza się jako „Not Applicable”). To 6.4.2 — automatyczne wykrywanie i blokowanie ataków na publicznie dostępne aplikacje webowe (zastępuje 6.4.1), 8.3.10.1 — dla dostawców usług: zmiana hasła klienta co najmniej raz na 90 dni albo dynamiczna analiza bezpieczeństwa konta (zastępuje 8.3.10), oraz 10.7.2 — wykrywanie, zgłaszanie i szybkie usuwanie awarii krytycznych systemów kontrolnych (zastępuje 10.7.1). To nie jest pełna lista wymogów, które weszły w życie tego dnia, tylko tych, które zastąpiły wcześniejsze.

Hasło „PCI 4.0 jest ściśle egzekwowane od 2025 roku” warto czytać ostrożnie. PCI SSC pisze: „PCI SSC does not define compliance requirements for any organization or set compliance validation responsibilities” — wymogi walidacji ustalają organizacje płatnicze, acquirerzy i inni pośrednicy płatności (blog z 30.01.2025). Wymogi obowiązują w standardzie, a to, jak i kiedy sprawdzi je Twój acquirer, ustalasz z nim.

RODO w sklepie internetowym

RODO ([rozporządzenie (UE) 2016/679](https://eur-lex.europa.eu/legal-content/PL/TXT/HTML/?uri=CELEX:32016R0679)) dotyczy każdego sklepu, który przetwarza dane osobowe klientów — czyli praktycznie każdego sklepu internetowego, niezależnie od tego, czy przyjmuje płatność kartą. Największe znaczenie praktyczne mają cztery artykuły.

Art. 6 określa podstawy prawne przetwarzania. Realizacja zamówienia i obsługa konta klienta mieszczą się w lit. b — przetwarzanie „niezbędne do wykonania umowy”. Obowiązki ustawowe, takie jak wystawianie faktur i przechowywanie dokumentacji podatkowej, to lit. c. Marketing bezpośredni do dotychczasowych klientów zwykle opiera się na lit. f — przetwarzanie jest wtedy „niezbędne do celów wynikających z prawnie uzasadnionych interesów realizowanych przez administratora”. To jednak podstawa odrębna od zgody na konkretny kanał komunikacji z art. 398 Prawa komunikacji elektronicznej (opisanej w tekście o automatyzacji sprzedaży) i jej nie zastępuje — sklep potrzebuje obu naraz.

Art. 13 nakłada obowiązek informacyjny w chwili zbierania danych. Ust. 1 wymaga podania m.in. tożsamości administratora, celu i podstawy prawnej przetwarzania, a jeśli podstawą jest lit. f — także wskazania, jaki konkretnie prawnie uzasadniony interes jest realizowany. Ust. 2 dodaje m.in. okres przechowywania danych (albo kryteria jego ustalania), prawa osoby (dostęp, sprostowanie, usunięcie, ograniczenie, sprzeciw, przenoszenie), prawo wniesienia skargi do organu nadzorczego oraz informację, czy podanie danych jest wymogiem ustawowym lub umownym. Ust. 4 zwalnia z tego obowiązku, gdy osoba już dysponuje tymi informacjami — w praktyce rzadko dotyczy to nowego klienta składającego pierwsze zamówienie.

Art. 28 reguluje relację z podmiotami przetwarzającymi dane w Twoim imieniu — hostingiem, platformą SaaS, operatorem e-mail i SMS czy firmą fulfillmentową. Ust. 1: „Jeżeli przetwarzanie ma być dokonywane w imieniu administratora, korzysta on wyłącznie z usług takich podmiotów przetwarzających, które zapewniają wystarczające gwarancje wdrożenia odpowiednich środków technicznych i organizacyjnych, by przetwarzanie spełniało wymogi niniejszego rozporządzenia i chroniło prawa osób, których dane dotyczą”. Ust. 3 wymaga, by ta relacja opierała się na umowie — w praktyce to umowa powierzenia przetwarzania danych (DPA), którą zawierasz z każdym takim podmiotem.

Art. 32 zobowiązuje do wdrożenia odpowiednich środków technicznych i organizacyjnych, które zapewnią „stopień bezpieczeństwa odpowiadający temu ryzyku”, „uwzględniając stan wiedzy technicznej, koszt wdrażania oraz charakter, zakres, kontekst i cele przetwarzania oraz ryzyko naruszenia praw lub wolności osób fizycznych”. Przepis wymienia m.in. pseudonimizację i szyfrowanie danych, zdolność do zapewnienia ciągłej poufności i dostępności systemów, zdolność do szybkiego przywrócenia dostępności danych po incydencie oraz regularne testowanie skuteczności tych środków. To on sprawia, że kontrola dostępu, kopie zapasowe z testem odtwarzania i szyfrowanie są obowiązkiem prawnym, a nie tylko dobrą praktyką.

Naruszenie danych — 72 godziny i dwa poziomy kar

Po naruszeniu ochrony danych osobowych, np. wycieku bazy klientów po przejęciu konta administratora, masz co do zasady 72 godziny na zgłoszenie do UODO. Art. 33 ust. 1 RODO stanowi, że administrator „bez zbędnej zwłoki – w miarę możliwości, nie później niż w terminie 72 godzin po stwierdzeniu naruszenia – zgłasza je organowi nadzorczemu […], chyba że jest mało prawdopodobne, by naruszenie to skutkowało ryzykiem naruszenia praw lub wolności osób fizycznych”. Zgłoszenie złożone po 72 godzinach musi zawierać wyjaśnienie przyczyn opóźnienia. Jeśli korzystasz z zewnętrznego podmiotu przetwarzającego (np. hostingu czy platformy SaaS), jego obowiązkiem (ust. 2) jest zgłoszenie naruszenia Tobie bez zbędnej zwłoki. Twój termin na zgłoszenie do UODO biegnie od chwili, gdy Ty jako administrator stwierdzisz naruszenie — dlatego umowa powierzenia powinna precyzować, jak szybko podmiot przetwarzający Cię powiadamia.

Kary administracyjne z art. 83 mają dwa poziomy i warto wiedzieć, który przepis trafia do którego. Niższy poziom (ust. 4) — do 10 mln EUR albo do 2% całkowitego rocznego światowego obrotu przedsiębiorstwa z poprzedniego roku obrotowego, przy czym zastosowanie ma kwota wyższa — obejmuje m.in. obowiązki administratora i podmiotu przetwarzającego z art. 25–39, a więc także art. 32 (środki bezpieczeństwa) i art. 33 (zgłoszenie naruszenia). Wyższy poziom (ust. 5) — do 20 mln EUR albo do 4% obrotu — obejmuje naruszenia „podstawowych zasad przetwarzania, w tym warunków zgody” z art. 5, 6, 7 i 9 oraz praw osób, których dane dotyczą, z art. 12–22. Do wyższego poziomu trafia więc zarówno przetwarzanie bez podstawy z art. 6, jak i braki w obowiązku informacyjnym z art. 13. RODO traktuje błąd w podstawie prawnej czy w polityce prywatności poważniej niż techniczną wpadkę w zabezpieczeniach — choć oba poziomy kar mogą realnie dotyczyć sklepu internetowego.

NIS2/KSC — czy to dotyczy Twojego sklepu

Typowy sklep internetowy, w którym sprzedajesz wyłącznie własny towar, jest poza zakresem polskiej ustawy wdrażającej NIS2 — z dwóch niezależnych powodów. Tą ustawą jest ustawa z 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustaw (Dz.U. 2026 poz. 252), obowiązująca od 3 kwietnia 2026 r.

Pierwszy powód to wielkość. Dyrektywa NIS2 (art. 2 ust. 1) ma zastosowanie „do podmiotów publicznych lub prywatnych w rodzaju tych, o których mowa w załączniku I lub II, które kwalifikują się jako średnie przedsiębiorstwa na podstawie art. 2 załącznika do zalecenia 2003/361/WE lub które przekraczają pułapy dla średnich przedsiębiorstw”. Wyjątki niezależne od wielkości (art. 2 ust. 2) są wąskie: dotyczą m.in. dostawców publicznych sieci i usług łączności elektronicznej, dostawców usług zaufania, rejestrów domen najwyższego poziomu i dostawców usług DNS. Polska ustawa (art. 5) co do zasady również wiąże status podmiotu kluczowego lub ważnego z progiem średniego przedsiębiorcy.

Drugi, ważniejszy powód to rodzaj działalności. Nawet średni sklep musiałby najpierw pasować do definicji podmiotu objętego ustawą. Kategoria najbliższa e-commerce to dostawca internetowej platformy handlowej — znowelizowana ustawa o KSC (art. 2 pkt 4d) odsyła tu do art. 2 pkt 8 ustawy o prawach konsumenta (tekst jednolity Dz.U. 2026 poz. 1244). Według tej definicji internetowa platforma handlowa to usługa, w ramach której umożliwia się „konsumentom zawieranie z innymi przedsiębiorcami umów na odległość” albo osobom fizycznym niebędącym przedsiębiorcami zawieranie takich umów z innymi osobami fizycznymi. Chodzi więc o pośrednictwo między kupującym a osobą trzecią, jak na Allegro czy Amazonie. Zwykły sklep, w którym konsument zawiera umowę bezpośrednio z Tobą, tej definicji nie spełnia, niezależnie od wielkości firmy.

To wniosek z treści obu ustaw, a nie z interpretacji urzędowej czy orzecznictwa. Jeśli obok własnego sklepu prowadzisz platformę, na której sprzedają też inne firmy (czyli jesteś operatorem marketplace'u), sprawdź kwalifikację z prawnikiem — to już inna sytuacja prawna. To samo dotyczy firmy, która poza sklepem prowadzi działalność wymienioną w załącznikach do ustawy i jest co najmniej średnim przedsiębiorcą. Przykładem jest sektor żywności, w którym ustawa obejmuje przedsiębiorstwa spożywcze „zajmujące się dystrybucją hurtową oraz przemysłowymi produkcją i przetwarzaniem”. Wtedy o kwalifikacji decyduje ta działalność, nie sam sklep.

Checklista bezpieczeństwa

• Acquirer albo operator płatności potwierdził, który SAQ Cię dotyczy — nie zgadujesz tego na podstawie wyglądu checkoutu.
• Jeśli osadzasz formularz płatności w iframe, masz potwierdzenie od dostawcy iframe'a albo własne techniki ochrony skryptów zgodne z kryterium z FAQ #1588 — nie zakładasz, że „to problem operatora płatności”.
• Skan ASV Twojej strony jest zlecony, także przy przekierowaniu na stronę operatora.
• Polityka prywatności zawiera wszystkie elementy z art. 13 ust. 1–2 RODO: tożsamość administratora, cel i podstawę prawną, okres przechowywania, prawa osoby i prawo skargi do UODO.
• Z każdym podmiotem przetwarzającym dane w Twoim imieniu (hosting, SaaS, e-mail i SMS, fulfillment) masz umowę powierzenia (DPA) zgodną z art. 28.
• Masz procedurę na wypadek naruszenia danych: kto zgłasza je do UODO, w jakim terminie (72 godziny) i co zapisujecie jako wyjaśnienie, jeśli termin nie zostanie dotrzymany.
• Masz udokumentowane, a nie tylko założone, że Twój model biznesowy nie spełnia definicji internetowej platformy handlowej — jeśli nie prowadzisz marketplace'u, NIS2/KSC najpewniej Cię nie dotyczy.

Jeśli Twój system sprzedaży w dużej części opiera się na zewnętrznych usługach SaaS (hosting, płatności, ERP w chmurze), podział odpowiedzialności za bezpieczeństwo danych między Tobą a dostawcą to osobny, szerszy temat — opisujemy go w tekście o bezpieczeństwie danych w chmurze.