PCI DSS 4.0

PCI DSS protège les données du titulaire: numéro de carte, expiration, nom et données d’authentification associées. Elle oblige toute entité les stockant, traitant ou transmettant, dont commerçants, acquéreurs, processeurs, facilitateurs et prestataires intermédiaires, et s’étend aussi aux systèmes connectés.

PCI DSS n’est pas une loi, aucun superviseur n’inflige d’amende PCI et l’obligation provient du contrat d’acceptation. Le Conseil précise que les validations requises dépendent de l’entité imposant la conformité, soit réseau, acquéreur ou facilitateur, expliquant des exigences de preuve différentes pour deux commerçants de taille similaire. Finance Loop traite les obligations réglementaires voisines dans DORA en Allemagne.

La version 4.0 conserve douze domaines d’exigences mais modifie leur mise en œuvre. L’ajout majeur est l’approche personnalisée: au lieu d’appliquer le contrôle prescrit, une organisation peut atteindre l’objectif à sa façon, documenter pourquoi sa méthode y parvient et faire valider ce raisonnement par un évaluateur. Cette voie exige davantage de travail et s’adresse aux équipes sécurité matures dont les contrôles existants ne correspondent pas au libellé prescrit.

Le reste renforce l’importance des preuves plutôt que des affirmations. Les exigences d’authentification se durcissent, notamment l’accès multifacteur à l’environnement des données de carte. Plusieurs contrôles nécessitent désormais une analyse ciblée déterminant la fréquence d’une activité selon l’évaluation des risques propre à l’organisation plutôt qu’un intervalle fixe. La version 4.0.1, révision de maintenance corrigeant et précisant 4.0, est celle à citer.

Deux exigences sont entrées en vigueur le 31 mars 2025 après transition et concernent le navigateur. L’exigence 6.4.3 couvre les scripts chargés sur une page de paiement: inventaire, justification commerciale écrite, autorisation explicite d’une partie désignée et vérification continue de l’intégrité, y compris pour les scripts tiers. L’exigence 11.6.1 demande un mécanisme détectant toute modification non autorisée de la page reçue par le navigateur du consommateur. L’exigence 12.3.1 couvre l’analyse ciblée des risques soutenant l’exigence 11.6.1.

Un script injecté dans la page de paiement, souvent via un gestionnaire de balises ou un fournisseur analytique, lit le numéro saisi et l’envoie ailleurs, sans anomalie visible sur le serveur marchand. Toute balise marketing ou analytique sur une page collectant des données de carte relève donc de 6.4.3.

Le questionnaire le plus court a été remanié le même mois. Le Conseil a retiré les exigences 6.4.3, 11.6.1 et 12.3.1 du SAQ A et ajouté un critère d’éligibilité: le commerçant doit confirmer que son site ne peut subir d’attaques par scripts affectant ses systèmes de commerce en ligne. La version de janvier 2025 s’applique depuis le 31 mars 2025, date du retrait de celle d’octobre 2024.

Les trois exigences quittent le questionnaire mais restent dans la norme, donc applicables au SAQ D ou à l’évaluation sur place, et le nouveau critère demande d’attester le même résultat. Le guide d’éligibilité de Adyen précise l’autre condition SAQ A: chaque élément de page et formulaire transmis au navigateur doit provenir uniquement et directement d’un prestataire ou processeur tiers conforme.

La réponse dépend de l’intégration et non de la taille commerciale. Une page redirigeant le client vers le prestataire ou intégrant son iframe maintient le numéro hors de la page marchande et oriente vers SAQ A. Une page marchande collectant la carte dans ses champs et la transmettant, même sans stockage, relève du questionnaire SAQ A-EP, bien plus long. Un commerçant stockant des numéros ou les traitant sur ses systèmes relève du SAQ D.

Le volume transactionnel détermine les preuves, mais pas les questions. Les réseaux classent les commerçants selon leurs transactions annuelles, le niveau supérieur exigeant une évaluation sur place par un évaluateur de sécurité qualifié plutôt qu’une autoévaluation. Demandez par écrit à votre acquéreur votre niveau et le questionnaire attendu, car ces deux paramètres déterminent le coût de l’exercice.

Si les champs contrôlés et fournis par le prestataire capturent le numéro et que votre système ne reçoit qu’un jeton, bases, journaux, sauvegardes et outils d’assistance ne détiennent aucune donnée de carte et sortent de l’évaluation.

Une page hébergeant les champs du prestataire mais chargeant aussi ses propres scripts les réintègre au périmètre, précisément visé par 6.4.3. Un jeton n’est pas automatiquement hors périmètre: si le commerçant possède un élément réversible en numéro ou les clés correspondantes, les données restent présentes. Finance Loop traite les coffres dans l’orchestration des paiements et l’acquisition dans l’acquisition commerçant.

Un établissement de paiement allemand répond désormais aux deux cadres, qui interrogent différemment les mêmes systèmes. PCI DSS protège un type de données dans son environnement, et son application relève d’une contrepartie contractuelle. DORA encadre la résilience opérationnelle de toute l’entreprise réglementée, sous contrôle de BaFin.

Le recoupement est pratique, sans constituer une équivalence juridique directe. Inventaires, vulnérabilités, contrôle d’accès, incidents et surveillance des tiers figurent dans les deux, permettant de produire une fois et présenter deux fois les preuves avec une documentation adaptée. Deux éléments ne se transfèrent pas: DORA impose des notifications au superviseur dans des délais réglementaires, et le périmètre PCI est plus étroit, donc un programme DORA ne démontre pas la conformité PCI de l’environnement des cartes. Finance Loop présente la résilience dans DORA en Allemagne et le domaine général dans la cybersécurité financière.

Aucune différence substantielle, la version 4.0.1 étant une révision limitée corrigeant des erreurs et précisant les libellés de 4.0, sans nouvelle exigence ni changement de date. Une organisation visant 4.0 vise aussi 4.0.1, et 4.0.1 est la version à nommer dans tout document ou contrat.

Non, les réseaux de cartes fixent la norme, appliquée contractuellement, avec des conséquences commerciales: demandes de preuves, amendes répercutées par l’acquéreur et, dans les cas graves, perte de l’acceptation des cartes. Une violation de données de carte déclenche aussi des obligations légales, dont la notification RGPD, produisant deux procédures distinctes.