Il PCI Security Standards Council ha rilasciato la versione 2.0 del Secure Software Standard e la relativa Guida al programma, che rappresenta la revisione più significativa dall'inizio del framework nel 2019. Questo aggiornamento ridisegna radicalmente il modo in cui il software di pagamento viene valutato e convalidato, introducendo una nuova terminologia, un campo di applicazione ampliato e processi semplificati che avranno un impatto su fornitori, valutatori e clienti in tutto l'ecosistema dei pagamenti.
Forse il cambiamento più fondamentale della versione 2.0 è la completa eliminazione del termine "software di pagamento" dallo standard. I criteri di idoneità sono ora interamente incentrati sul concetto di Sensitive Assets, definitocome qualsiasi elemento del prodotto software il cui accesso, uso, modifica o divulgazione non autorizzati possono compromettere le funzionalità o i dati relativi ai pagamenti del software.
Questa riformulazione concettuale è accompagnata da un nuovo documento obbligatorio, il Sensitive Asset Identification (SAID), che fornisce un contesto dettagliato ed esempi per l'identificazione di dati, funzionalità, risorse e modalità operative sensibili. Per i dati EMVCo 3DS, lo standard fa ora riferimento al documento PCI 3DS Data Matrix.
L'implicazione pratica è chiara: se il vostro software gestisce risorse sensibili secondo la definizione dello standard, rientra nell'ambito di applicazione, indipendentemente dal fatto che rientri nelle categorie tradizionali del software di pagamento.
La versione 2.0 introduce significativi aggiornamenti terminologici che valutatori e venditori devono interiorizzare:
Inoltre, il glossario è stato trasferito da un documento SSF esterno all'Appendice A dello standard stesso, e i termini definiti sono ora contrassegnati in tutti i requisiti di sicurezza per facilitarne il riconoscimento. È stato introdotto un nuovo termine, "Strong Authentication" e lo standard si basa ora sulla base di "Strong Cryptography" piuttosto che su specifici parametri di forza effettiva delle chiavi.
Lo standard v2.0 è stato interamente ristrutturato attorno a undici Obiettivi di sicurezza nella sezione Core, che si applica a tutto il software valutato nell'ambito del framework:
I requisiti sono stati rivisti per concentrarsi esclusivamente su PAN e SAD in relazione agli standard PCI DSS, con un contesto aggiuntivo fornito nel documento SAID.
Rinominato da "Requisiti del software del terminale", questo modulo è stato notevolmente semplificato. Molti requisiti (B1.1, B1.2, B1.3, B3.x, B5.x) sono stati assorbiti nei requisiti Core e i requisiti SRED sono stati rivisti.
Rinominato da "Requisiti per il software web" per meglio cogliere il suo intento. Il chiarimento dell'ambito è significativo: questo modulo riguarda il software accessibile su reti pubbliche in cui essenzialmente chiunque abbia accesso alla rete può interagire con il software. È importante notare che il software non accessibile pubblicamente può comunque essere valutato in base a questo modulo a discrezione del fornitore, in quanto i requisiti contribuiscono a ridurre il rischio per qualsiasi implementazione.
Questo modulo completamente nuovo consente di valutare gli SDK, compresi gli SDK EMVCo 3DS. Lo standard afferma esplicitamente che la versione 2.0 sostituirà lo standard SDK PCI 3DS separato, offrendo ai fornitori una maggiore flessibilità grazie alla natura più oggettiva dello standard Secure Software.
Le precedenti categorie di modifiche "a basso impatto" e "ad alto impatto" sono state sostituite da una struttura con modifiche Delta di livello 1 e 2 :
Il versioning dei caratteri jolly è stato formalmente reintrodotto con regole chiare:
Questa formalizzazione consente ai fornitori di gestire le versioni minori senza presentare le modifiche a PCI SSC, a condizione che l'uso dei caratteri jolly sia convalidato durante la Valutazione completa.
La versione 2.0 rende esplicito ciò che prima era implicito: lafornitura del codice sorgente di è obbligatoria. La Guida al programma afferma inequivocabilmente che:
"Il fornitore di software è tenuto a fornire il codice sorgente del proprio prodotto software da valutare, come ritenuto necessario dal valutatore che esegue la valutazione". Non è possibile far valutare un prodotto software secondo questo standard senza fornire il relativo codice sorgente".
I requisiti di prova sono stati completamente riscritti in base a tre metodi:
Il ciclo di vita di convalida di 3 anni rimane intatto:
Chiarimenti chiave nella v2.0:
La versione 2.0 introduce una sezione dedicata Sezione 8 per la notifica dei problemi di sicurezza, formalizzando:
PCI Secure Software Standard v2.0 rappresenta una maturazione del framework, passando da categorie prescrittive di software di pagamento a un approccio basato su principi incentrati sulla protezione delle risorse sensibili. L'inclusione di funzionalità di valutazione degli SDK, la formalizzazione delle versioni wildcard e il sistema di modifiche delta a livelli puntano a un programma di convalida più flessibile e sostenibile.
Per le organizzazioni attualmente in possesso di convalide v1.x o che stanno pianificando nuove valutazioni, è il momento di rivolgersi a società di valutazione SSF qualificate per comprendere il percorso di transizione e sfruttare la maggiore flessibilità offerta da questa importante revisione.
Lo Standard PCI Secure Software v2.0 e la Guida al programma v2.0 entrano in vigore a gennaio 2026. Le organizzazioni devono consultare la documentazione ufficiale di PCI SSC e i valutatori qualificati per ottenere indicazioni specifiche sulla conformità.