Czym różni się PCI SSF v2.0 od v1.2.1? PCI Secure Software Standard v2.0, opublikowany 15 sty 2026, to pierwsza pełna rewizja standardu: przenosi punkt ciężkości z aplikacji płatniczej na identyfikację i ochronę aktywów wrażliwych, wprowadza nowy dokument towarzyszący SAID, upraszcza strukturę i zmienia proces zmian delta. Wersja 1.2.1 pozostaje ważna do końca 12-miesięcznego okna przejściowego liczonego od udostępnienia szkoleń.
Definicja kanoniczna: PCI Secure Software Standard to jeden z dwóch standardów ramy PCI Software Security Framework (SSF), określający wymogi bezpiecznego projektowania, tworzenia i utrzymania oprogramowania płatniczego, walidowany przez asesorów Secure Software.
Dla vendora oprogramowania płatniczego to zmiana, którą trzeba zaplanować teraz – od niej zależy zakres kolejnej walidacji i termin przejścia na nowy standard.
PCI SSF v2.0 a v1.2.1 – w skrócie:
- PCI Secure Software Standard v2.0 opublikowano 15 sty 2026; to pierwsza pełna rewizja od wprowadzenia standardu (blog PCI SSC).
- Nowy punkt ciężkości: standard nie skupia się już przede wszystkim na aplikacji płatniczej, lecz na identyfikacji i ochronie aktywów wrażliwych (sensitive assets), wspieranej nowym dokumentem SAID (Sensitive Asset Identification).
- Zmieniono strukturę i terminologię standardu oraz zredukowano nakładanie się z drugim standardem ramy – PCI Secure Software Lifecycle (SLC).
- Zaktualizowano proces zmian delta z nowym szablonem Change Impact oraz wprowadzono wildcardy dla zmian oprogramowania niewpływających na bezpieczeństwo (blog PCI SSC).
- Szablony v2.x (ROV, AOV, Change Impact) oczekiwane były na początku lutego 2026, szkolenie CBT w I kw. 2026; po udostępnieniu szkoleń startuje 12-miesięczne okno przejścia z v1.2.1 na v2.0.
- Patronusec jako akredytowany QSA wspiera dostawców oprogramowania płatniczego w przygotowaniu do walidacji SSF – od identyfikacji aktywów wrażliwych po przejście na v2.0.
Spis treści
Czym jest PCI Software Security Framework i standard Secure Software?
PCI Software Security Framework (SSF) to rama zastępująca dawny standard PA-DSS, złożona z dwóch standardów: Secure Software Standard (walidacja konkretnego oprogramowania) i Secure Software Lifecycle Standard (walidacja procesu wytwórczego vendora). Dotyczy zewnętrznych dostawców oprogramowania płatniczego sprzedawanego merchantom i dostawcom usług.
PCI SSF powstał, aby zastąpić PA-DSS elastyczniejszym podejściem, obsługującym różne typy oprogramowania płatniczego, technologie i metodyki wytwórcze. Program PA-DSS wygaszono: nowych zgłoszeń nie przyjmowano po 30 cze 2021, a wsparcie programu zakończyło się 30 paź 2022. Od tego czasu walidacja oprogramowania płatniczego odbywa się w ramach SSF.
Rozróżnienie dwóch standardów ramy jest kluczowe dla vendora:
- Secure Software Standard (SSS) – waliduje konkretny produkt: czy oprogramowanie jest zaprojektowane, tworzone i utrzymywane tak, by chronić transakcje i dane, minimalizować podatności i bronić się przed atakami. Efektem jest wpis produktu na listę Validated Payment Software.
- Secure Software Lifecycle Standard (SLC) – waliduje proces vendora: praktyki bezpiecznego cyklu wytwórczego, które pozwalają utrzymywać bezpieczeństwo oprogramowania w czasie i zarządzać zmianami.
PCI SSF zastąpił model PA-DSS opartej na sztywnej liście kontroli podejściem opartym na celach bezpieczeństwa – vendor wykazuje, jak spełnia cel, zamiast odhaczać predefiniowaną listę wymogów.
Co dokładnie zmienia wersja 2.0 względem 1.2.1?
Wersja 2.0 to pierwsza pełna rewizja Secure Software Standard: przebudowuje strukturę, przenosi punkt ciężkości na aktywa wrażliwe, redukuje nakładanie się z SLC i modernizuje proces zmian. Wersja 1.2.1 była ostatnią z linii 1.x, do której wcześniej (w 1.2) dodano Web Software Module.
Najważniejsze zmiany według bloga PCI SSC i komunikatów Rady:
- Nowy nacisk na aktywa wrażliwe (sensitive assets). Standard nie skupia się już przede wszystkim na aplikacji płatniczej, lecz na identyfikacji i ochronie aktywów wrażliwych – dowolnych elementów produktu, których nieuprawniony dostęp, użycie lub modyfikacja mogą naruszyć bezpieczeństwo. Wspiera to nowy dokument towarzyszący SAID (Sensitive Asset Identification).
- Przebudowana struktura i terminologia. Wymogi zreorganizowano dla łatwiejszej nawigacji, a terminologię ujednolicono; zredukowano też nakładanie się z drugim standardem ramy (SLC).
- Zmodernizowany proces zmian delta. Nowy szablon Change Impact oraz wprowadzenie wildcardów pozwalających uwzględnić zmiany oprogramowania niewpływające na bezpieczeństwo – to bezpośrednio dotyka codziennego utrzymania listingu.
- Usprawnienia portalu i listingu. Dostęp do portalu do składania rocznych atestacji i zmian administracyjnych przez vendora oraz ulepszone funkcje portalu i listy.
- Powiązanie z 3DS. Przy okazji transformacji zaktualizowano PCI 3DS Data Matrix do wersji 1.2, uwzględniającej elementy danych wrażliwych 3DS SDK.
Najgłębsza zmiana w SSF v2.0 nie dotyczy pojedynczego wymogu, lecz filozofii zakresu: v1.2.1 pytała „jak chronisz aplikację płatniczą”, a v2.0 pyta „jakie aktywa wrażliwe masz w produkcie i jak każdy z nich chronisz”.
Jak zmiana punktu ciężkości na aktywa wrażliwe wpływa na vendora?
Przeniesienie punktu ciężkości na aktywa wrażliwe oznacza, że vendor najpierw identyfikuje i dokumentuje wszystkie aktywa wymagające ochrony, a dopiero potem dobiera do nich kontrole – zamiast spełniać listę wymogów przypisanych z góry do aplikacji płatniczej. To zmiana metodyczna, nie kosmetyczna.
Aktyw wrażliwy w rozumieniu standardu to dowolny element produktu (włącznie z samym produktem), którego nieuprawniony dostęp, użycie lub modyfikacja mogą naruszyć bezpieczeństwo. Nowy dokument SAID wspiera vendorów w identyfikacji i dokumentowaniu takich aktywów – staje się punktem wyjścia całej walidacji.
Praktyczne konsekwencje dla dostawcy:
- Inny punkt startowy walidacji. Zamiast od listy kontroli, projekt zaczyna się od inwentaryzacji aktywów wrażliwych – klucze, dane uwierzytelniające, logika bezpieczeństwa, sam kod krytyczny.
- Szersza definicja zakresu. Podejście oparte na aktywach może objąć elementy, których model „aplikacji płatniczej” wprost nie adresował – to szansa na precyzję, ale i ryzyko niedoszacowania zakresu przy pobieżnej identyfikacji.
- Więcej odpowiedzialności po stronie vendora. Vendor sam wykazuje, jakie ma aktywa i jak je chroni, zamiast odhaczać predefiniowaną listę – co nagradza dojrzałe zespoły, a obnaża improwizację.
W praktyce oznacza to: pierwszym zadaniem w projekcie SSF v2.0 nie jest już przegląd kontroli, lecz rzetelna, udokumentowana identyfikacja aktywów wrażliwych – i to ona zdeterminuje zakres oraz koszt walidacji.
Twoje oprogramowanie jest walidowane na SSF v1.2.1 i nie wiesz, jak przygotować się do v2.0?
Patronusec wykonuje przegląd gotowości do SSF v2.0: identyfikujemy aktywa wrażliwe Twojego produktu według podejścia SAID, mapujemy je na istniejące kontrole i wskazujemy luki względem nowej struktury standardu. W ciągu 10 dni roboczych otrzymujesz pisemny raport gotowości i plan przejścia.
Zamów przegląd gotowości do SSF v2.0
Jak wygląda okno przejściowe i harmonogram wdrożenia v2.0?
Po udostępnieniu szkoleń dla asesorów startuje 12-miesięczne okno przejściowe, w którym vendorzy mogą walidować się jeszcze według v1.2.1 albo już według v2.0. Standard v2.0 opublikowano 15 sty 2026, a materiały wspierające udostępniano etapami w I-II kw. 2026.
Harmonogram według komunikatów PCI SSC:
- 15 sty 2026 – publikacja PCI Secure Software Standard v2.0 w bibliotece dokumentów PCI SSC.
- początek lutego 2026 – oczekiwane udostępnienie szablonów v2.x: ROV (Report on Validation), AOV (Attestation of Validation) oraz nowego Change Impact.
- I kw. 2026 – oczekiwane szkolenie CBT (computer-based training) v2.0 dla dotychczasowych asesorów Secure Software; szkolenia stacjonarne (ILT) dla nowych asesorów planowane na II kw.
- start okna przejściowego – 12-miesięczny okres przejścia z v1.2.1 na v2.0 rozpoczyna się po udostępnieniu szkoleń.
Dla vendora oznacza to okno decyzyjne, nie natychmiastowy przymus. Produkt walidowany na v1.2.1 zachowuje ważność zgodnie z zasadami programu, ale kolejna walidacja i utrzymanie listingu przesuną się na v2.0. Decyzję, czy zdążyć jeszcze z walidacją na v1.2.1, czy od razu przygotować się do v2.0, warto podjąć na podstawie cyklu życia produktu i terminu następnej walidacji, a nie odkładać do końca okna.
Okno przejściowe SSF to nie odroczenie obowiązku, lecz okno decyzyjne: vendor wybiera moment przejścia na v2.0 w granicach 12 miesięcy od udostępnienia szkoleń, dopasowując go do własnego cyklu walidacji.
Co dostawca oprogramowania powinien zrobić już teraz?
Vendor powinien już teraz zidentyfikować aktywa wrażliwe swojego produktu, porównać obecne kontrole z nową strukturą v2.0 i zaplanować moment przejścia w oknie 12 miesięcy. Wczesne przygotowanie zamienia zmianę standardu z ryzyka w uporządkowany projekt.
Checklist przygotowania do v2.0:
- Zidentyfikuj aktywa wrażliwe według podejścia SAID – to punkt wyjścia całej walidacji v2.0, a nie zadanie na koniec projektu.
- Zmapuj obecne kontrole na nową strukturę – sprawdź, gdzie wymogi v1.2.1 przekładają się wprost na v2.0, a gdzie zmiana filozofii wymaga nowego dowodu.
- Przejrzyj proces zmian delta – dostosuj go do nowego szablonu Change Impact i mechanizmu wildcardów dla zmian niewpływających na bezpieczeństwo.
- Ustal moment przejścia – zderz termin następnej walidacji i cykl życia produktu z 12-miesięcznym oknem, zamiast czekać na jego koniec.
- Zweryfikuj relację z SLC – sprawdź, czy redukcja nakładania się standardów zmienia zakres Twojej walidacji procesu wytwórczego.
- Zaplanuj dowody – identyfikacja aktywów i podejście oparte na celach wymagają innej dokumentacji niż odhaczanie listy kontroli z v1.2.1.
Patronusec wspiera dostawców oprogramowania płatniczego w tym przejściu w ramach usługi audytu i przygotowania do PCI SSF – od identyfikacji aktywów wrażliwych po plan przejścia dopasowany do cyklu walidacji produktu.
FAQ – PCI SSF v2.0
Kiedy przestanie obowiązywać PCI SSF v1.2.1?
Wersja 1.2.1 pozostaje ważna do końca 12-miesięcznego okna przejściowego, które startuje po udostępnieniu szkoleń dla asesorów v2.0. Standard v2.0 opublikowano 15 sty 2026, a szkolenia i szablony udostępniano etapami w I-II kw. 2026. Produkty walidowane na v1.2.1 zachowują ważność zgodnie z zasadami programu.
Czy walidacja na v1.2.1 traci ważność po wydaniu v2.0?
Nie automatycznie. Produkt walidowany na v1.2.1 zachowuje ważność zgodnie z zasadami programu przez okno przejściowe. Na v2.0 przechodzi się przy kolejnej walidacji lub istotnej zmianie wymagającej ponownej oceny. Decyzję o momencie przejścia warto podjąć na podstawie cyklu życia produktu.
Czym jest SAID w PCI SSF v2.0?
SAID (Sensitive Asset Identification) to nowy dokument towarzyszący standardowi v2.0, który wspiera vendorów w identyfikacji i dokumentowaniu aktywów wrażliwych. Aktyw wrażliwy to dowolny element produktu, którego nieuprawniony dostęp, użycie lub modyfikacja mogą naruszyć bezpieczeństwo. SAID staje się punktem wyjścia walidacji v2.0.
Czy PCI SSF dotyczy oprogramowania tworzonego na własny użytek?
Nie. PCI SSF dotyczy zewnętrznych dostawców oprogramowania płatniczego sprzedawanego merchantom i dostawcom usług. Oprogramowanie tworzone przez merchanta lub dostawcę usług na własny, wewnętrzny użytek nie podlega walidacji SSF – choć samo środowisko przetwarzania danych kartowych nadal podlega PCI DSS.
Czym różni się Secure Software Standard od Secure Software Lifecycle?
Secure Software Standard (SSS) waliduje konkretny produkt – jego bezpieczeństwo i integralność. Secure Software Lifecycle (SLC) waliduje proces wytwórczy vendora – praktyki bezpiecznego cyklu życia oprogramowania. To dwa odrębne standardy ramy SSF; wersja 2.0 SSS zredukowała nakładanie się z SLC dla jaśniejszego podziału zakresów.
Ile trwa przygotowanie do walidacji SSF z Patronusec?
Czas zależy od typu oprogramowania, liczby aktywów wrażliwych i stanu dokumentacji oraz od tego, czy walidujesz się po raz pierwszy, czy przechodzisz z v1.2.1 na v2.0. Po bezpłatnej rozmowie scope-assessment przedstawiamy stałą wycenę obejmującą identyfikację aktywów, analizę luk i przygotowanie do walidacji.
Warto przeczytać
Ścieżka lektury dla tematu bezpieczeństwa oprogramowania płatniczego:
- PCI Secure Software Framework (SSF) – kluczowy standard dla bezpieczeństwa oprogramowania płatniczego – fundament: czym jest rama SSF i jej dwa standardy.
- Komponent P2PE, rozwiązanie P2PE i aplikacja P2PE – dlaczego walidacja aplikacji P2PE nie zastępuje SSF.
- Czym jest 3DS SDK – wymogi i zastosowania – oprogramowanie płatnicze na urządzeniu i jego odrębne standardy.
- Zakres certyfikacji PCI DSS – od czego zacząć i jak go określić – relacja oprogramowania płatniczego do środowiska CDE.
PCI SSF v2.0 – bezpłatna konsultacja
Patronusec jako akredytowany QSA wspiera dostawców oprogramowania płatniczego w walidacji PCI SSF – pracujemy z klientami z sektorów fintech, e-commerce i finansowego. W bezpłatnej 30-minutowej konsultacji pomożemy Ci:
- zidentyfikować aktywa wrażliwe Twojego produktu według podejścia SAID,
- zmapować obecne kontrole z v1.2.1 na nową strukturę v2.0,
- ustalić optymalny moment przejścia w 12-miesięcznym oknie,
- zaplanować dowody i dokumentację pod podejście oparte na aktywach.
Umów konsultację | Audyt PCI SSF | PCI SLC | Certyfikacja PCI DSS | Analiza luk PCI
