PCI DSS.
Délimiter les données de paiement et leurs dépendances, clarifier les responsabilités opérationnelles et convenir de la preuve adaptée avec l’organisme compétent.
- PCI DSS v4.0.1 · PCI SSC
- Par Jonathan Bezdek
- À jour au 22/10/2026
- Temps de lecture : 9 min
Réponse courte.
PCI DSS est la norme sectorielle de protection des données de cartes de paiement. Elle concerne les commerçants, prestataires et systèmes qui les traitent ou influencent leur sécurité. La version actuelle est PCI DSS v4.0.1. L’environnement de paiement et le rôle déterminent le périmètre ; la démarche de preuve est convenue avec l’acquéreur ou la marque de paiement, notamment par SAQ ou ROC.
PCI DSS 4.0 et la version actuelle.
PCI DSS associe des exigences techniques et opérationnelles de sécurité des données de paiement. Le PCI Security Standards Council, ou PCI SSC, développe la norme et ses outils d’accompagnement. Les organismes acceptant la preuve, généralement les acquéreurs et les marques de paiement, déterminent comment démontrer le respect de la norme dans chaque programme de paiement ; la FAQ 1473 du PCI SSC explique cette répartition des rôles.
PCI DSS v4.0.1 est la version figurant dans la bibliothèque officielle. Selon la publication du PCI SSC sur la révision, v4.0 a été retirée le 31 décembre 2024. La date du 31 mars 2025, déjà prévue pour les nouvelles exigences v4, est restée inchangée. À la date de cette page, cette échéance est passée ; il ne s’agit pas d’un futur délai d’adoption.
Une validation réussie ne remplace pas la protection continue. Pour l’organisation pratique, les changements de circuits de paiement, d’applications et de prestataires doivent conduire à réexaminer le périmètre convenu. Une nouvelle intégration de paiement peut créer des dépendances différentes de la solution précédemment évaluée, même si la même entreprise continue d’accepter les paiements.
À qui s’applique PCI DSS.
Selon la présentation du PCI SSC, PCI DSS ne vise pas seulement les organisations stockant, traitant ou transmettant les données de carte. L’influence possible sur la sécurité de l’environnement des données de titulaires de carte, ou Cardholder Data Environment (CDE), doit aussi être considérée. Les commerçants et prestataires doivent donc d’abord décrire leur rôle concret et les prestations réellement fournies.
Externaliser le traitement des paiements ne crée pas d’exemption automatique. La FAQ 1092 du PCI SSC distingue une éventuelle réduction du périmètre direct d’exigences du maintien de la responsabilité relative au choix des prestataires, aux responsabilités convenues et à la preuve requise. Même avec une page de paiement hébergée, clarifiez avec l’organisme compétent les conditions à remplir par l’intégration technique choisie.
La limite se démontre par des mesures efficaces, au-delà d’un simple nom dans un schéma d’architecture. La FAQ 1115 du PCI SSC explique que les systèmes connectés et l’efficacité réelle de la segmentation doivent être examinés. Exclure trop vite les accès administratifs, services de soutien ou interfaces peut conduire à un périmètre d’examen incomplet.
Organiser les exigences PCI DSS dans l’exploitation.
La mise en œuvre relie la protection de l’environnement de paiement à des processus opérationnels traçables. Les six domaines suivants sont des repères éditoriaux de planification, et non une reproduction des douze exigences officielles ou des points de contrôle ; leur applicabilité concrète est examinée sur le périmètre confirmé.
Rendre les flux de paiement et le périmètre compréhensibles.
Suivez concrètement l’origine des informations de paiement, les composants participants et les personnes ou fournisseurs pouvant agir sur eux. Consignez la limite confirmée et ses hypothèses. Une description compréhensible aide le développement, l’exploitation et l’organisme acceptant la preuve à parler du même circuit de paiement.
Exploiter les systèmes et les changements de manière sûre.
Attribuez des responsables clairs aux applications et composants d’infrastructure concernés. À chaque changement, examinez si de nouvelles connexions, fonctions ou dépendances modifient le périmètre confirmé. Au quotidien, un historique traçable des changements est plus utile qu’un état ponctuel constitué uniquement pour l’examen.
Limiter l’utilisation et la transmission des données.
Commencez concrètement par identifier les données de paiement réellement nécessaires au processus choisi et les endroits où des copies peuvent apparaître. Prenez en compte les exports, journaux et processus de soutien. La planification détaillée de sécurité doit correspondre aux types de données et à leur finalité ; une classification générale de confidentialité n’explique pas ces décisions.
Organiser les accès de manière traçable.
Reliez les responsabilités métier aux possibilités techniques effectivement accordées. Examinez aussi les comptes de service, accès administratifs et fournisseurs, au-delà des salariés. Pour organiser le travail, clarifiez qui approuve un accès, qui traite les changements et comment constater son retrait dans les délais.
Vérifier le fonctionnement et traiter les enseignements.
Planifiez les enregistrements et contrôles adaptés avec les responsables de l’environnement de paiement. Un scan ou test de pénétration isolé ne décrit que son propre objet. Pour chaque constat, consignez le changement qui en découle et la vérification de son efficacité, sans assimiler un résultat de test à toute la preuve PCI DSS.
Inclure les prestataires et les incidents.
Définissez les interlocuteurs opérationnels et la conduite à tenir face aux anomalies. Pour les prestations externalisées, les tâches propres doivent rester compréhensibles à côté des engagements du fournisseur. La FAQ 1576 du PCI SSC explique qu’une preuve de prestataire doit couvrir les services utilisés ; un document d’entreprise quelconque ne suffit pas automatiquement.
Mettre en œuvre PCI DSS dans la durée.
Convenir du rôle et de la démarche de preuve.
Pour commencer concrètement, clarifiez avec l’acquéreur ou la marque de paiement votre rôle, la preuve attendue et l’interlocuteur compétent avant de choisir un formulaire.
Recenser un circuit de paiement.
Décrivez les données, applications, systèmes et prestataires concernés, du début du paiement aux enregistrements opérationnels conservés.
Confirmer le périmètre.
Examinez les connexions pertinentes et les composants influençant la sécurité, puis faites évaluer la délimitation, y compris la segmentation éventuelle, par des spécialistes.
Ancrer les tâches dans le fonctionnement.
Attribuez les mesures de protection et responsabilités partagées à des personnes précises et reliez leur mise en œuvre aux enregistrements adaptés.
Préparer des preuves cohérentes.
Vérifiez que les documents requis décrivent le même service, le même rôle et le même périmètre, et que les décisions ouvertes ont été traitées de manière traçable.
Suivre les changements et les examens ultérieurs.
Convenez des intervalles de preuve nécessaires et vérifiez lors des changements que le périmètre, les preuves des prestataires et les responsabilités opérationnelles restent adaptés.
La « certification PCI » et les preuves réellement prévues.
La preuve reconnue PCI DSS utilise les documents officiels prévus. Un SAQ documente une autoévaluation admissible, un ROC les résultats de la démarche d’examen correspondante et une AOC l’attestation associée. Selon la FAQ 1220 du PCI SSC, des documents quelconques appelés certificats de conformité ne remplacent pas les modèles officiels.
L’organisme acceptant la preuve détermine la démarche requise ; un Qualified Security Assessor, ou QSA, peut intervenir lors d’un examen correspondant. Selon la FAQ 1473 du PCI SSC, le périmètre et l’applicabilité doivent être évalués correctement. Choisir un nom de SAQ ne confirme donc ni le respect de ses critères d’éligibilité ni l’application de toutes les exigences pertinentes.
Même le modèle adapté doit être utilisé dans sa version actuelle. Le PCI SSC a modifié les règles SAQ A au 31 mars 2025 et a explicitement précisé que la suppression de points de contrôle individuels du questionnaire n’abolit pas les exigences PCI DSS sous-jacentes. Convenez des dates de preuve et obligations ultérieures de votre cas plutôt que de supposer une durée générale de certificat.
Pour aller plus loin sur le blog.
Situer les autres référentiels.
ISO 27001 traite du management de la sécurité de l’information dans un périmètre défini ; la preuve PCI DSS est une décision distincte pour l’environnement de paiement. Les CIS Controls aident à hiérarchiser la sécurité générale, mais ne fixent aucune démarche de validation PCI. Le RGPD concerne les traitements de données personnelles et reste à examiner indépendamment de la preuve relative aux paiements.
Dans Secani.
Secani propose son propre catalogue éditorial pour les entreprises relatif à PCI DSS v4.0.1. Le profil recense notamment le périmètre CDE, le rôle de commerçant ou prestataire et la démarche SAQ/ROC convenue. Ces informations de travail facilitent un traitement structuré ; elles ne remplacent ni les documents officiels d’examen, ni la confirmation de l’éligibilité, ni le jugement de l’organisme compétent.
Commencer par un circuit de paiement concret.
Choisissez un circuit de paiement effectivement utilisé et désignez ses responsables métier et techniques. Consignez les prestations que vous assurez et celles confiées à un prestataire. Convenez ensuite de la preuve attendue avec l’organisme compétent avant de planifier les efforts sur la base d’un questionnaire supposé adapté.
Sources.
- PCI SSC – présentation de PCI DSS et publics visés
- PCI SSC – bibliothèque officielle de documents
- PCI SSC – publication de PCI DSS v4.0.1
- FAQ 1473 PCI SSC – organismes compétents et démarche de preuve
- FAQ 1092 PCI SSC – traitement externalisé des paiements
- FAQ 1576 PCI SSC – preuves des prestataires
- FAQ 1220 PCI SSC – documents officiels plutôt que certificats de conformité
- FAQ 1115 PCI SSC – systèmes connectés et segmentation
- PCI SSC – changements de SAQ A au 31 mars 2025
- PCI SSC – bulletin SAQ du 15 octobre 2024
Questions fréquentes.
Non, pas automatiquement. L’externalisation peut modifier le périmètre direct ; la responsabilité du choix de prestataires adaptés, de responsabilités claires et de la preuve requise reste à examiner séparément.
Pas seulement selon l’effort souhaité. Les critères d’éligibilité doivent être remplis et la démarche de preuve requise convenue avec l’organisme qui l’accepte.
Des certificats de conformité quelconques ne remplacent pas de manière reconnue les documents officiels. La démarche d’examen convenue et les rapports ou attestations officiels associés font foi.
Non. Un certificat SMSI concerne le périmètre de management qu’il indique ; les exigences et la démarche de preuve de l’environnement de paiement doivent être clarifiées séparément.
Délimiter le circuit de paiement.
Discutons de la manière de traiter le périmètre, les tâches et les preuves dans Secani.
Cette page présente PCI DSS dans ses propres termes et ne remplace ni les documents officiels du PCI SSC ni une évaluation spécialisée. Les exigences de chaque programme de paiement et les décisions de l’organisme compétent restent à respecter séparément.