PCI DSS

PCI DSS v4: Cosa Cambia Davvero per i Merchant nel 2025

10 febbraio 2025 6 min di lettura PCI Proxy EU

Il 31 marzo 2025 è la data che ha reso obbligatori tutti i pci dss v4 requirements precedentemente etichettati come "future-dated". Per molti merchant italiani ed europei questa scadenza è passata in secondo piano, ma le conseguenze pratiche sono concrete. I nuovi obblighi modificano come vanno gestiti i pagamenti online, i call center e qualsiasi sistema che interagisce con dati carta. La tokenizzazione rimane il modo più efficace per assorbire questi cambiamenti senza riprogettare l'intera infrastruttura.

PCI DSS v4: Cosa Cambia Davvero per i Merchant nel 2025

I requisiti v4 diventati obbligatori nel 2025

I requisiti "future-dated" del PCI DSS v4 che sono diventati obbligatori a marzo 2025 toccano aree specifiche e ad alto impatto operativo. Il requisito 6.4.3 richiede un inventario documentato di tutti gli script JavaScript presenti nelle pagine di pagamento, con meccanismi per verificarne l'integrità. Questo nasce dalla risposta agli attacchi e-skimming che hanno colpito migliaia di siti ecommerce negli anni precedenti. Il requisito 11.6.1 aggiunge il monitoraggio continuo delle pagine di pagamento per rilevare modifiche non autorizzate agli script e agli header HTTP.

Sul fronte dell'autenticazione, il requisito 8.4.2 estende l'obbligo di MFA a tutti gli accessi al CDE, compresi quelli da reti interne. Nel v3.2.1 la MFA era richiesta principalmente per gli accessi remoti. Questa estensione ha un impatto diretto sulle politiche di accesso ai sistemi di pagamento interni e sugli strumenti di amministrazione. I merchant che gestiscono sistemi propri in cui transitano dati carta devono rivedere le proprie politiche di autenticazione per essere allineati.

L'impatto pratico sui merchant ecommerce e MOTO

Per i merchant ecommerce il requisito più impattante è il 6.4.3 sugli script. Se il sito di pagamento carica librerie JavaScript di terze parti, CSS esterni o pixel di tracking, ciascuno di questi elementi deve essere censito e monitorato per l'integrità. Questo vale anche per gli script di provider come Google Analytics o Meta Pixel se presenti sulla pagina di checkout. Molti merchant scoprono di avere decine di dipendenze esterne non documentate che richiedono una revisione completa del loro checkout.

Per i merchant MOTO (Mail Order/Telephone Order), i nuovi requisiti di MFA impattano sulle postazioni degli operatori di call center che inseriscono dati carta. Ogni accesso al sistema che gestisce i PAN deve ora essere protetto da autenticazione multi-fattore. Questo spesso richiede un aggiornamento delle piattaforme di gestione degli ordini telefonici e una revisione delle procedure operative degli agenti. La soluzione più diretta è rimuovere completamente i dati carta dall'ambiente del call center usando tecnologie di mascheramento o tokenizzazione real-time.

Come la tokenizzazione assorbe i nuovi requisiti

La tokenizzazione con un provider certificato PCI DSS Level 1 elimina alla radice molti dei problemi creati dai nuovi requisiti v4. Se i dati carta non entrano mai nell'ambiente del merchant, il requisito 6.4.3 sugli script si applica a un perimetro molto ridotto o non si applica affatto, a seconda dell'architettura del checkout. Con un hosted payment page o un form di tokenizzazione gestito dal provider, le pagine di pagamento del merchant non contengono script che elaborano dati carta, eliminando gran parte dell'obbligo di monitoraggio.

Allo stesso modo, l'estensione dell'obbligo di MFA al CDE perde di rilevanza pratica se il CDE stesso è ridotto al minimo o eliminato dall'infrastruttura del merchant. Un merchant con architettura SAQ A non ha sistemi propri che memorizzano, trasmettono o elaborano dati carta: il suo perimetro di compliance è limitato e i nuovi requisiti v4 più onerosi non si applicano. Questo rende la riduzione del scope la strategia di adeguamento al v4 più conveniente sia in termini di costi immediati sia di oneri ricorrenti.

Domande frequenti

Il mio acquirer mi chiederà il PCI DSS v4 subito?

Dipende dall'acquirer e dal contratto in essere. Molti acquirer europei stanno già aggiornando i processi di onboarding e rinnovo per richiedere SAQ conformi al v4. Se hai un rinnovo annuale imminente, verifica con il tuo acquirer quale versione del questionario è richiesta. Non aspettare che sia lui a segnalare la non conformità: il rischio di sanzioni contrattuali è reale.

Devo rifare il SAQ con PCI DSS v4?

Sì, il prossimo SAQ che compili deve essere basato sui template v4. I modelli SAQ aggiornati sono disponibili sul sito del PCI Security Standards Council. Il tipo di SAQ (A, A-EP, B, D, ecc.) dipende dalla tua architettura di accettazione dei pagamenti, non dallo standard: se usi già tokenizzazione con hosted fields, potresti già qualificarti per il SAQ A più semplice.

I requisiti v4 si applicano anche ai merchant di Livello 4?

Sì. I merchant di Livello 4 (meno di 20.000 transazioni ecommerce annue o fino a 1 milione di transazioni di qualsiasi tipo) sono comunque soggetti al PCI DSS v4. La differenza rispetto ai livelli superiori riguarda il metodo di validazione (SAQ invece di ROC), non l'applicabilità dello standard. I nuovi requisiti v4 si applicano a tutti i merchant che accettano carte dei principali circuiti.

Conformità PCI DSS v4 senza riprogettare l'infrastruttura: la tokenizzazione è il percorso più rapido per la maggior parte dei merchant. Scopri PCI Proxy EU.

PCI Proxy EU Team

RoxPay, tokenizzazione PCI DSS in Europa

Contenuti rivisti da esperti in pagamenti e conformità PCI DSS.

Conformità PCI DSS v4 senza riprogettare l'infrastruttura

Tokenizzazione certificata Level 1: riduci il perimetro e assorbi i nuovi requisiti v4 con una sola integrazione.