Nowa wersja PCI DSS i standard PCI KMO – 2 kluczowe wnioski z PCI Community Meeting 2026 w Vancouver

Zaktualizowano: 29 wrz 2026

Co wynika z PCI Community Meeting 2026 w Vancouver dla organizacji objętych standardami PCI? Dwie rzeczy mają największe znaczenie praktyczne. Po pierwsze, PCI SSC opublikowało standard PCI Key Management and Operations (KMO) v1.0, który porządkuje zarządzanie kluczami kryptograficznymi we wszystkich programach PCI – zaczynając od kluczy PIN i P2PE. Po drugie, nowa wersja PCI DSS jest w fazie konsultacji, a Rada szacuje jej publikację na Q2 2028, zastrzegając, że termin może się zmienić.

PCI Key Management and Operations (KMO) to standard PCI SSC opublikowany 14 września 2026, określający wymagania bezpieczeństwa i procedury testowe dla podmiotów zarządzających kluczami kryptograficznymi chroniącymi PIN, dane konta i inne wrażliwe zasoby w całym cyklu życia klucza.

Nowa wersja PCI DSS i PCI KMO – w skrócie:

1. PCI SSC opublikowało PCI KMO v1.0 14 wrz 2026, dzień przed rozpoczęciem North America Community Meeting (15-17 wrz 2026, Vancouver). Standard obejmuje cały cykl życia klucza – od generowania po zniszczenie.
2. KMO ma budowę modułową: wymagania wspólne dla każdego podmiotu oraz wymagania specyficzne dla 6 typów usług (DM, PPS, KIF, SSP, CA/RA, HaaS), których zależności opisuje macierz 3 standardu.
3. Jedna ocena KMO może potwierdzić bezpieczeństwo zarówno kluczy PIN, jak i kluczy P2PE – zgodnie z zasadą „assess once, use many”.
4. KMO może docelowo przejąć rolę standardu PCI PIN Security, ale o obowiązującym standardzie decydują organizacje kartowe – do czasu biuletynów Visa i Mastercard obowiązują dotychczasowe programy.
5. Nowa wersja PCI DSS przejdzie w 2027 roku dwie kolejne rundy konsultacji (RFC); szacowana publikacja to Q2 2028 i nie jest to termin wiążący.
6. Planowane kierunki zmian: włączenie wymagań PCI 3DS Core i TSP do PCI DSS jako załączników, połączenie podejścia niestandardowego z kontrolami kompensacyjnymi oraz doprecyzowanie zasad dla systemów AI – bez przepisywania całego standardu na wymagania oparte na celach.
7. PCI DSS v4.0.1 pozostaje jedynym obowiązującym punktem odniesienia dla audytu – oczekiwanie na kolejną wersję nie zwalnia z wdrażania bieżących wymagań.
8. Patronusec jako akredytowany QSA realizuje projekty PCI DSS, PCI PIN Security i PCI P2PE, dzięki czemu przejście na KMO i nową wersję PCI DSS można zaplanować w jednym harmonogramie zgodności, a nie w trzech równoległych projektach.

---

---

Co PCI SSC ogłosiło na Community Meeting 2026 w Vancouver?

Podczas North America Community Meeting w Vancouver (15-17 wrz 2026) PCI SSC przedstawiło dwa kierunki o największym znaczeniu dla rynku płatności: nowy standard PCI KMO v1.0 dla zarządzania kluczami kryptograficznymi oraz plan prac nad nową wersją PCI DSS, której publikację szacuje na Q2 2028. Oba wpisują się w strategię konsolidacji standardów PCI.

Tegoroczna edycja miała szczególny charakter. PCI SSC obchodziło 20-lecie działalności, a według komunikatu prasowego Rady wydarzenie w Vancouver Convention Centre zgromadziło banki, akceptantów, dostawców usług płatniczych, asesorów i dostawców technologii pod hasłem łączącym podsumowanie dwóch dekad z przyszłością bezpieczeństwa płatności. Dominującym tematem kuluarowym była sztuczna inteligencja – od warsztatów przedkonferencyjnych o powierzchni ataku w płatnościach agentowych (agentic payments) po publikację nowych wytycznych Security Considerations for AI Systems.

Z perspektywy organizacji objętych programami PCI najważniejsze są jednak nie pojedyncze ogłoszenia, ale kierunek, który je łączy:

• KMO zastępuje rozproszone wymagania dotyczące zarządzania kluczami jednym standardem z modułami dla konkretnych usług,
• nowa wersja PCI DSS ma wchłonąć wymagania PCI 3DS Core i Token Service Provider (TSP) jako dedykowane załączniki,
• Secure Software Standard v2.0 już wcześniej utworzył alternatywną ścieżkę oceny dla 3DS SDK w ramach tej samej strategii konsolidacji.

Wspólnym mianownikiem ogłoszeń z Vancouver jest modułowość: PCI SSC odchodzi od wielu odrębnych standardów na rzecz wspólnego rdzenia wymagań uzupełnianego modułami stosowanymi wyłącznie tam, gdzie organizacja faktycznie realizuje daną funkcję.

Ten sam wzorzec znamy z PCI Software Security Framework, w którym moduły dodatkowe stosuje się tylko do określonych typów oprogramowania. Dla organizacji oznacza to w perspektywie kilku lat mniej równoległych audytów, ale też konieczność precyzyjnego ustalenia, które moduły jej dotyczą.

Czym jest standard PCI Key Management and Operations (KMO)?

PCI KMO v1.0 to standard PCI SSC opublikowany 14 wrz 2026, który definiuje wymagania bezpieczeństwa, procedury testowe i wytyczne dla podmiotów obsługujących systemy wykorzystujące klucze kryptograficzne do ochrony danych konta. Obejmuje pełny cykl życia klucza oraz procedury, systemy i sprzęt używane do zarządzania kluczami i ich eksploatacji.

Według oficjalnego komunikatu PCI SSC zakres standardu obejmuje klucze chroniące PIN, dane konta oraz inne wrażliwe zasoby – w tym klucze używane do przechowywania, transportu i derywacji innych kluczy. Najważniejsze cechy KMO v1.0:

• Pierwsza faza: klucze PIN i P2PE. Standard konsoliduje, ujednolica i aktualizuje wymagania zarządzania kluczami, które dotąd funkcjonowały oddzielnie w PCI PIN Security i PCI P2PE.
• Jedna ocena, dwa typy kluczy. Pojedyncza ocena KMO może zwalidować bezpieczeństwo kluczy PIN i P2PE, a wynikowy KMO Listing może być referencjonowany przez rozwiązanie P2PE tam, gdzie ma to zastosowanie.
• HSM w chmurze i zdalne HSM. KMO bezpośrednio adresuje moduły HSM udostępniane jako usługa i powstał w zgodzie z opublikowanymi niedawno wymaganiami PCI HSM v5.
• Rozbudowa w kolejnych wersjach. Przyszłe rewizje mogą objąć potrzeby innych typów danych, np. tych regulowanych przez standardy Card Production.

W bibliotece dokumentów PCI SSC dostępne są już Requirements and Test Procedures v1.0 oraz Program Guide. Wymagania kwalifikacyjne dla asesorów KMO mają zostać opublikowane wkrótce – co oznacza, że formalne oceny KMO ruszą dopiero po zakwalifikowaniu pierwszych asesorów.

PCI KMO odwraca dotychczasową logikę standardów PCI: zamiast powtarzać wymagania zarządzania kluczami w każdym standardzie osobno, Rada utrzymuje je w jednym dokumencie, do którego odwołują się pozostałe programy.

Przykład: procesor, który jednocześnie tłumaczy bloki PIN dla acquirera i zarządza środowiskiem deszyfrowania rozwiązania P2PE, dziś przedstawia dowody dla tych samych HSM, tych samych ceremonii kluczy i tych samych opiekunów kluczy (key custodians) w dwóch odrębnych ocenach. W modelu KMO wspólne wymagania ocenia się raz, a moduły specyficzne dla usługi PPS i DM – dodatkowo.

Patronusec Insight: Najczęstsza pułapka, jaką obserwujemy w środowiskach PIN i P2PE, to rozjazd dokumentacji: ta sama ceremonia generowania klucza opisana w dwóch procedurach, z innymi rolami i innym formatem logów. KMO bezlitośnie to ujawni, bo jedna ocena wymaga jednego, spójnego obrazu cyklu życia klucza. W ramach ocen PCI PIN Security porządkujemy dziś procedury kluczowe tak, by od razu dało się je zmapować na wymagania wspólne KMO.

Których organizacji dotyczy PCI KMO?

PCI KMO dotyczy podmiotów, które zarządzają kluczami kryptograficznymi chroniącymi PIN lub dane konta – dla siebie lub w imieniu innych organizacji. Standard łączy wymagania wspólne dla wszystkich z wymaganiami specyficznymi dla sześciu typów usług, a zależności między nimi opisuje macierz 3 (Matrix 3) w standardzie.

Sześć typów usług KMO i ich zakres:

Typ usługi KMO	Czym się zajmuje	Przykładowy podmiot
DM (Decryption Management)	Zarządza środowiskiem deszyfrowania w komponentowym rozwiązaniu P2PE	Dostawca komponentu deszyfrowania P2PE
PPS (PIN-Processing Service)	Wykonuje operacje na PIN (np. weryfikację, translację), nie będąc wydawcą karty	Procesor lub agent acquirera tłumaczący bloki PIN
KIF (Key-Injection Facility)	Świadczy usługi kryptograficzne dla innych podmiotów: generowanie, przekazywanie i ładowanie kluczy (lokalne i zdalne)	Dostawca wstrzykiwania kluczy do terminali POI
SSP (Signing Service Provider)	Podpisuje oprogramowanie lub pakiety danych (firmware, aplikacje, pliki konfiguracyjne) dla innych podmiotów	Podmiot podpisujący firmware terminali
CA/RA (Certification/Registration Authority)	Podpisuje klucze publiczne (certyfikaty X.509 i inne) na potrzeby zdalnej dystrybucji kluczy symetrycznych; RA weryfikuje wnioski w imieniu CA	Urząd certyfikacji w schemacie Remote Key Loading
HaaS (HSM-as-a-Service)	Zarządza klastrem HSM udostępnianym innym podmiotom	Dostawca chmurowego lub zdalnego HSM

Jeden podmiot może realizować kilka typów usług KMO jednocześnie – wtedy spełnia wymagania wspólne raz, a wymagania specyficzne dla każdej świadczonej usługi osobno.

Drzewo decyzyjne: czy KMO dotyczy Twojej organizacji?

1. Czy Twoja organizacja generuje, przechowuje, dystrybuuje, ładuje lub niszczy klucze chroniące PIN lub dane konta?
   • Nie → KMO nie dotyczy Cię bezpośrednio. Sprawdź jednak, czy Twoi dostawcy (procesor, dostawca P2PE, dostawca HSM) będą się na nie powoływać.
   • Tak → przejdź do pytania 2.
2. Czy świadczysz którąś z usług DM, PPS, KIF, SSP, CA/RA lub HaaS (dla siebie lub innych podmiotów)?
   • Tak → obowiązują Cię wymagania wspólne KMO oraz moduły dla każdej świadczonej usługi (macierz 3).
   • Nie jestem pewien → zinwentaryzuj operacje na kluczach i przypisz je do typów usług przed kolejną oceną.
3. Czy Twoja obecna walidacja wynika z programu PIN organizacji kartowej lub z listingu P2PE?
   • Tak → utrzymuj dotychczasowe oceny do czasu biuletynów Visa i Mastercard, równolegle przygotowując mapowanie na KMO.

---

Przetwarzasz jednocześnie klucze PIN i P2PE albo świadczysz usługi KIF lub HaaS?

W 30-minutowej rozmowie przypiszemy Twoje operacje na kluczach do typów usług KMO i wskażemy, które elementy obecnych ocen PCI PIN Security i P2PE będą do ponownego wykorzystania po przejściu na KMO.

Umów bezpłatną konsultację

---

Czy PCI KMO zastąpi standard PCI PIN Security?

Potencjalnie tak, ale nie automatycznie. Na Community Meeting sygnalizowano, że KMO docelowo ma przejąć rolę PCI PIN Security w obszarze zarządzania kluczami. O tym, który standard organizacja musi spełnić, decydują jednak programy zgodności organizacji kartowych – dlatego kluczowe będą nadchodzące biuletyny Visa i Mastercard.

Ta różnica ma znaczenie praktyczne. PCI SSC tworzy i utrzymuje standardy, ale nie egzekwuje zgodności – robią to organizacje kartowe (Visa, Mastercard) w swoich programach oraz acquirerzy w umowach z podmiotami. Dotyczy to w szczególności bezpieczeństwa PIN, gdzie obowiązek oceny i jej częstotliwość wynikają z reguł poszczególnych organizacji kartowych.

Publikacja standardu przez PCI SSC nie tworzy obowiązku zgodności – obowiązek powstaje dopiero wtedy, gdy organizacja kartowa lub acquirer wpisze ten standard do swoich wymagań.

Do czasu ogłoszenia stanowisk przez organizacje kartowe warto przyjąć trzy założenia robocze:

• Bieżące oceny PCI PIN Security pozostają ważne i należy je realizować według dotychczasowego harmonogramu.
• Okres przejściowy jest prawdopodobny. Visa i Mastercard mogą ogłosić stanowiska w różnym czasie i z różnymi terminami, co przez pewien czas może oznaczać równoległe funkcjonowanie obu standardów.
• Rozwiązania P2PE zyskają możliwość referencjonowania KMO Listingu, co z czasem uprości walidację komponentów zarządzania kluczami w rozwiązaniach PCI P2PE.

W praktyce oznacza to: nie wstrzymuj zaplanowanej oceny PIN w oczekiwaniu na KMO, ale przy jej okazji uporządkuj dokumentację tak, by pasowała do struktury nowego standardu.

Kiedy pojawi się nowa wersja PCI DSS?

Według orientacyjnej mapy drogowej przedstawionej w Vancouver nowa wersja PCI DSS ma zostać opublikowana szacunkowo w Q2 2028. Wcześniej, w 2027 roku, PCI SSC przeprowadzi dwie kolejne rundy konsultacji (RFC), a projekt przejdzie przegląd interesariuszy i głosowanie Board of Advisors. Rada wyraźnie zastrzegła, że terminy mogą się zmienić.

Etap	Termin orientacyjny	Status
RFC 1 dla PCI DSS v4.0.1	2026	Zakończony; trwa analiza 884 komentarzy od 70 organizacji
RFC 2	Q1/Q2 2027	Planowany
RFC 3	Druga połowa 2027	Planowany
Dalsze prace redakcyjne, przegląd interesariuszy, głosowanie Board of Advisors	Po zakończeniu RFC	Planowane
Publikacja nowej wersji PCI DSS	Szacunkowo Q2 2028	Termin niewiążący, może się zmienić

Q2 2028 to szacunek, a nie termin zgodności – do publikacji nowej wersji wymagania PCI DSS v4.0.1 pozostają jedynym obowiązującym punktem odniesienia dla audytu QSA.

Warto pamiętać też o okresie przejściowym. Przy poprzedniej zmianie PCI DSS v4.0 opublikowano 31 mar 2022, a v3.2.1 wycofano dopiero 31 mar 2024. Nawet jeśli nowa wersja ukaże się zgodnie z planem, organizacje najprawdopodobniej będą miały czas na przejście – choć długość tego okresu nie została jeszcze ogłoszona.

Jakie zmiany planuje PCI SSC w nowej wersji PCI DSS?

PCI SSC wskazało cztery cele: rozszerzenie struktury bezpieczeństwa środowiska poza model oparty wyłącznie na PAN, większą elastyczność doboru rygoru do ryzyka, jaśniejszy zakres i ścieżki dla użytkowników zwalidowanych rozwiązań PCI oraz dalsze upraszczanie opcji walidacji i dokumentacji w całym ekosystemie standardów PCI.

PCI 3DS Core i TSP jako załączniki do PCI DSS

PCI SSC rozważa włączenie wymagań PCI 3DS Core oraz Token Service Provider (TSP) do PCI DSS, najprawdopodobniej w formie dedykowanych załączników. Kluczowe doprecyzowanie z Vancouver: nie oznacza to, że każdy akceptant stanie się podmiotem objętym wymaganiami 3DS lub TSP. Wymagania te dotyczyłyby wyłącznie organizacji realizujących funkcje 3DS (np. ACS, DS, 3DS Server) lub wydających tokeny EMV. Dla większości podmiotów oceniających dziś zgodność z PCI DSS dotychczasowe wymagania dla danych konta i model walidacji pozostaną bez zmian.

Więcej wymagań opartych na celach – ale nie cały standard

Rada zamierza uprościć część najbardziej złożonych wymagań i zwiększyć swobodę w sposobie osiągania celów bezpieczeństwa. Jednocześnie jasno zakomunikowała, że nie planuje przepisania całego standardu na wymagania oparte na celach (objective-based). Wyniki konsultacji to potwierdzają: interesariusze nie proszą o usunięcie szczegółów, lecz częściej o większą jasność i więcej wytycznych.

Preskryptywność PCI DSS jest jego zaletą, a nie wadą – dla organizacji bez dużych zespołów bezpieczeństwa precyzyjny opis „jak wygląda dobrze” ma większą wartość niż sam cel kontrolny.

Podejście niestandardowe i kontrole kompensacyjne w jednym mechanizmie

Podejście niestandardowe (customized approach), wprowadzone w PCI DSS v4.0, pozwala spełnić cel wymagania innym projektem kontroli. W praktyce przyjęło się słabiej, niż zakładano: organizacje mają trudność z rozróżnieniem, kiedy stosować podejście niestandardowe, a kiedy kontrolę kompensacyjną, a dokumentacja bywa obszerna. Rozważana koncepcja zakłada połączenie obu ścieżek w jeden mechanizm „spełnienia wymagania inaczej” z jednym, wspólnym arkuszem (worksheet).

Zwalidowane rozwiązania PCI

Czwarty obszar to jaśniejszy zakres i ścieżki dla organizacji korzystających ze zwalidowanych rozwiązań PCI SSC (np. P2PE, MPoC). Dla akceptantów to potencjalnie najprostsza droga do ograniczenia zakresu oceny.

Jak nowa wersja PCI DSS podejdzie do sztucznej inteligencji (AI)?

PCI DSS pozostanie neutralny technologicznie. Jeśli system AI jest komponentem środowiska PCI lub może wpływać na jego bezpieczeństwo, obowiązują go te same wymagania co każdą inną technologię. Nowa wersja ma raczej doprecyzować język i wytyczne dotyczące systemów, funkcji i przepływów danych AI oraz oczekiwania w zakresie nadzoru nad AI.

Przekaz z Vancouver był pragmatyczny: AI nie wymaga osobnego „uniwersum bezpieczeństwa” w PCI DSS. Zamiast dziesiątek technicznych kontroli specyficznych dla AI Rada rozważa oczekiwania z obszaru ładu organizacyjnego (governance), które sprowadzają się do pięciu pytań:

• Gdzie w organizacji wykorzystujemy AI?
• Do czego jest używana?
• Do jakich danych ma dostęp?
• Kto jest uprawniony do jej używania?
• Jak wygląda dopuszczalne użycie?

Równolegle PCI SSC opublikowało podczas Community Meeting wytyczne Security Considerations for AI Systems, rozwijające zasady dotyczące AI ogłoszone w 2025 roku.

AI w środowisku płatniczym to problem nadzoru i zakresu, a nie osobna kategoria techniczna – system AI z dostępem do danych konta podlega PCI DSS na tych samych zasadach co każdy inny komponent systemu.

Organizacje, które już dziś stosują AI w obsłudze klienta, analizie fraudów lub operacjach IT w pobliżu środowiska CDE, powinny zacząć od rejestru zastosowań i polityki użycia – elementy takiej polityki opisujemy w artykule Polityka AI w firmie – 10 elementów.

Co branża zgłosiła w pierwszym RFC dla PCI DSS v4.0.1?

W pierwszej rundzie Request for Comments dla PCI DSS v4.0.1 70 organizacji zgłosiło 884 komentarze. Najwięcej uwag dotyczyło wymagań 6, 11 i 12, w szczególności kontroli skryptów na stronach płatności (wymagania 6.4.3 i 11.6.1). Powracały też tematy AI, chmury, API, MFA, passkeys, haseł i kryptografii.

Pełna lista powracających tematów zgłoszonych przez uczestników konsultacji:

• AI, chmura i API,
• uwierzytelnianie, MFA i passkeys,
• wymagania dotyczące haseł i ich zgodność z aktualną praktyką branżową,
• kryptografia, zarządzanie kluczami i keyed hashing,
• kontrola dostępu zdalnego,
• wymagania 6.4.3 i 11.6.1 dla stron płatności.

Wymagania 6.4.3 i 11.6.1 pozostają najbardziej dyskutowanym obszarem PCI DSS v4.0.1 – zarówno w konsultacjach PCI SSC, jak i w praktyce audytowej.

Zwróć uwagę na punkt styku z pierwszym wnioskiem: kryptografia i zarządzanie kluczami pojawiają się zarówno w komentarzach do PCI DSS, jak i w nowym standardzie KMO. Można się spodziewać, że PCI SSC będzie dążyć do spójności wymagań kryptograficznych w obu dokumentach.

Co Twoja organizacja powinna zrobić teraz?

Nie czekać. PCI DSS v4.0.1 pozostaje obowiązującym standardem, a dobrze wdrożone kontrole nie stracą wartości po publikacji nowej wersji. Priorytety na dziś to bezpieczeństwo stron płatności, zarządzanie podatnościami, uwierzytelnianie, nadzór nad dostawcami, ograniczanie zakresu PCI i inwentaryzacja zastosowań AI w środowisku płatniczym.

Rekomendowane działania według profilu organizacji:

Akceptanci i dostawcy usług objęci PCI DSS:

• dokończ wdrożenie wymagań v4.0.1, zwłaszcza 6.4.3 i 11.6.1, uwierzytelniania wieloskładnikowego i zarządzania podmiotami trzecimi,
• ograniczaj zakres PCI tam, gdzie jest to uzasadnione, i oceniaj zwalidowane rozwiązania (P2PE, tokenizacja),
• zinwentaryzuj zastosowania AI w środowisku CDE i w jego pobliżu.

Podmioty zarządzające kluczami (PIN, P2PE, KIF, HSM):

• przypisz swoje operacje na kluczach do typów usług KMO,
• zweryfikuj spójność procedur ceremonii kluczy między ocenami PIN i P2PE,
• sprawdź, czy dostawca HSM w chmurze planuje zgodność z PCI HSM v5,
• monitoruj biuletyny Visa i Mastercard dotyczące statusu KMO.

Dobra architektura bezpieczeństwa wdrożona dziś nie stanie się złą praktyką tylko dlatego, że pojawi się nowy numer wersji standardu.

Patronusec Insight: Z naszego doświadczenia projektowego wynika, że organizacje, które odkładają wdrożenie wymagań 6.4.3 i 11.6.1 „do nowej wersji”, trafiają na audyt z niezgodnością w obszarze, który Rada wprost wskazała jako najczęściej komentowany – a nie jako przeznaczony do usunięcia. Konsultacje mogą zmienić sposób opisu tych wymagań, ale nie ich cel. Analiza luk PCI DSS pod kątem v4.0.1 pokazuje, co trzeba domknąć teraz, a co warto zaprojektować elastycznie z myślą o kolejnej wersji.

Jakie mity o PCI KMO i nowej wersji PCI DSS warto zweryfikować?

Po Community Meeting na rynku krąży kilka uproszczeń, które mogą prowadzić do błędnych decyzji budżetowych i projektowych. Poniższe zestawienie konfrontuje je z tym, co faktycznie ogłosiło PCI SSC.

MIT: PCI KMO już zastąpił standard PCI PIN Security.
FAKT: KMO v1.0 opublikowano 14 wrz 2026, ale o tym, który standard jest wymagany, decydują programy organizacji kartowych. Do czasu biuletynów Visa i Mastercard obowiązują dotychczasowe wymagania.

MIT: Nowa wersja PCI DSS zacznie obowiązywać w 2028 roku.
FAKT: Q2 2028 to szacowany termin publikacji, zastrzeżony przez Radę jako zmienny. Termin obowiązywania i okres przejściowy nie zostały ogłoszone.

MIT: Po włączeniu 3DS Core do PCI DSS każdy akceptant będzie musiał spełnić wymagania 3DS.
FAKT: Wymagania 3DS i TSP mają dotyczyć wyłącznie podmiotów realizujących te funkcje.

MIT: Nowa wersja PCI DSS będzie w całości oparta na celach.
FAKT: PCI SSC nie planuje przepisania całego standardu na wymagania oparte na celach; preskryptywność ma pozostać tam, gdzie wnosi wartość.

MIT: AI będzie wymagała osobnego zestawu kontroli w PCI DSS.
FAKT: PCI DSS pozostaje neutralny technologicznie; zmiany mają dotyczyć doprecyzowania języka, wytycznych i oczekiwań w zakresie nadzoru nad AI.

---

FAQ

---

Warto przeczytać

1. Przewodnik po standardzie PCI DSS cz. 1 – kto podlega PCI DSS, poziomy zgodności, ROC i AOC: fundament przed analizą zmian w kolejnej wersji.
2. Zakres certyfikacji PCI DSS – od czego zacząć i jak go określić – ograniczanie zakresu to działanie, które zachowa wartość niezależnie od nowej wersji standardu.
3. Agentic Payment Provider i Network Tokeny Visa (VTS) – kontekst tokenizacji i płatności agentowych, istotny przy planowanym włączeniu wymagań TSP do PCI DSS.
4. Polityka AI w firmie – 10 elementów – praktyczny punkt wyjścia do pytań o nadzór nad AI, które PCI SSC zapowiada w nowej wersji PCI DSS.

---

Nowa wersja PCI DSS i PCI KMO – bezpłatna konsultacja

Patronusec jako akredytowany QSA realizuje projekty PCI DSS, PCI PIN Security i PCI P2PE dla klientów z sektora fintech, retail, e-commerce i finansowego – dzięki temu widzimy zmiany z Vancouver jednocześnie z perspektywy standardu, audytu i codziennych operacji na kluczach.

W bezpłatnej 30-minutowej konsultacji pomożemy Ci:

• ustalić, czy i jako który typ usługi (DM, PPS, KIF, SSP, CA/RA, HaaS) Twoja organizacja podlega PCI KMO,
• wskazać elementy obecnych ocen PIN i P2PE, które da się ponownie wykorzystać w ocenie KMO,
• zidentyfikować luki w PCI DSS v4.0.1, które trzeba zamknąć niezależnie od harmonogramu nowej wersji,
• zaplanować harmonogram zgodności uwzględniający RFC w 2027 roku i szacowaną publikację w 2028 roku.

Umów bezpłatną konsultację | PCI DSS | PCI PIN Security | PCI P2PE | Analiza luk