Qu'est-ce que PCI DSS, et à qui s'applique-t-il
PCI DSS (Payment Card Industry Data Security Standard) est le référentiel de sécurité qui encadre le stockage, le traitement et la transmission des données de carte de paiement. Il est publié par le PCI SSC (Security Standards Council), consortium fondé en 2006 par les cinq grands réseaux, Visa, Mastercard, American Express, Discover et JCB. Aucun régulateur public ne l'édicte. Sa force contraignante vient des contrats, les réseaux et les acquéreurs l'imposant à tout acteur qui touche à une donnée carte.
La version en vigueur est la v4.0, publiée en mars 2022, révisée en v4.0.1 en juin 2024 (corrections rédactionnelles, pas de nouvelle exigence). La v3.2.1 a été retirée le 31 mars 2024. Une série d'exigences dites « futures », tolérées jusque-là en simple bonne pratique, sont devenues obligatoires le 31 mars 2025. Ce basculement structure l'actualité du référentiel en 2025 et 2026.
Le CDE : définir et réduire le périmètre
Le CDE (Cardholder Data Environment) désigne l'ensemble des personnes, des processus et des systèmes qui stockent, traitent ou transmettent des données de compte, plus tout système connecté qui pourrait les compromettre. Sa délimitation ouvre tout projet de conformité. Elle établit la liste des actifs à évaluer et commande le coût de l'évaluation, car tout ce qui est hors périmètre échappe aux exigences.
PCI DSS distingue deux familles de données de compte. Leurs règles de conservation diffèrent radicalement. Les données du titulaire (cardholder data) peuvent être stockées, à condition de les protéger, alors que les données d'authentification sensibles (SAD) ne doivent jamais être conservées après l'autorisation, même chiffrées.
| Élément | Catégorie | Stockage autorisé | Doit être rendu illisible |
|---|---|---|---|
| Numéro de carte (PAN) | Donnée titulaire | Oui | Oui |
| Nom du porteur | Donnée titulaire | Oui | Non (mais protégé par le périmètre) |
| Date d'expiration | Donnée titulaire | Oui | Non |
| Code de service | Donnée titulaire | Oui | Non |
| Contenu complet de la piste / puce | SAD | Jamais après autorisation | s.o. |
| Cryptogramme (CVV2 / CVC2 / CID) | SAD | Jamais après autorisation | s.o. |
| PIN / bloc PIN | SAD | Jamais après autorisation | s.o. |
La segmentation réseau désigne l'isolement du CDE du reste du système d'information, obtenu par des VLAN, des pare-feux et des contrôles d'accès. Elle empêche un poste bureautique compromis de servir de rebond vers les systèmes qui traitent la donnée carte. Elle retire du même coup des dizaines de machines du champ de l'audit, ce qui en fait le principal levier de réduction de périmètre.
Les 12 exigences, regroupées en 6 objectifs
Le standard se compose de 12 exigences organisées en six grands objectifs, chacune se déclinant en dizaines de sous-exigences testables. Le tableau ci-dessous en donne la vue d'ensemble.
| Objectif | N° | Exigence | En clair |
|---|---|---|---|
| Réseau sécurisé | 1 | Contrôles de sécurité réseau | Pare-feux et filtrage entre le CDE et le reste |
| Réseau sécurisé | 2 | Configurations sécurisées | Plus de mots de passe par défaut ni de services inutiles |
| Protéger les données | 3 | Protéger les données de compte stockées | Chiffrer/tronquer le PAN, ne jamais garder les SAD |
| Protéger les données | 4 | Chiffrer les transmissions sur réseaux ouverts | TLS fort de bout en bout sur Internet |
| Gestion des vulnérabilités | 5 | Protéger contre les logiciels malveillants | Anti-malware maintenu et surveillé |
| Gestion des vulnérabilités | 6 | Développer et maintenir des systèmes sûrs | Correctifs, développement sécurisé, gestion des scripts |
| Contrôle d'accès | 7 | Restreindre l'accès au besoin d'en connaître | Moindre privilège, accès justifié par le rôle |
| Contrôle d'accès | 8 | Identifier et authentifier les accès | Identifiants nominatifs, MFA généralisée |
| Contrôle d'accès | 9 | Restreindre l'accès physique | Sécuriser locaux, médias, terminaux |
| Surveiller et tester | 10 | Journaliser et surveiller les accès | Traçabilité, horodatage, revue des logs |
| Surveiller et tester | 11 | Tester régulièrement la sécurité | Scans ASV, tests d'intrusion, détection d'altération |
| Politique | 12 | Politique de sécurité de l'information | Gouvernance, sensibilisation, gestion des tiers |
Nouveautés v4 : 6.4.3 et 11.6.1 contre l'e-skimming
Le skimming côté navigateur désigne l'injection de code voleur dans la page de paiement affichée chez le client, technique connue sous le nom d'attaques de type Magecart. Deux des exigences devenues obligatoires le 31 mars 2025 visent explicitement ce mode d'attaque. Les versions précédentes du standard portaient sur les systèmes serveurs du marchand, sans traiter le code exécuté dans le navigateur.
Une page de paiement contemporaine charge couramment des dizaines de scripts tiers (analytics, chat, A/B testing), et chacun d'eux peut être détourné pour lire les champs de saisie. Les moyens employés combinent CSP (Content Security Policy), Subresource Integrity (SRI) et surveillance de l'inventaire des scripts. Un formulaire de saisie iframé hébergé par le PSP place la donnée carte hors du DOM du marchand. Les scripts de la page n'y accèdent plus.
Niveaux marchands, SAQ et attestation
La manière de prouver sa conformité dépend du volume de transactions et du mode d'acceptation, les réseaux définissant quatre niveaux marchands. Au-delà d'environ 6 millions de transactions carte par an (niveau 1), l'entité doit produire un ROC (Report on Compliance) établi par un QSA (auditeur qualifié). En dessous, elle peut recourir à un auto-questionnaire (SAQ) adapté à sa situation.
| Niveau | Volume annuel de transactions carte | Preuve attendue |
|---|---|---|
| Niveau 1 | > 6 millions (tous canaux) ou marchand compromis | Audit sur site + ROC par un QSA, scans ASV trimestriels |
| Niveau 2 | 1 à 6 millions | SAQ (parfois audit exigé par l'acquéreur), scans ASV |
| Niveau 3 | 20 000 à 1 million en e-commerce | SAQ + scans ASV trimestriels |
| Niveau 4 | < 20 000 en e-commerce, jusqu'à 1 million autres canaux | SAQ + scans ASV, à l'appréciation de l'acquéreur |
Le SAQ désigne une famille de questionnaires, chacun établi pour un mode d'acceptation particulier. Le questionnaire retenu dépend de la façon dont l'entité reçoit et traite la donnée carte, et il fixe par là même le nombre d'exigences à démontrer.
| SAQ | Situation type | Nombre d'exigences (ordre de grandeur) |
|---|---|---|
| A | E-commerce 100 % externalisé (redirection ou iframe PSP) | Le plus court |
| A-EP | E-commerce partiellement externalisé, la page marchand influe sur la sécurité | Intermédiaire, en forte hausse |
| B / B-IP | Terminaux autonomes (dial-out, ou IP) | Court |
| C-VT | Terminal virtuel (saisie manuelle sur navigateur isolé) | Court à moyen |
| C | Application de paiement connectée à Internet | Moyen |
| P2PE | Terminal validé PCI P2PE | Très réduit grâce au chiffrement matériel |
| D | Tous les autres marchands et les prestataires de services | Le plus complet (les 12 exigences) |
Coûts, réduction de périmètre et sanctions
Le coût de la conformité varie fortement d'une entité à l'autre. Il suit d'abord l'étendue du périmètre évalué. Plus le périmètre est large, plus l'audit est cher, puisque le nombre de systèmes, de flux et de contrôles à examiner croît avec lui. La tokenisation, le P2PE et l'externalisation de la saisie réduisent ce périmètre, font descendre un marchand du SAQ D vers le SAQ A et divisent la charge par dix.
- Externaliser la saisie (iframe / redirection PSP) pour viser le SAQ A.
- Tokeniser les PAN dès l'entrée : plus aucune donnée carte en clair au repos.
- Segmenter le réseau pour isoler et rétrécir le CDE.
- Choisir des terminaux P2PE validés pour le point de vente physique.
- Cartographier les flux de données carte au moins une fois par an, ce qui est une exigence et le meilleur révélateur d'un périmètre qui a dérivé.