Un paiement par carte peut sembler entièrement géré par la banque, le terminal ou le prestataire de paiement. Pourtant, dès qu'une entreprise stocke, traite ou transmet des données de carte, ou qu'un de ses systèmes peut affecter la sécurité de cet environnement, la norme PCI DSS entre dans le raisonnement. Son objectif est de réduire le risque de vol ou de compromission des données de paiement en imposant un socle commun de mesures techniques et organisationnelles.
La version de référence publiée par le PCI Security Standards Council est PCI DSS v4.0.1. Pour une PME, l'enjeu n'est pas de transformer toute son informatique en environnement bancaire. Il faut surtout savoir où passent les données de carte, quels systèmes sont réellement concernés et quelle preuve de conformité est demandée par l'acquéreur ou le réseau de cartes.
Qu'est-ce que la norme PCI DSS et qui l'a créée ?
PCI DSS signifie Payment Card Industry Data Security Standard. Il s'agit d'un standard de sécurité destiné à protéger les données de comptes de paiement. Le PCI Security Standards Council, ou PCI SSC, maintient ce référentiel et publie les documents de validation associés.
Le PCI SSC a été fondé en 2006 par American Express, Discover, JCB International, Mastercard et Visa. Ces réseaux intègrent PCI DSS dans leurs propres programmes de conformité. C'est une distinction importante : le Conseil élabore et maintient le standard, tandis que les modalités de conformité et de validation relèvent des réseaux de cartes et des acteurs qui permettent au commerçant d'accepter les paiements.
Quelles entreprises sont concernées par PCI DSS ?
Le périmètre ne dépend pas uniquement de la taille de l'entreprise. PCI DSS vise les entités qui stockent, traitent ou transmettent des données de titulaires de cartes ou des données d'authentification sensibles. Il peut aussi concerner des systèmes ou des prestataires capables d'influencer la sécurité de l'environnement dans lequel ces données sont traitées.
Un commerçant en boutique, un site e-commerce, un prestataire de paiement, un hébergeur ou un fournisseur de services techniques peuvent donc être concernés à des degrés différents. Le point déterminant est le flux réel des données, pas le chiffre d'affaires de l'entreprise.
Une PME qui externalise le paiement doit-elle quand même s'en préoccuper ?
Oui. Externaliser le paiement à un prestataire conforme peut réduire fortement le périmètre PCI DSS, mais ne dispense pas automatiquement le commerçant de toute démarche. Il faut vérifier comment le paiement est intégré, quelles données transitent encore par le site ou les systèmes internes et quel questionnaire ou justificatif l'acquéreur demande.
C'est particulièrement important en e-commerce. Une page qui redirige totalement vers un prestataire de paiement n'a pas le même périmètre qu'un site qui héberge lui-même des champs de carte ou des scripts capables d'interagir avec la page de paiement.
Quelles sont les 12 exigences de la norme PCI DSS ?
PCI DSS v4.0.1 repose sur douze grandes familles d'exigences. Elles couvrent le réseau, les configurations, la protection des données, les logiciels malveillants, les accès, la journalisation, les tests et la gouvernance. Pour un décideur, l'intérêt est moins de mémoriser les douze numéros que de comprendre qu'une conformité sérieuse ne se limite pas à installer un pare-feu ou un antivirus.
| Exigence | Ce qu'elle impose en pratique |
|---|---|
| 1. Sécurité du réseau | Mettre en place et maintenir des mesures de sécurité réseau adaptées. |
| 2. Configurations sécurisées | Éviter les réglages par défaut et appliquer des configurations sécurisées aux composants du système. |
| 3. Données stockées | Limiter, protéger et maîtriser la conservation des données de compte. |
| 4. Données transmises | Protéger les données de titulaires de cartes lors de leur transmission sur des réseaux publics ouverts. |
| 5. Logiciels malveillants | Protéger les systèmes et réseaux contre les logiciels malveillants et maintenir ces protections. |
| 6. Systèmes et logiciels | Développer, corriger et maintenir des systèmes et logiciels sécurisés. |
| 7. Limitation des accès | Accorder l'accès aux données et systèmes selon le besoin professionnel réel. |
| 8. Identification et authentification | Identifier les utilisateurs et sécuriser leur authentification avant l'accès aux composants concernés. |
| 9. Accès physique | Limiter les accès physiques aux données de titulaires de cartes et aux supports concernés. |
| 10. Journalisation | Enregistrer et surveiller les accès aux systèmes et aux données de paiement. |
| 11. Tests de sécurité | Tester régulièrement la sécurité des systèmes, des réseaux et des contrôles mis en place. |
| 12. Politique de sécurité | Formaliser les responsabilités, les procédures et le programme de sécurité de l'information. |
Pour une PME, le piège classique consiste à traiter ces exigences comme une checklist annuelle. Plusieurs contrôles doivent être maintenus en continu ou réalisés à des fréquences précises. Une configuration correcte le jour de l'audit ne suffit donc pas si les accès, les correctifs ou la supervision se dégradent ensuite.
Comment prouver sa conformité PCI DSS ?
La conformité et sa validation sont deux sujets distincts. Une entreprise doit d'abord appliquer les exigences qui correspondent à son environnement. Elle doit ensuite fournir la preuve demandée par son acquéreur, son réseau de cartes ou un autre donneur d'ordre.
Quelle différence entre un SAQ et un audit PCI DSS ?
Le SAQ, pour Self-Assessment Questionnaire, est un questionnaire d'auto-évaluation utilisé lorsque l'organisation répond aux critères du type de SAQ concerné. Il en existe plusieurs, car un e-commerçant qui externalise entièrement le paiement n'a pas le même environnement qu'un commerçant utilisant un système de paiement connecté à Internet.
Le ROC, ou Report on Compliance, documente une évaluation plus complète. Selon le programme de conformité applicable, le volume de transactions, le type d'activité ou le niveau de risque, l'évaluation peut nécessiter l'intervention d'un QSA, un évaluateur qualifié par le PCI SSC. Il ne faut donc pas choisir seul un SAQ parce qu'il paraît plus simple : la bonne méthode de validation doit être confirmée avec l'acquéreur ou l'organisme qui exige la conformité.
Que risque une entreprise non conforme à PCI DSS ?
PCI DSS n'est pas une loi française. Il s'agit d'un standard intégré aux programmes contractuels des réseaux de cartes et des acteurs du paiement. Les conséquences d'une non-conformité varient donc selon le contrat, le réseau concerné, la gravité de la situation et l'existence éventuelle d'un incident de sécurité.
Une entreprise peut notamment se voir imposer des mesures correctives, des contrôles supplémentaires ou des conséquences financières prévues par son environnement contractuel. Dans les cas les plus sérieux, la capacité à accepter des paiements par carte peut être remise en cause. Il faut éviter d'annoncer un montant universel de « pénalité PCI DSS » : il n'existe pas un barème unique applicable à toutes les entreprises.
PCI DSS remplace-t-elle les obligations du RGPD ?
Non. PCI DSS et le RGPD ne couvrent pas la même chose. PCI DSS définit un standard de sécurité pour les données de paiement, tandis que le RGPD encadre le traitement des données personnelles. Si une violation de données de paiement concerne aussi des données personnelles, l'entreprise doit analyser séparément ses obligations au titre du RGPD, notamment la documentation de l'incident et, selon le niveau de risque, sa notification à la CNIL.
Autrement dit, être conforme à PCI DSS ne dispense pas de respecter la réglementation sur les données personnelles, et l'inverse est également vrai.
Comment organiser une mise en conformité PCI DSS ?
La démarche commence par le périmètre. Tant que l'entreprise ne sait pas précisément où les données de carte sont saisies, transmises, stockées ou accessibles, elle ne peut ni évaluer ses écarts ni déterminer la bonne méthode de validation.
- Cartographier les flux de paiement. Identifiez les terminaux, pages web, serveurs, applications, prestataires et connexions qui participent au paiement ou peuvent affecter sa sécurité.
- Réduire le périmètre. Évitez de stocker des données de carte lorsque ce n'est pas nécessaire et privilégiez, lorsque l'architecture le permet, des solutions qui limitent l'exposition de vos propres systèmes.
- Confirmer la méthode de validation. Demandez à votre acquéreur ou à votre prestataire de paiement quel SAQ, quelle attestation ou quel type d'évaluation correspond à votre situation.
- Traiter les écarts. Corrigez les configurations, les accès, la protection des données, la journalisation, la gestion des vulnérabilités et les procédures qui ne répondent pas aux exigences applicables.
- Conserver les preuves. Documentez les contrôles, les revues, les tests et les responsabilités. Une mesure de sécurité difficile à prouver devient vite un problème lors d'une validation.
- Maintenir la conformité. Intégrez les contrôles PCI DSS à l'exploitation courante plutôt que de les remettre à niveau uniquement avant l'échéance annuelle.
Quelle première vérification faire avant de lancer un projet PCI DSS ?
Commencez par demander à votre prestataire de paiement et à votre banque acquéreuse quel est exactement votre périmètre de validation. Ensuite, dessinez le trajet d'un paiement depuis la saisie de la carte jusqu'au prestataire qui l'autorise. Si un numéro de carte apparaît dans un journal, une base de données, un ticket de support, un export ou une application interne alors que vous pensiez avoir tout externalisé, votre périmètre réel est probablement plus large que prévu.
À l'inverse, une architecture qui évite à vos systèmes de recevoir ou de conserver les données de carte peut alléger considérablement la charge de conformité. C'est souvent le premier levier à examiner avant d'ajouter des outils, des audits ou des procédures supplémentaires.
