PCI DSS

01 — DéfinitionQu'est-ce que PCI DSS ?

Source officielle : site officiel PCI Security Standards Council.

PCI DSS (Payment Card Industry Data Security Standard) est le standard de sécurité mondial des données de cartes bancaires. Il impose un ensemble d'exigences techniques et organisationnelles à toute entité qui stocke, traite ou transmet des données de cartes de paiement, afin de les protéger contre la fraude et les violations.

Le standard est maintenu par le PCI Security Standards Council, fondé en 2006 à l'initiative des principaux réseaux de cartes bancaires : Visa, Mastercard, American Express, Discover et JCB. Ces réseaux imposent le respect de PCI DSS via les accords contractuels qui lient les banques acquéreuses, les prestataires de services et les commerçants.

Historique des versions :

• PCI DSS 1.0 (2004) — initialement indépendant pour chaque réseau (Visa AIS, Mastercard SDP).
• Unification en 2006 avec la création du PCI SSC.
• PCI DSS 3.0 (2013) — refonte majeure.
• PCI DSS 3.2.1 (2018) — version longtemps utilisée, retirée en mars 2024.
• PCI DSS 4.0 (mars 2022) — refonte profonde, transition progressive.
• PCI DSS 4.0.1 (juin 2024) — version actuelle, clarifications et corrections.

PCI DSS n'est pas une loi au sens strict — c'est un standard contractuel imposé par l'industrie des cartes. Mais dans la pratique, il s'impose à tous les acteurs du paiement par carte avec une force contraignante équivalente à une réglementation : les commerçants qui ne sont pas conformes peuvent voir leur capacité d'accepter les cartes interrompue par leur banque acquéreuse.

PCI DSS est souvent décrié pour sa complexité et son coût, mais son impact sur la sécurisation de l'écosystème des paiements est indéniable. Depuis son adoption massive, la part de la fraude due à la compromission directe des commerçants a diminué significativement, les attaquants s'étant tournés vers d'autres vecteurs (phishing, account takeover, fraude sans présence de carte).

02 — PérimètreDonnées et acteurs concernés

Données carte concernées

PCI DSS distingue deux catégories de données :

Cardholder Data (données de titulaire)

• PAN (Primary Account Number) : numéro de carte 13-19 chiffres. Donnée la plus sensible. Peut être stockée sous conditions strictes (chiffrement, tokenization).
• Nom du titulaire, date d'expiration, code service : considérées comme cardholder data quand associées au PAN.

Sensitive Authentication Data (données d'authentification)

• CVV / CVC / CID : cryptogramme visuel à 3 ou 4 chiffres au dos de la carte.
• Données de bande magnétique / piste (track data).
• PIN et blocs PIN chiffrés.
• Ne doivent JAMAIS être stockées après l'autorisation de la transaction — même chiffrées.

Cette distinction est fondamentale : un commerçant peut stocker un PAN (tokenisé ou chiffré) pour rembourser ou refacturer, mais ne doit jamais conserver le CVV qu'il a utilisé pour une transaction précédente.

Entités concernées

Commerçants (merchants)

Toute entité qui accepte des cartes de paiement comme moyen de paiement. Classés en 4 niveaux selon le volume de transactions annuel (Visa/Mastercard) — voir section « Niveaux de conformité ».

Prestataires de services (service providers)

Toute entité qui stocke, traite ou transmet des données carte pour le compte d'autres entités. Inclut : PSP (Payment Service Providers), passerelles de paiement, hébergeurs cloud hébergeant des infrastructures de paiement, centres d'appel, éditeurs SaaS proposant des fonctions de paiement, processeurs, acquéreurs.

Les prestataires de services ont des exigences plus strictes et sont classés en 2 niveaux (niveau 1 au-dessus de 300 000 transactions annuelles).

Acteurs associés

• Acquéreurs : banques qui collectent les paiements pour les commerçants.
• Émetteurs : banques qui émettent les cartes aux porteurs.
• Réseaux : Visa, Mastercard, Amex, Discover, JCB.
• QSA : auditeurs qualifiés (Qualified Security Assessors).
• ASV : prestataires de scans qualifiés (Approved Scanning Vendors).
• PFI : investigateurs post-incident qualifiés (PCI Forensic Investigators).

Approches de réduction du périmètre

Un levier stratégique majeur : réduire la surface PCI DSS en limitant l'exposition aux données carte.

Externalisation complète vers un PSP

Utiliser un prestataire PCI DSS certifié (Stripe, Adyen, PayPal, Worldline, Mollie, Lemonway) pour que les données carte ne transitent jamais par les systèmes du commerçant. Techniques : redirection vers la page du PSP, iframe hébergée par le PSP, champs hébergés (hosted fields). Réduit drastiquement le périmètre PCI DSS du commerçant (passage possible au SAQ A, le plus simple).

Tokenisation

Remplacement du PAN par un token non exploitable, stocké chez le PSP. Le commerçant ne manipule que le token pour les refacturations ou remboursements. Reconnue par PCI DSS si correctement mise en œuvre.

Segmentation réseau

Isoler strictement le Cardholder Data Environment (CDE) du reste du SI via la segmentation. Les systèmes hors CDE sortent du périmètre PCI. La segmentation doit être démontrée par des tests d'intrusion et documentée.

03 — ExigencesLes 12 exigences fondamentales

PCI DSS structure ses exigences en 6 objectifs qui regroupent 12 exigences principales, elles-mêmes déclinées en centaines de sous-exigences spécifiques.

Objectif 1 — Construire et maintenir un réseau sécurisé

Exigence 1 — Installer et maintenir des contrôles de sécurité réseau

Pare-feu et contrôles équivalents entre le CDE et les réseaux non fiables, documentation des flux, revue périodique des règles.

Exigence 2 — Appliquer des configurations sécurisées à tous les composants

Changer les mots de passe par défaut (critique — vecteur d'attaque classique), désactiver les services inutiles, configurations durcies documentées.

Objectif 2 — Protéger les données du titulaire

Exigence 3 — Protéger les données carte stockées

Chiffrement fort des PAN stockés (AES-256 recommandé), masquage à l'affichage (ne montrer que les 6 premiers et 4 derniers chiffres), destruction sécurisée après délai, interdiction absolue de stocker le CVV et le contenu de la piste.

Exigence 4 — Protéger les transmissions avec un chiffrement fort

TLS 1.2+ obligatoire sur les réseaux publics, interdiction des protocoles obsolètes (SSL, TLS 1.0/1.1), gestion des certificats, pas d'envoi PAN par email/SMS sans chiffrement.

Objectif 3 — Maintenir un programme de gestion des vulnérabilités

Exigence 5 — Protéger tous les systèmes et réseaux contre les logiciels malveillants

Anti-malware sur tous les systèmes à risque, mises à jour régulières, surveillance, détection proactive. EDR moderne couramment utilisé pour satisfaire cette exigence.

Exigence 6 — Développer et maintenir des systèmes et logiciels sécurisés

Gestion des vulnérabilités (CVE/CVSS), patching rapide, développement sécurisé (secure SDLC), code review, scans applicatifs. Protection des applications web (WAF ou équivalent).

Objectif 4 — Implémenter des contrôles d'accès forts

Exigence 7 — Restreindre l'accès par besoin de savoir

Principe de moindre privilège, séparation des tâches, validation explicite des accès, revue périodique.

Exigence 8 — Identifier et authentifier les accès

Identifiants uniques, MFA obligatoire depuis PCI DSS 4.0 pour tous les accès au CDE, politique mots de passe robuste, expiration, blocage après tentatives échouées.

Exigence 9 — Restreindre l'accès physique aux données

Contrôle d'accès physique aux locaux contenant des données carte, badges, journalisation des entrées, gestion des supports (papier, USB, archives) et destruction sécurisée.

Objectif 5 — Surveiller et tester régulièrement les réseaux

Exigence 10 — Journaliser et surveiller tous les accès

Logs exhaustifs des accès aux données carte, conservation minimum 1 an (3 mois accessibles en ligne), synchronisation des horloges, protection des logs, revue régulière. SIEM très utilisé.

Exigence 11 — Tester régulièrement la sécurité

Scans ASV trimestriels (périmètre exposé à Internet), scans internes trimestriels, tests d'intrusion annuels, tests de segmentation, détection d'intrusion, intégrité des fichiers critiques.

Objectif 6 — Maintenir une politique de sécurité

Exigence 12 — Politique de sécurité de l'information

Politique formalisée et maintenue, analyse de risques annuelle, formation et sensibilisation (y compris anti-phishing), gestion des fournisseurs, plan de réponse à incident, enquêtes préalables à l'embauche.

Nouvelles exigences PCI DSS 4.0

PCI DSS 4.0 a ajouté et renforcé plusieurs exigences, notamment :

• MFA pour tous les accès au CDE (pas seulement admin).
• Détection des scripts tiers en page de paiement (contre le Magecart / formjacking).
• Authentification renforcée (12 caractères minimum d'ici 2025-2026).
• Analyse de risque ciblée pour justifier certains choix en customized approach.
• Détection et réponse aux incidents renforcées.

04 — NiveauxLes catégories de commerçants et prestataires

Niveaux des commerçants (Visa, Mastercard similaire)

Niveau 1 — Plus de 6 millions de transactions annuelles

• Commerçants les plus importants (grandes enseignes, sites e-commerce majeurs).
• Audit QSA annuel obligatoire.
• Scans ASV trimestriels.
• Test d'intrusion annuel.
• Attestation of Compliance (AoC) signée par dirigeant.

Niveau 2 — 1 à 6 millions de transactions annuelles

• SAQ annuel signé (auto-évaluation).
• Scans ASV trimestriels.
• Certains réseaux imposent audit QSA (Mastercard).

Niveau 3 — 20 000 à 1 million de transactions annuelles

• SAQ annuel.
• Scans ASV trimestriels.

Niveau 4 — Moins de 20 000 transactions annuelles

• SAQ annuel.
• Scans ASV trimestriels (si exposition Internet).
• Obligations variables selon la banque acquéreuse.

Niveaux des prestataires de services

Niveau 1 — Plus de 300 000 transactions annuelles

• Audit QSA annuel obligatoire.
• Exigences plus strictes que les commerçants de même niveau.
• Obligations accrues de reporting.

Niveau 2 — Moins de 300 000 transactions annuelles

• SAQ D-SP annuel (version spécifique aux service providers).
• Scans ASV trimestriels.

Les différents SAQ selon l'activité

Le PCI SSC propose plusieurs SAQ adaptés au type d'activité :

• SAQ A : e-commerce qui externalise totalement (redirection pure vers un PSP PCI DSS certifié). Le plus simple — une vingtaine de questions.
• SAQ A-EP : e-commerce avec iframe ou intégration hébergée du PSP (le site marchand contrôle partiellement le DOM).
• SAQ B : terminaux de paiement autonomes (pas d'électronique moderne).
• SAQ B-IP : terminaux de paiement IP.
• SAQ C : systèmes de paiement connectés à Internet.
• SAQ C-VT : terminal virtuel uniquement.
• SAQ P2PE : solution Point-to-Point Encryption certifiée.
• SAQ D : tous les autres cas (traitement complet des données carte). Le plus complet — des centaines de questions.
• SAQ D-SP : service provider niveau 2.
• SAQ SPoC : application mobile sur COTS (Commercial Off-The-Shelf), nouveauté.

Sélectionner le bon SAQ

Le choix du SAQ est stratégique : un SAQ A est accessible à une petite structure, un SAQ D est un projet lourd. Beaucoup d'organisations investissent pour redessiner leur intégration afin de basculer d'un SAQ D à un SAQ A. Confirmation par la banque acquéreuse en cas de doute.

05 — ValidationLe processus de conformité

Acteurs qualifiés du PCI SSC

QSA — Qualified Security Assessor

Cabinets agréés par le PCI SSC pour conduire les audits PCI DSS. En France et Europe : NTT, Advens, Provadys, Orange Cyberdefense, Deloitte, PwC, KPMG, EY, BDO, Foregenix, Coalfire, Trustwave, Schellman. La liste complète est publiée sur le site du PCI SSC.

ISA — Internal Security Assessor

Employé certifié en interne par une grande organisation pour conduire des audits internes PCI. Ne peut pas signer les RoC pour son employeur mais participe activement à la démarche.

ASV — Approved Scanning Vendor

Prestataires agréés pour réaliser les scans de vulnérabilités trimestriels obligatoires. Liste variée : Qualys, Tenable, Rapid7, SecurityMetrics, ControlScan, A-LIGN.

PFI — PCI Forensic Investigator

Cabinets qualifiés pour conduire les investigations forensic après incident impliquant des données carte. Obligatoires en cas de violation.

Processus de validation

Audit QSA typique

1. Scoping : définition du CDE, cartographie des flux carte.
2. Gap assessment : identification des écarts avec les exigences.
3. Remédiation : correction des écarts.
4. Audit terrain : tests, revues, entretiens.
5. Tests d'intrusion : internes, externes, de segmentation.
6. Rapport d'audit (RoC) : document de 200-500 pages documentant chaque exigence.
7. Attestation of Compliance (AoC) : résumé signé par la direction et le QSA.
8. Soumission à l'acquéreur/réseau.

Durée et coût typiques

• SAQ A : quelques jours de travail, 0-5 000 € si accompagnement.
• SAQ D : 2-6 mois de préparation, 20 000-100 000 € selon complexité.
• Premier audit QSA niveau 1 : 12-18 mois, 150 000-500 000 € et plus tout compris (conseil, outillage, audit).
• Renouvellement annuel QSA : 30-50% du premier coût.
• Scans ASV : quelques milliers d'euros par an.

Cadence et maintien

• Audit QSA ou SAQ : annuel.
• Scans ASV : trimestriels.
• Scans internes : trimestriels.
• Tests d'intrusion : annuels + après tout changement significatif.
• Formation personnel : annuelle minimum.
• Revue des accès : au moins semestrielle.
• Revue des règles pare-feu : au moins semestrielle.

Conséquences de la non-conformité

• Amendes par les réseaux : 5 000 à 100 000 USD/mois selon gravité.
• Hausse des frais d'interchange : renchérissement des coûts de transaction.
• Interdiction de traiter certaines cartes dans les cas extrêmes.
• Coûts forensic en cas de violation : PFI obligatoire, 50 000 à 500 000+ €.
• Compensation aux émetteurs : 3-10 USD par carte compromise à remplacer.
• Amende CNIL si données personnelles impliquées.
• Coût réputationnel souvent supérieur aux sanctions directes.

06 — Version 4.0Les évolutions majeures

Les deux approches possibles

Defined approach (approche définie)

Respect strict des exigences telles que formulées. Mode traditionnel. Plus simple à auditer, moins flexible.

Customized approach (approche personnalisée)

L'entité définit ses propres mesures de contrôle, démontre qu'elles atteignent l'objectif de l'exigence, documente une analyse de risque ciblée (Targeted Risk Analysis). Flexibilité accrue mais demande plus de travail documentaire et de compétence. Utile pour intégrer des solutions modernes que les exigences prescriptives ne prévoient pas.

MFA étendue

PCI DSS 3.2.1 imposait déjà la MFA pour les administrateurs et les accès distants. PCI DSS 4.0 étend l'obligation à tous les accès au CDE, y compris les utilisateurs finaux et les accès depuis le réseau interne. Impact opérationnel majeur pour beaucoup d'organisations.

Mots de passe renforcés

Exigences transitoires :

• Avant avril 2025 : 7 caractères minimum, changement tous les 90 jours.
• Depuis avril 2025 : 12 caractères minimum (ou 8 minimum avec technologies alternatives avancées), alignement progressif avec les bonnes pratiques NIST.
• Encouragement à l'usage de passkeys et MFA résistante au phishing.

Sécurité des scripts tiers (exigence 6.4.3)

Réponse à la vague d'attaques Magecart (formjacking de pages de paiement via scripts tiers compromis). Obligation d'inventorier les scripts présents sur les pages de paiement, de surveiller leur intégrité, d'autoriser explicitement leur chargement. Technologies : Content Security Policy (CSP), Subresource Integrity (SRI), monitoring dédié.

Détection d'intrusion renforcée

Exigences sur la capacité de détection (IDS/IPS, EDR, SIEM), sur la réponse automatisée aux alertes critiques, sur l'intégrité des fichiers.

Analyse de risque ciblée

Pour certaines exigences, PCI DSS 4.0 demande une Targeted Risk Analysis formalisée justifiant les choix de fréquence ou de portée. Nouveau livrable pour les audits.

Cryptographie et post-quantique

Recommandations croissantes autour de la robustesse cryptographique et de la préparation au post-quantique. Les clés cryptographiques doivent être gérées via HSM ou équivalent ; la crypto-agilité (capacité à changer d'algorithme) devient un objectif explicite.

Calendrier d'application

• 31 mars 2024 : fin du support de PCI DSS 3.2.1.
• Depuis avril 2024 : PCI DSS 4.0/4.0.1 seule version en vigueur.
• Depuis le 1er avril 2025 : toutes les exigences 4.0 dites « future-dated » sont pleinement obligatoires.
• Toute organisation auditée après avril 2025 doit être conforme à 4.0.1 dans son intégralité.

07 — DémarcheConduire un projet PCI DSS

08 — FAQQuestions fréquentes

PCI DSS et RGPD sont-ils redondants ?

Complémentaires, pas redondants. RGPD protège les données personnelles au sens large, avec une approche risques et droits des personnes. PCI DSS protège spécifiquement les données carte avec des exigences prescriptives techniques. Un numéro de carte bancaire est une donnée personnelle au sens RGPD — les deux régimes s'appliquent. Les mesures techniques PCI DSS (chiffrement, MFA, journalisation) contribuent à la conformité RGPD. En cas de violation de données carte, notification CNIL sous 72h et notification au réseau carte et banque acquéreuse dans les délais contractuels (souvent plus courts).

Faut-il être auditeur QSA pour conseiller sur PCI ?

Non pour conseiller ; oui pour signer un RoC. Beaucoup de consultants PCI expérimentés sans qualification QSA accompagnent les projets. Les QSA interviennent surtout pour : gap assessment officiel, RoC niveau 1, audits formels. Le conseil stratégique, la préparation, la remédiation peuvent être menés par tout expert PCI compétent. Les certifications individuelles ISA (Internal Security Assessor) pour les salariés et PCIP (Professional) pour les consultants sont valorisées.

Peut-on utiliser le cloud pour des charges PCI ?

Oui, avec précautions. AWS, Azure, GCP proposent des attestations PCI DSS couvrant leur infrastructure (shared responsibility model). Le client reste responsable de sa couche applicative, configuration, données, accès. Les services PaaS ou managés simplifient selon le cas. Les AoC des hyperscalers sont disponibles via leurs portails de compliance (AWS Artifact, Azure Compliance Center, GCP Compliance Reports Manager). Les clients doivent vérifier quels services exacts sont dans le périmètre de l'attestation.

Comment PCI DSS traite les applications mobiles ?

Plusieurs standards complémentaires. PCI SSF (Software Security Framework) remplace PA-DSS depuis 2022 pour les applications de paiement. PCI MPoC (Mobile Payments on COTS) et SPoC (Software PIN on COTS) couvrent l'acceptation de paiement sur smartphones grand public. Pour un commerçant qui consomme ces applications, PCI DSS s'applique normalement, mais certaines exigences peuvent être héritées du prestataire certifié fournissant l'app de paiement.

Les tokens 3D Secure remplacent-ils PCI DSS ?

Non. 3D Secure (EMV 3DS, évolution d'ancien 3DS 1.0) est un protocole d'authentification qui réduit la fraude (liability shift vers l'émetteur en cas d'authentification valide) mais ne concerne que l'authentification du porteur. Le PAN reste traité par le commerçant et PCI DSS s'applique. 3DS améliore la sécurité sans remplacer le standard. L'authentification forte imposée par la DSP2 (directive européenne sur les paiements) utilise largement 3DS.