Exigences de pentesting PCI DSS 4.0 : ce qui a changé et comment se préparer pour 2026

En bref : PCI DSS 4.0 a considérablement élargi les exigences de pentesting par rapport à la version 3.2.1. Les exigences à date future sont devenues obligatoires le 31 mars 2025, ce qui signifie que chaque organisation qui traite, stocke ou transmet des données de titulaires de cartes doit désormais se conformer aux règles plus strictes. Les changements clés incluent une méthodologie documentée obligatoire, des exigences explicites de tests internes et externes, une vérification élargie de la segmentation, des tests de la couche applicative alignés sur le OWASP Top 10, et la nouvelle option de validation d'approche personnalisée qui nécessite des tests encore plus rigoureux. Les fournisseurs de services font face à des obligations supplémentaires, notamment des tests de segmentation semestriels et une vérification de l'isolation multi-locataires. Ce guide détaille chaque exigence, explique ce qui a changé et fournit une liste de vérification pratique pour les évaluations de 2026.

---

PCI DSS 4.0 représente la refonte la plus significative du Standard de Sécurité des Données de l'Industrie des Cartes de Paiement depuis sa création. Publié en mars 2022 avec une période de transition se terminant le 31 mars 2025, le standard mis à jour a introduit des changements substantiels aux exigences de pentesting que de nombreuses organisations s'efforcent encore de comprendre et de mettre en œuvre. Avec les évaluations de 2026 qui approchent, la fenêtre de préparation se réduit.

Si vous traitez, stockez ou transmettez des données de titulaires de cartes -- ou si vous fournissez des services à des organisations qui le font -- comprendre les exigences de pentesting de PCI DSS 4.0 n'est pas optionnel. Contrairement à certains cadres de conformité où le pentesting est implicite ou recommandé, PCI DSS l'exige explicitement avec des exigences spécifiques de périmètre, de méthodologie et de fréquence que votre Évaluateur de Sécurité Qualifié (QSA) évaluera en détail.

Ce qui a changé entre PCI DSS 3.2.1 et 4.0

PCI DSS 3.2.1 traitait le pentesting principalement dans l'Exigence 11.3, avec un langage relativement large qui donnait aux organisations une latitude significative dans la manière dont elles conduisaient et documentaient leurs tests. La version 4.0 a renuméroté, élargi et renforcé ces exigences considérablement. Voici les changements les plus significatifs.

Renumérotation des exigences

PCI DSS 4.0 a réorganisé la structure des exigences. Le pentesting est passé de l'Exigence 11.3 à l'Exigence 11.4, avec les sous-exigences 11.4.1 à 11.4.7. Ce n'est pas seulement cosmétique -- la renumérotation reflète un contenu élargi et des sous-exigences supplémentaires qui n'existaient pas dans la version 3.2.1.

Méthodologie documentée obligatoire

L'Exigence 11.4.1 exige désormais explicitement qu'une méthodologie de pentesting soit définie, documentée et mise en œuvre. La méthodologie doit :

• Être basée sur une approche reconnue par l'industrie (PTES, OSSTMM, Guide de Test OWASP ou NIST SP 800-115)
• Couvrir l'ensemble du périmètre de l'environnement des données de titulaires de cartes (CDE) et les systèmes critiques
• Inclure des tests internes et externes
• Inclure des tests depuis l'intérieur et l'extérieur du réseau
• Inclure des tests de la couche applicative qui traitent, au minimum, les vulnérabilités listées dans l'Exigence 6.2.4 (qui correspond étroitement au OWASP Top 10)
• Inclure des tests de pénétration au niveau réseau couvrant toutes les fonctions réseau et systèmes d'exploitation

Sous la version 3.2.1, les organisations pouvaient se contenter d'une méthodologie faisant référence aux standards de l'industrie en termes généraux. Sous la version 4.0, le QSA évaluera si votre méthodologie documentée traite spécifiquement chacun de ces éléments et si vos tests réels ont suivi la méthodologie documentée. Une référence vague aux « meilleures pratiques de l'industrie » ne passera pas l'examen.

Périmètre et criticité élargis

L'Exigence 11.4.2 spécifie que les tests d'intrusion internes doivent être effectués sur tous les systèmes concernés. La définition de « concerné » sous PCI DSS 4.0 inclut tout système qui stocke, traite ou transmet des données de titulaires de cartes, tout système qui se trouve dans le même segment réseau que les systèmes CDE, et tout système qui pourrait affecter la sécurité du CDE. C'est plus large que ce que de nombreuses organisations réalisent, et le sous-dimensionnement du périmètre du test d'intrusion est l'une des constatations les plus courantes rapportées par les QSA.

L'Exigence 11.4.3 couvre les tests d'intrusion externes, exigeant des tests du périmètre accessible depuis l'extérieur du CDE et de tout système critique accessible depuis l'extérieur du réseau de l'organisation.

Tests de segmentation : désormais plus rigoureux

L'Exigence 11.4.5 traite de la vérification de la segmentation réseau -- des tests qui confirment que les contrôles de segmentation réseau isolent efficacement le CDE des systèmes hors périmètre. Sous la version 3.2.1, les tests de segmentation étaient requis mais la méthodologie était définie de manière vague. Sous la version 4.0 :

• Les tests de segmentation doivent confirmer que les méthodes de segmentation sont opérationnelles et efficaces
• Les tests doivent vérifier que les systèmes hors périmètre ne peuvent pas communiquer avec les systèmes dans le CDE
• Pour les fournisseurs de services, les tests de segmentation doivent être effectués tous les six mois (pas seulement annuellement)
• Les tests doivent avoir lieu après tout changement des contrôles ou méthodes de segmentation

L'exigence semestrielle pour les fournisseurs de services est particulièrement significative. Les organisations qui effectuaient une vérification annuelle de la segmentation sous la version 3.2.1 doivent maintenant doubler leur fréquence de test, ce qui a des implications significatives en termes de coûts et d'opérations.

Exigences à date future (désormais obligatoires)

Plusieurs exigences de pentesting ont été désignées comme « à date future » lors de la publication de PCI DSS 4.0, ce qui signifie qu'elles étaient des meilleures pratiques jusqu'au 31 mars 2025, après quoi elles sont devenues obligatoires. Elles sont maintenant pleinement applicables :

• 11.4.1 : L'exigence de méthodologie documentée décrite ci-dessus.
• 11.4.6 : Pour les fournisseurs de services, le pentesting doit spécifiquement confirmer que l'approche personnalisée produit les contrôles de sécurité attendus. C'est un territoire nouveau -- l'approche personnalisée est un concept de PCI DSS 4.0 qui permet aux organisations de répondre aux objectifs de sécurité par des contrôles alternatifs, mais ces contrôles alternatifs doivent être validés par des tests.
• 11.4.7 : Les fournisseurs de services multi-locataires doivent permettre le pentesting par leurs clients. Cela signifie que si vous fournissez une infrastructure partagée aux commerçants, vous devez avoir des processus et des politiques qui permettent à vos locataires de conduire (ou de faire conduire en leur nom) des tests d'intrusion de leurs environnements au sein de votre infrastructure.

La distinction scan vs pentest : critique pour la conformité

PCI DSS 4.0 est exceptionnellement clair sur la différence entre le scan de vulnérabilités et le pentesting, et confondre les deux est l'un des moyens les plus rapides d'échouer à une évaluation.

Les scans de vulnérabilités (Exigences 11.3.1 et 11.3.2) sont des évaluations automatisées qui identifient les vulnérabilités connues, les mauvaises configurations et les correctifs manquants sur les systèmes. PCI DSS exige :

• Des scans de vulnérabilités internes au moins trimestriels
• Des scans de vulnérabilités externes au moins trimestriels par un Fournisseur de Scan Approuvé (ASV)
• Des scans après tout changement significatif

Les tests d'intrusion (Exigence 11.4) vont au-delà du scan pour inclure l'exploitation active. Le standard déclare explicitement que le pentesting implique « la tentative d'exploitation des vulnérabilités » pour « déterminer si un accès non autorisé ou une autre activité malveillante est possible ». Un test d'intrusion qui identifie uniquement les vulnérabilités sans tenter l'exploitation ne satisfait pas l'Exigence 11.4.

Cette distinction est importante car certains fournisseurs commercialisent le scan de vulnérabilités comme du pentesting. Un rapport de scan automatisé, quelle que soit son exhaustivité, ne satisfait pas l'exigence de pentesting. Votre QSA examinera la méthodologie et les preuves du rapport pour déterminer si une exploitation réelle a été tentée. Si les preuves montrent uniquement une sortie de scanner sans tentatives d'exploitation, l'exigence sera marquée comme non satisfaite.

L'implication pour les plateformes de tests automatisés par IA est importante : la plateforme doit démontrer une validation d'exploitation, pas seulement une détection de vulnérabilités, pour satisfaire les exigences de pentesting PCI DSS. Les tests automatisés de ThreatExploit incluent des tentatives d'exploitation actives avec capture de preuves, ce qui est spécifiquement conçu pour répondre à cette exigence.

Analyse exigence par exigence

Voici un détail de chaque exigence de pentesting sous PCI DSS 4.0, ce que le QSA évalue et comment la satisfaire.

Exigence 11.4.1 : Méthodologie et périmètre

Ce qu'elle dit : Une méthodologie de pentesting est définie, documentée et mise en œuvre, et inclut des approches de pentesting reconnues par l'industrie, une couverture de l'ensemble du périmètre CDE et des systèmes critiques, des tests depuis l'intérieur et l'extérieur du réseau, et des tests pour valider les contrôles de segmentation et de réduction du périmètre.

Ce que le QSA évalue :

• Un document de méthodologie écrit existe-t-il ?
• Fait-il référence à un standard reconnu (PTES, OSSTMM, OWASP, NIST) ?
• Le périmètre couvre-t-il tous les systèmes concernés ?
• Y a-t-il des preuves que les tests ont suivi la méthodologie documentée ?

Comment la satisfaire : Maintenez un document de politique de pentesting qui spécifie la méthodologie, le processus de définition du périmètre, la fréquence des tests et les exigences de rapport. Assurez-vous que votre prestataire de test (qu'il soit interne, externe ou automatisé) suit et documente le respect de cette méthodologie.

Exigence 11.4.2 : Tests d'intrusion internes

Ce qu'elle dit : Les tests d'intrusion internes sont effectués selon la méthodologie définie au moins une fois tous les 12 mois et après tout changement significatif d'infrastructure ou d'application.

Ce que le QSA évalue :

• Des tests internes ont-ils été effectués au cours des 12 derniers mois ?
• Le rapport de test couvre-t-il tous les systèmes internes concernés ?
• Les tests ont-ils été répétés après des changements significatifs ?
• Les vulnérabilités identifiées ont-elles été corrigées et retestées ?

Comment la satisfaire : Effectuez des tests d'intrusion internes au minimum annuellement. Documentez ce qui constitue un « changement significatif » dans votre méthodologie. Conservez les preuves que des retests ont eu lieu après des changements majeurs d'infrastructure, des déploiements d'applications ou des modifications réseau.

Exigence 11.4.3 : Tests d'intrusion externes

Ce qu'elle dit : Les tests d'intrusion externes sont effectués selon la méthodologie définie au moins une fois tous les 12 mois et après tout changement significatif d'infrastructure ou d'application.

Ce que le QSA évalue :

• Mêmes critères que 11.4.2, appliqués aux tests externes
• L'ensemble du périmètre externe a-t-il été testé ?
• Tous les systèmes accessibles depuis l'extérieur ont-ils été inclus ?

Comment la satisfaire : Effectuez des tests d'intrusion externes au minimum annuellement. Assurez-vous que le périmètre inclut tous les systèmes exposés à Internet dans le CDE : applications web, API, points d'accès VPN, passerelles de messagerie et tout autre service accessible depuis l'extérieur.

Exigence 11.4.4 : Remédiation et retest

Ce qu'elle dit : Les vulnérabilités exploitables et les faiblesses de sécurité découvertes lors du pentesting sont corrigées, et les tests sont répétés pour vérifier les corrections.

Ce que le QSA évalue :

• Y a-t-il un plan de remédiation pour chaque constatation ?
• Les constatations critiques et élevées ont-elles été remédiées ?
• Y a-t-il des preuves de retest après remédiation ?
• Les preuves de retest sont-elles documentées dans le rapport ?

Comment la satisfaire : Établissez un flux de remédiation avec des SLA définis par sévérité (ex. : critique : 15 jours, élevé : 30 jours, moyen : 90 jours). Après remédiation, effectuez un retest et documentez les résultats. Les tests automatisés par IA rendent le retest efficace et immédiat -- vous pouvez valider un correctif en quelques heures après le déploiement plutôt que de planifier un engagement de suivi.

Exigence 11.4.5 : Vérification de la segmentation

Ce qu'elle dit : Si la segmentation est utilisée pour isoler le CDE, des tests d'intrusion sont effectués pour vérifier que les contrôles de segmentation sont opérationnels et efficaces -- au moins tous les 12 mois, et tous les six mois pour les fournisseurs de services.

Ce que le QSA évalue :

• Y a-t-il une segmentation entre le CDE et les réseaux hors périmètre ?
• Les contrôles de segmentation ont-ils été testés en tentant de pénétrer depuis les segments hors périmètre vers les segments concernés ?
• Pour les fournisseurs de services : deux tests de segmentation ont-ils été effectués au cours des 12 derniers mois ?
• Les tests ont-ils été répétés après des changements des méthodes de segmentation ?

Comment la satisfaire : Planifiez des tests spécifiques de segmentation à la fréquence requise. Les tests doivent inclure des tentatives de franchissement des limites de segments en utilisant l'analyse de routage, le test des règles de pare-feu, les tentatives de VLAN hopping et l'exploitation de tout service qui traverse les segments. Les tests automatisés peuvent effectuer la vérification de la segmentation de manière continue, détectant les dérives de configuration entre les cycles d'évaluation formels.

Exigence 11.4.6 : Validation de l'approche personnalisée (fournisseurs de services)

Ce qu'elle dit : Si l'approche personnalisée est utilisée pour toute exigence PCI DSS, l'approche personnalisée de l'entité est confirmée par un pentesting.

Ce que le QSA évalue :

• L'organisation a-t-elle adopté l'approche personnalisée pour une exigence ?
• Si oui, le pentesting valide-t-il spécifiquement les contrôles alternatifs ?
• Y a-t-il des preuves documentées que les contrôles alternatifs atteignent l'objectif de sécurité visé ?

Comment la satisfaire : Si vous utilisez l'approche personnalisée, travaillez avec votre QSA pour définir des scénarios de pentesting spécifiques qui valident vos contrôles alternatifs. Documentez l'approche de test, les résultats attendus et les résultats réels. Cela nécessite une coordination étroite entre votre programme de test et votre équipe de conformité.

Exigence 11.4.7 : Support de test pour les fournisseurs de services multi-locataires

Ce qu'elle dit : Les fournisseurs de services multi-locataires soutiennent les demandes de pentesting de leurs clients selon les méthodes spécifiées.

Ce que le QSA évalue :

• Le fournisseur de services a-t-il une politique pour soutenir le pentesting des clients ?
• Y a-t-il des procédures définies pour que les clients demandent et conduisent des tests ?
• Des délais et méthodes raisonnables sont-ils spécifiés ?

Comment la satisfaire : Développez une politique de pentesting client qui définit : comment les clients demandent les tests, quelles méthodes sont autorisées (externe uniquement, interne avec coordination, scan automatisé), les procédures de planification et toute restriction nécessaire pour protéger les autres locataires. Communiquez cette politique à tous les clients.

Tests de la couche applicative : l'alignement OWASP

L'Exigence 6.2.4 de PCI DSS 4.0 définit l'ensemble minimum de vulnérabilités applicatives qui doivent être traitées dans le développement, et l'Exigence 11.4 lie le pentesting à ces mêmes catégories de vulnérabilités. Bien que le standard n'utilise pas directement l'expression « OWASP Top 10 », les catégories de vulnérabilités s'alignent étroitement :

• Attaques par injection (SQL, LDAP, XPath, injection de commandes)
• Débordements de tampon
• Stockage cryptographique non sécurisé
• Communications non sécurisées
• Gestion incorrecte des erreurs
• Cross-site scripting (XSS)
• Contrôle d'accès inapproprié (incluant IDOR, navigation forcée, élévation de privilèges)
• Cross-site request forgery (CSRF)
• Authentification et gestion de session défaillantes
• Toutes les autres vulnérabilités identifiées dans l'Exigence 6.2.4

Votre test d'intrusion doit démontrer que chacune de ces catégories de vulnérabilités a été testée. Le QSA examinera le rapport de test pour confirmer la couverture. Si votre rapport montre des tests d'injection SQL mais aucune preuve de tests d'authentification, l'exigence sera partiellement satisfaite au mieux.

C'est un domaine où les plateformes de tests automatisés offrent un avantage significatif. Les tests alimentés par l'IA vérifient systématiquement chaque catégorie de vulnérabilité de la méthodologie avec une cohérence totale, assurant qu'aucune catégorie n'est oubliée en raison de la pression du temps ou d'un oubli humain. Les testeurs manuels, sous les contraintes de temps d'un engagement à périmètre fixe, peuvent prioriser certaines catégories et accorder une attention superficielle aux autres.

Comment le pentesting automatisé par IA satisfait PCI DSS 4.0

Correspondance du pentesting automatisé par IA avec chaque exigence PCI DSS 4.0 :

Exigence	Ce qu'elle exige	Comment l'automatisation la satisfait
11.4.1	Méthodologie documentée	Documentation de la méthodologie de la plateforme basée sur OWASP/PTES
11.4.2	Tests internes annuels + après changements	Tests internes à la demande, déclenchés par CI/CD ou planification
11.4.3	Tests externes annuels + après changements	Tests externes à la demande avec disponibilité le jour même
11.4.4	Remédiation et retest	Retest immédiat après corrections avec preuves avant/après
11.4.5	Vérification de segmentation (semestrielle pour les FS)	Tests de segmentation automatisés selon un calendrier configurable
11.4.6	Validation d'approche personnalisée	Scénarios de test configurables pour les contrôles personnalisés
11.4.7	Support de test multi-locataires	Capacité de test en libre-service pour les locataires

L'avantage clé est la fréquence. PCI DSS 4.0 fixe des fréquences minimales de test (annuellement pour la plupart, semestriellement pour la segmentation des fournisseurs de services), mais le standard exige également des tests après les « changements significatifs ». Dans les environnements de développement modernes où le code est déployé de manière hebdomadaire ou quotidienne, définir et suivre les changements significatifs est un défi opérationnel. Les tests automatisés continus contournent entièrement ce problème : si vous testez en continu, chaque changement est testé, et le déclencheur de « changement significatif » devient sans objet.

Liste de vérification de préparation pour les évaluations 2026

Utilisez cette liste de vérification pour évaluer votre état de préparation aux exigences de pentesting PCI DSS 4.0 pour votre prochaine évaluation.

Documentation

• Méthodologie de pentesting écrite faisant référence à PTES, OSSTMM, OWASP ou NIST SP 800-115
• Périmètre défini correspondant à la frontière actuelle du CDE et à tous les systèmes concernés
• Définition du « changement significatif » qui déclenche un retest
• SLA de remédiation par sévérité de vulnérabilité
• Calendrier de test respectant les exigences minimales de fréquence

Couverture des tests

• Tests d'intrusion internes complétés au cours des 12 derniers mois
• Tests d'intrusion externes complétés au cours des 12 derniers mois
• Vérification de la segmentation complétée (dans les 12 mois pour les commerçants, 6 mois pour les fournisseurs de services)
• Tests de la couche applicative couvrant toutes les catégories de vulnérabilités de l'Exigence 6.2.4
• Tests de la couche réseau couvrant tous les systèmes d'exploitation et fonctions réseau dans le périmètre
• Retests effectués après tous les changements significatifs d'infrastructure ou d'application depuis la dernière évaluation

Qualité des preuves

• Les rapports de test incluent des preuves d'exploitation, pas seulement l'identification de vulnérabilités
• Scores CVSS attribués à toutes les constatations
• Preuves de remédiation documentées pour toutes les constatations critiques et élevées
• Résultats de retest confirmant l'efficacité de la remédiation
• Résumé exécutif et sections méthodologiques adaptés à l'examen du QSA
• Déclaration de périmètre claire dans chaque rapport correspondant à la frontière du CDE

Spécifique aux fournisseurs de services

• Tests de segmentation semestriels complétés (deux tests au cours des 12 derniers mois)
• Contrôles d'approche personnalisée validés par pentesting (si applicable)
• Politique de support de pentesting client documentée et communiquée (si multi-locataires)

Améliorations de processus pour 2026

• Évaluer le pentesting automatisé par IA pour augmenter la fréquence de test au-delà des minimums
• Mettre en œuvre des tests continus pour répondre aux exigences de test des « changements significatifs »
• Intégrer le pentesting dans le pipeline de gestion des changements et de déploiement
• Établir un flux de retest automatisé pour une validation plus rapide de la remédiation
• Examiner et mettre à jour le document de méthodologie de test au moins annuellement

Le plancher de conformité vs le plafond de sécurité

PCI DSS 4.0 fixe un plancher pour le pentesting -- des exigences minimales qui doivent être satisfaites pour atteindre la conformité. Atteindre ce plancher est nécessaire. Mais comme nous le discutons en détail dans notre article sur le pentesting de conformité vs les véritables tests de sécurité, les minimums de conformité sont conçus pour établir une base de référence, pas pour fournir une sécurité complète.

Les organisations qui traitent les exigences de pentesting PCI DSS comme le plafond plutôt que le plancher laissent un risque significatif non traité. Les exigences ne couvrent pas les tests des systèmes adjacents aux paiements qui sont hors périmètre mais pourraient servir de pivots d'attaque. Elles n'exigent pas de tests des failles de logique métier spécifiques aux flux de paiement. Elles ne prescrivent pas de tests d'ingénierie sociale ni d'évaluations de sécurité physique.

Les organisations de paiement les plus sécurisées utilisent les exigences PCI DSS comme point de départ et étendent les tests pour couvrir leur profil de risque réel. Le pentesting automatisé par IA rend cela économiquement faisable car le coût marginal des tests au-delà du minimum de conformité est négligeable lorsque les tests sont automatisés. Exécuter un pentest contre les systèmes hors périmètre en parallèle du test obligatoire dans le périmètre coûte peu d'effort supplémentaire lorsque la plateforme gère les deux simultanément.

PCI DSS 4.0 a considérablement relevé le plancher du pentesting par rapport à la version 3.2.1. Atteindre ce nouveau plancher nécessite une meilleure documentation, un périmètre plus large, des tests plus fréquents et des preuves plus rigoureuses. Les organisations qui se préparent maintenant -- avec des méthodologies documentées, des capacités de test automatisé et des flux de remédiation -- navigueront sereinement dans leurs évaluations 2026. Celles qui attendent trouveront l'écart entre leurs pratiques actuelles et les nouvelles exigences plus large que prévu.