Komponent P2PE, rozwiązanie P2PE i aplikacja P2PE – 3 ścieżki walidacji dla dostawców

Czym różnią się rozwiązanie, komponent i aplikacja P2PE? Rozwiązanie P2PE to kompletny, walidowany zestaw obejmujący wszystkie 5 domen standardu. Komponent P2PE to wydzielona usługa (np. wstrzykiwanie kluczy albo zarządzanie deszyfracją), walidowana osobno do wykorzystania w rozwiązaniach innych dostawców. Aplikacja P2PE to oprogramowanie z dostępem do jawnych danych kartowych, instalowane na zatwierdzonym urządzeniu POI.

Definicja kanoniczna: Komponent P2PE to usługa obejmująca wydzielony podzbiór wymogów standardu PCI P2PE (m.in. zarządzanie szyfrowaniem, deszyfracją lub kluczami), świadczona przez dostawcę komponentu na rzecz dostawców rozwiązań P2PE i wpisywana na listę PCI SSC.

Ten artykuł jest adresowany do dostawców: firm, które budują własne rozwiązanie P2PE, świadczą usługi innym dostawcom albo rozwijają oprogramowanie na terminale i zastanawiają się, którą ścieżkę walidacji wybrać.

Komponent, rozwiązanie i aplikacja P2PE – w skrócie:

1. Aktualny standard PCI P2PE v3.2 (cze 2025) dzieli wymagania na 5 domen; pełne rozwiązanie musi pokryć wszystkie, komponent tylko przypisany mu podzbiór.
2. Wersja 3.0 standardu (gru 2019) podwoiła katalog komponentów, dodając 4 nowe typy: PDCP, PMCP, KMCP i KLCP obok wcześniejszych EMS, DMS, KIF i CA/RA (komunikat prasowy PCI SSC, szablony P-ROV).
3. Domena 3 (zarządzanie rozwiązaniem) nie podlega outsourcingowi – zawsze odpowiada za nią dostawca rozwiązania, nawet jeśli resztę realizują komponenty.
4. Aplikacja P2PE może zostać oceniona według Domeny 2 w ramach walidacji rozwiązania albo osobno, z wpisem na listę Validated P2PE Applications – druga ścieżka opłaca się, gdy aplikacja trafia do wielu rozwiązań.
5. Trzecia strona wykonująca funkcje P2PE ma zawsze dwie opcje: własny P-ROV i wpis na listę PCI SSC albo ocenę w ramach audytu każdego klienta z osobna.
6. Patronusec jako akredytowany QSA wspiera dostawców na całej ścieżce: od analizy luk, przez przygotowanie do walidacji, po wybór optymalnego wariantu (rozwiązanie, komponent, aplikacja).

---

---

Czym jest rozwiązanie P2PE (P2PE Solution)?

Rozwiązanie P2PE to kompletny zestaw sprzętu, oprogramowania, procesów i usług, który szyfruje dane kartowe w zatwierdzonym urządzeniu POI i deszyfruje je w bezpiecznym środowisku, oceniony według wszystkich 5 domen standardu PCI P2PE i wpisany na listę Validated P2PE Solutions. Odpowiedzialność za całość ponosi jeden podmiot: dostawca rozwiązania.

Standard PCI P2PE (aktualnie v3.2, cze 2025) definiuje dostawcę rozwiązania jako podmiot trzeci wobec merchantów (np. procesor, acquirer lub bramka płatnicza), który odpowiada za projekt i wdrożenie konkretnego rozwiązania oraz za spełnienie wszystkich wymogów P2PE – także tych realizowanych przez podwykonawców, takich jak urzędy certyfikacji czy zakłady wstrzykiwania kluczy. Wyjątkiem jest MMS (Merchant-Managed Solution), w którym merchant sam pełni rolę dostawcy dla własnych punktów akceptacji; PCI SSC nie publikuje listingów MMS.

Pięć domen standardu wyznacza zakres pełnej walidacji:

• Domena 1 – zarządzanie urządzeniami POI i zainstalowanym oprogramowaniem,
• Domena 2 – bezpieczeństwo aplikacji z dostępem do jawnych danych,
• Domena 3 – zarządzanie rozwiązaniem, relacjami z podwykonawcami i instrukcją PIM,
• Domena 4 – środowisko deszyfracji (w tym jego zgodność z PCI DSS),
• Domena 5 – operacje na kluczach kryptograficznych i zarządzanie urządzeniami SCD; wymogi tej domeny czerpią wprost z praktyk standardu PCI PIN Security Requirements (aktualnie v3.1, mar 2021).

Domena 3 jest jedyną domeną, której zgodnie ze standardem PCI P2PE nie wolno powierzyć trzeciej stronie ani dostawcy komponentu – zarządzanie rozwiązaniem musi wykonywać sam dostawca rozwiązania.

W praktyce oznacza to: nawet firma, która outsourcuje wstrzykiwanie kluczy, deszyfrację i zarządzanie terminalami, pozostaje właścicielem ryzyka. To ona podpisuje P-ROV, utrzymuje PIM dla merchantów i odpowiada przed PCI SSC za coroczne potwierdzenie statusu.

Czym jest komponent P2PE i jakie są typy komponentów?

Komponent P2PE to usługa pokrywająca wydzielony podzbiór wymogów standardu, świadczona na rzecz dostawców rozwiązań i walidowana samodzielnie, z wpisem na listę Validated P2PE Components. Dostawca rozwiązania, który korzysta z komponentu z listy, wykazuje w swoim P-ROV gotowy, zwalidowany element zamiast poddawać go ocenie od zera.

Model komponentowy wprowadziła wersja 2.0 standardu (cze 2015), a P2PE v3.0 (gru 2019) – jak podaje komunikat prasowy PCI SSC – podwoiła liczbę typów dostawców komponentów. Pełna lista typów (za P2PE Program Guide i szablonami P-ROV PCI SSC) obejmuje:

Typ komponentu	Skrót	Przykładowy zakres usługi
Encryption Management Services	EMS	Zarządzanie flotą urządzeń POI i oprogramowaniem na nich (Domena 1)
Decryption Management Services	DMS	Prowadzenie środowiska deszyfracji z HSM (Domena 4)
Key Injection Facility	KIF	Wstrzykiwanie kluczy kryptograficznych do terminali
Certification/Registration Authority	CA/RA	Operacje urzędu certyfikacji dla zdalnej dystrybucji kluczy
Key Management Component Provider	KMCP	Wydzielone operacje zarządzania kluczami (Domena 5)
Key Loading Component Provider	KLCP	Zdalne lub lokalne ładowanie kluczy do urządzeń
POI Deployment Component Provider	PDCP	Logistyka i wdrażanie terminali u merchantów
POI Management Component Provider	PMCP	Bieżące zarządzanie terminalami w terenie

Ważny szczegół techniczny z szablonu raportowego PCI SSC dla usług zarządzania kluczami: podmiot oceniany jako komponent danego typu nie może „domykać” własnych wymogów usługami innego komponentu tego samego typu z listy – przykładowo KIF w trakcie oceny nie spełni swoich wymogów, korzystając z innego, wpisanego na listę KIF.

Korzyść biznesowa modelu komponentowego działa w obie strony. Dostawca rozwiązania składa produkt z gotowych, zwalidowanych klocków i skraca własny audyt. Dostawca komponentu zdobywa natomiast pozycję na liście PCI SSC, którą może sprzedawać wielu dostawcom rozwiązań jednocześnie, zamiast przechodzić ocenę w ramach audytu każdego klienta z osobna.

Patronusec Insight: Z naszego doświadczenia projektowego wynika, że firmy świadczące usługi dla dostawców P2PE często zbyt późno orientują się, że mają wybór ścieżki. Standard dopuszcza dwie opcje: własny P-ROV i listing komponentu albo powtarzaną ocenę w audycie każdego klienta. Druga opcja wydaje się tańsza przy jednym kliencie, ale już przy dwóch-trzech dostawcach rozwiązań koszty wielokrotnych ocen i dostępności zespołu do audytów przewyższają koszt jednej walidacji komponentu. Warto policzyć próg opłacalności, zanim drugi klient poprosi o audyt.

Jakie czynności kwalifikują firmę jako dostawcę komponentu lub aplikacji P2PE?

Firma staje się kandydatem na dostawcę komponentu, gdy wykonuje na rzecz dostawcy rozwiązania P2PE dowolną funkcję objętą wymogami standardu: od wstrzykiwania kluczy, przez zarządzanie terminalami, po prowadzenie środowiska deszyfracji. Dostawcą aplikacji P2PE jest natomiast producent oprogramowania z dostępem do jawnych danych kartowych na urządzeniu POI.

Przykładowe czynności, które w praktyce podlegają pod poszczególne role:

• Ładowanie i zarządzanie kluczami: generowanie kluczy BDK, wstrzykiwanie kluczy do terminali w zabezpieczonym pomieszczeniu (KIF), zdalna dystrybucja kluczy technikami asymetrycznymi (CA/RA, KLCP), przechowywanie komponentów kluczy i zarządzanie kustoszami (KMCP).
• Obsługa floty terminali: konfigurowanie urządzeń POI przed wysyłką, aktualizacje firmware i aplikacji, prowadzenie inwentarza system buildów, wysyłka i logistyka urządzeń do merchantów (EMS, PDCP, PMCP).
• Deszyfracja: utrzymanie środowiska z HSM, w którym dane kartowe są odszyfrowywane i przekazywane do autoryzacji (DMS).
• Tworzenie oprogramowania na terminale: rozwój aplikacji płatniczej odczytującej dane karty, biblioteki SDK przetwarzającej PAN na urządzeniu POI, aplikacji drukującej pełny PAN na paragonie tam, gdzie wymaga tego prawo (dostawca aplikacji P2PE, Domena 2).

Granicę wyznacza dostęp do jawnych danych lub materiału kryptograficznego. Standard rozróżnia tu aplikację P2PE (dostęp do jawnych danych kartowych, pełna ocena wg Domeny 2) od oprogramowania niepłatniczego (np. aplikacja lojalnościowa na tym samym terminalu, bez dostępu do danych) – to drugie podlega wyłącznie wymogom 1C-2 z Domeny 1, weryfikującym brak interfejsów do danych i podpisywanie kodu pod podwójną kontrolą.

Zgodnie ze standardem PCI P2PE (v3.2) aplikacją P2PE jest każde oprogramowanie lub inne pliki z dostępem do jawnych danych kartowych, przeznaczone do załadowania na zatwierdzone urządzenie POI i użycia w ramach rozwiązania P2PE.

W praktyce oznacza to: jeżeli Twój produkt lub usługa dotyka jawnego PAN, SAD albo kluczy służących do ich ochrony w łańcuchu P2PE, jesteś w zakresie standardu – pytanie brzmi tylko, w której roli i według której ścieżki chcesz się walidować.

Czym jest aplikacja P2PE i kiedy podlega Domenie 2?

Aplikacja P2PE to oprogramowanie z dostępem do jawnych danych kartowych, instalowane na zatwierdzonym urządzeniu POI jako element rozwiązania P2PE. Każda taka aplikacja musi przejść ocenę według Domeny 2 standardu, zanim trafi do rozwiązania – niezależnie od tego, czy ocenę wykonano osobno, czy w ramach audytu rozwiązania.

Wymóg 1A-2 standardu stanowi, że aplikacje z dostępem do jawnych danych, które nie figurują na liście Validated P2PE Applications, muszą zostać ocenione według Domeny 2 w ramach walidacji rozwiązania. Ocena Domeny 2 jest wymagająca: obejmuje m.in. przegląd kodu źródłowego, testy z użyciem narzędzi śledczych, weryfikację, że aplikacja nie przechowuje PAN po zakończeniu transakcji ani SAD po autoryzacji, oraz że korzysta wyłącznie z mechanizmów odczytu danych zwalidowanych w ramach SRED urządzenia.

Istotna uwaga dla wytwórców oprogramowania: standard P2PE nie wymaga, aby aplikacja P2PE była walidowana według jakiegokolwiek innego standardu PCI. Ocena według PCI SSF (Secure Software Standard) nie zastępuje Domeny 2 – to odrębne programy o innym zakresie. Firmware terminala zatwierdzony w ramach oceny PCI PTS również nie jest aplikacją P2PE i nie podlega ponownej ocenie.

Obowiązkowym artefaktem dostawcy aplikacji jest Implementation Guide: przewodnik opisujący bezpieczną instalację, konfigurację, interfejsy logiczne i zasady zarządzania kluczami oraz certyfikatami. Dostawca rozwiązania ma obowiązek przekazywać aktualną wersję tego przewodnika integratorom i resellerom.

Czym różni się aplikacja oceniana w ramach rozwiązania od standalone certyfikacji?

Aplikacja P2PE oceniana w ramach rozwiązania jest ujęta w P-ROV konkretnego dostawcy rozwiązania i formalnie istnieje tylko w jego kontekście. Aplikacja walidowana standalone przechodzi tę samą ocenę Domeny 2, ale otrzymuje własny wpis na liście Validated P2PE Applications i może być wykorzystywana w wielu rozwiązaniach.

Standard wprost wskazuje, że aplikacje mogą być oceniane i wpisywane na listę PCI SSC „na przykład wtedy, gdy aplikacja może być używana w więcej niż jednym rozwiązaniu P2PE”. Różnice praktyczne:

Kryterium	Aplikacja w ramach rozwiązania	Aplikacja standalone (listing)
Zakres oceny	Domena 2 (pełna)	Domena 2 (pełna) – ta sama
Kto zamawia ocenę	Dostawca rozwiązania	Producent aplikacji
Wpis na listę PCI SSC	Brak (aplikacja widnieje w P-ROV rozwiązania)	Tak, na liście Validated P2PE Applications
Użycie w kolejnym rozwiązaniu	Wymaga ponownej oceny w audycie kolejnego rozwiązania	Kolejny dostawca powołuje się na listing (weryfikuje nazwę i wersję)
Kontrola producenta nad procesem	Ograniczona – zależy od harmonogramu klienta	Pełna – producent zarządza własnym cyklem walidacji
Kiedy się opłaca	Aplikacja pisana na potrzeby jednego rozwiązania	Aplikacja sprzedawana wielu dostawcom rozwiązań

Analogiczny mechanizm dotyczy zmian. Modyfikacja wpisanego na listę rozwiązania, komponentu lub aplikacji (np. dodanie nowego modelu terminala albo nowej wersji aplikacji) wymaga przejścia procesu delta assessment opisanego w P2PE Program Guide – ocenie podlega zmiana, nie całość od nowa. Program przewiduje też 3-letni cykl pełnej rewalidacji z corocznym potwierdzaniem statusu wobec PCI SSC (P2PE Program Guide). Aktualny P2PE v3.x Program Guide pochodzi z wrz 2024, a wydana w cze 2025 wersja 3.2 standardu nie unieważnia walidacji wykonanych wg v3.0 i v3.1 (PCI SSC).

Drzewo decyzyjne dla producenta oprogramowania na terminale:

1. Czy aplikacja ma dostęp do jawnych danych kartowych (PAN/SAD) na urządzeniu POI?
   • NIE → to oprogramowanie niepłatnicze; podlega tylko wymogom 1C-2 w audycie rozwiązania, w którym będzie użyte.
   • TAK → przejdź do pytania 2.
2. Czy aplikacja będzie używana w więcej niż jednym rozwiązaniu P2PE (lub sprzedawana różnym dostawcom)?
   • TAK → walidacja standalone i wpis na listę Validated P2PE Applications.
   • NIE → przejdź do pytania 3.
3. Czy zależy Ci na kontroli nad harmonogramem walidacji i argumencie sprzedażowym niezależnym od klienta?
   • TAK → standalone mimo jednego rozwiązania – listing ułatwi pozyskanie kolejnych klientów.
   • NIE → ocena w ramach P-ROV rozwiązania klienta wystarczy.

Jak wygląda proces walidacji i utrzymania listingu?

Proces walidacji przebiega tak samo dla rozwiązania, komponentu i aplikacji: ocenę wykonuje P2PE QSA, wynik dokumentuje w P-ROV według obowiązkowego szablonu PCI SSC, a Rada po akceptacji raportu publikuje wpis na właściwej liście. Różni się jedynie zakres ocenianych wymogów i użyty szablon raportu.

Typowa sekwencja z perspektywy dostawcy:

1. Klasyfikacja roli – ustalenie, czy walidujesz rozwiązanie, komponent (i którego typu), czy aplikację; od tego zależy zestaw wymogów i szablon P-ROV.
2. Analiza luk – porównanie stanu obecnego z wymogami przypisanych domen; na tym etapie wychodzą braki w rodzaju HSM bez wymaganych certyfikacji FIPS 140-2/140-3 poziom 3 czy procedur podwójnej kontroli przy podpisywaniu kodu.
3. Remediacja – wdrożenie brakujących kontroli; dla środowiska deszyfracji obejmuje to również doprowadzenie do zgodności z PCI DSS (aktualnie v4.0.1), której wymaga Domena 4.
4. Ocena P2PE QSA – audyt właściwy: przegląd dokumentacji, testy, wizyty w lokalizacjach (np. KIF), przegląd kodu dla aplikacji.
5. Akceptacja PCI SSC i listing – Rada weryfikuje P-ROV; po akceptacji rozwiązanie, komponent lub aplikacja trafia na publiczną listę.
6. Utrzymanie – coroczne potwierdzenie statusu, delta assessment przy zmianach, pełna rewalidacja co 3 lata; komponenty dodatkowo raportują status swoim dostawcom rozwiązań (wymogi 1E, 4E i 5I standardu).

Patronusec prowadzi dostawców przez pełen cykl certyfikacji PCI P2PE – od klasyfikacji roli i analizy luk po przygotowanie do oceny P2PE QSA.

Najczęstsze błędy praktyków

❌ Traktowanie oceny PTS urządzenia jako pokrycia dla oprogramowania – ocena PCI PTS obejmuje firmware, natomiast każde dodane później oprogramowanie z dostępem do danych wymaga osobnej oceny według Domeny 2.

❌ Próba outsourcingu Domeny 3 – zarządzania rozwiązaniem, relacji z podwykonawcami i PIM nie można przekazać komponentowi; standard rezerwuje tę domenę dla dostawcy rozwiązania.

❌ Zakładanie, że walidacja SSF lub dawna PA-DSS zastępuje Domenę 2 – standard P2PE nie uznaje walidacji aplikacji według innych programów PCI; Domena 2 ma własny, odrębny zakres.

❌ Pominięcie wymogu zgodności środowiska deszyfracji z PCI DSS – Domena 4 wymaga utrzymania zgodności PCI DSS w środowisku deszyfracji, co bywa największą pozycją kosztową całego projektu.

❌ Wprowadzanie zmian w zwalidowanym rozwiązaniu bez delta assessment – dodanie modelu terminala, wersji aplikacji lub nowego KIF poza procesem delta unieważnia spójność listingu z rzeczywistością i naraża merchantów na utratę prawa do SAQ P2PE.

❌ Mylenie oprogramowania niepłatniczego z aplikacją P2PE – aplikacja lojalnościowa bez dostępu do danych podlega tylko wymogom 1C-2, ale wymaga udokumentowanego potwierdzenia braku interfejsów do jawnych danych; deklaracja producenta nie wystarczy.

FAQ

---

Warto przeczytać

Ścieżka lektury dla dostawców budujących kompetencje P2PE:

1. P2PE – przewodnik po rozwiązaniach płatniczych – fundament: jak działa P2PE od strony architektury.
2. P2PE, E2EE i NESA – 3 podejścia do szyfrowania płatności – kontekst rynkowy: walidacja na tle alternatyw.
3. PCI Secure Software Framework (SSF) – kluczowy standard dla bezpieczeństwa oprogramowania płatniczego – jak wygląda walidacja oprogramowania poza terminalem.
4. Zakres certyfikacji PCI DSS – od czego zacząć i jak go określić – przydatne przy Domenie 4 (zgodność środowiska deszyfracji).
5. Ile kosztuje certyfikat bezpieczeństwa PCI – ekonomia formalnych ocen w ekosystemie PCI.

---

Walidacja P2PE dla dostawców – bezpłatna konsultacja

Patronusec jako akredytowany QSA wspiera dostawców rozwiązań, komponentów i aplikacji P2PE – od klasyfikacji roli po przygotowanie do oceny. Umów bezpłatną rozmowę scope-assessment, aby ustalić optymalną ścieżkę walidacji.

Umów konsultację | Analiza luk PCI | Certyfikacja PCI DSS