2026-07-21 · GUIDE · L'équipe Offensive Technology

À quelle fréquence devriez-vous réaliser un test d'intrusion ?

Réponse courte : au moins une fois tous les 12 mois, et à nouveau après toute modification significative des systèmes dans le périmètre. Cette règle en deux volets, calendrier plus changements, constitue le minimum pratique pour tous les référentiels auxquels un acheteur est confronté. Seule la norme PCI DSS l'inscrit comme une obligation stricte. SOC 2 et ISO 27001 ne mentionnent aucune fréquence ; ils reposent sur l'analyse des risques, et le rythme annuel est simplement devenu la cadence attendue par les auditeurs. Si votre environnement déploie du code chaque semaine ou traite des données à forte valeur, une fois par an est un seuil minimal à dépasser, pas un objectif à viser.

La question se pose parce que le terme « annuel » ressemble à une règle imposée par une autorité officielle. Pour un référentiel, c'est le cas. Pour les autres, il s'agit d'une convention née autour d'une approche basée sur les risques, et savoir faire la différence vous évite soit de suracheter, soit d'être pris au dépourvu lors d'un audit. Voici ce que dit réellement chacun d'entre eux.

La version courte, par référentiel

Quatre éléments poussent la plupart des acheteurs à réaliser un test : un processeur de paiement, un rapport SOC 2, un certificat ISO ou un formulaire d'assurance. Un seul d'entre eux prescrit une fréquence précise.

La règle en deux volets : calendrier plus changements

Toute réponse crédible concernant la fréquence repose en réalité sur la combinaison de deux règles, et en ignorer une laisse une vulnérabilité.

Le volet calendaire existe parce qu'un test d'intrusion est un exercice ponctuel. Il décrit les systèmes du périmètre pendant la période de test, face aux techniques définies dans les règles d'engagement. De nouvelles classes de vulnérabilités sont découvertes, de nouveaux exploits sont publiés, et vos équipes continuent de déployer du code. Un test annuel remet cette horloge à zéro avant que la vision ne devienne trop obsolète.

Le volet lié aux changements existe parce que le calendrier ne sait pas quand vous avez refondu votre flux d'authentification ou exposé une nouvelle API. Un test réalisé en mars ne vous apprend rien sur le service lancé en juin. C'est pourquoi chaque référentiel sérieux associe « au moins tous les 12 mois » à « et après toute modification significative », et c'est ce second volet que les acheteurs négligent le plus souvent.

Ce qui constitue une modification significative

PCI DSS laisse à chaque organisation le soin de définir et de justifier ce qui est « significatif », mais les exemples du secteur sont constants. Considérez chacun des éléments suivants comme un déclencheur pour tester le périmètre concerné, quelle que soit la date du dernier test annuel :

• Une mise à jour applicative majeure ou la réécriture d'un composant lié à la sécurité.
• Un nouveau service exposé sur Internet, un sous-domaine ou une API qui élargit la surface accessible à un attaquant.
• Une migration vers le cloud, ou une modification substantielle de l'architecture cloud ou de l'IAM.
• Une modification apportée à l'authentification, au SSO (single sign-on) ou à la gestion des sessions.
• Une modification de la segmentation réseau, des règles de pare-feu ou de l'isolation des environnements.
• Une acquisition ou une nouvelle intégration tierce qui intègre la surface d'attaque d'un tiers à la vôtre.

Le point commun est l'exposition. Si le changement modifie ce qui est accessible depuis l'extérieur, la manière d'établir l'identité ou l'emplacement d'une frontière de confiance, le dernier test ne reflète plus la réalité.

Ce que dit réellement chaque référentiel

La norme PCI DSS v4.0 est la plus prescriptive. L'exigence 11.4 impose des tests d'intrusion internes et externes au moins une fois tous les 12 mois et après toute mise à niveau ou modification significative de l'infrastructure ou des applications, selon une méthodologie documentée basée sur une approche reconnue par le secteur telle que le NIST SP 800-115. Lorsque la segmentation est utilisée pour maintenir des systèmes hors de l'environnement des données de cartes de paiement, cette segmentation doit être testée au moins tous les 12 mois pour les commerçants et au moins tous les 6 mois pour les prestataires de services, et les vulnérabilités identifiées doivent faire l'objet d'un nouveau test après correction. C'est l'indication de fréquence la plus claire fournie par l'ensemble des référentiels.

SOC 2 ne mentionne aucune fréquence. Les Trust Services Criteria de l'AICPA sont rédigés sous forme d'objectifs et non de calendriers, il n'y a donc aucune ligne exigeant un test annuel. En pratique, les auditeurs en attendent au moins un par an, planifié pour s'inscrire dans la période d'observation d'un rapport Type 2. Nous avons détaillé quels critères font référence aux tests dans SOC 2 exige-t-il un test d'intrusion ?

L'ISO/IEC 27001 repose explicitement sur les risques. Elle exige la gestion des vulnérabilités techniques et la vérification des mesures de sécurité, et elle associe la fréquence à votre propre appréciation des risques et à votre plan de traitement plutôt qu'à un calendrier fixe. Les organisations certifiées s'accordent sur un test annuel comme socle défendable, les actifs présentant des risques plus élevés étant testés plus fréquemment. La fréquence vous appartient de la justifier, il ne s'agit pas d'une constante imposée.

La cyber-assurance dépend de l'assureur. Certaines polices demandent si vous réalisez des tests régulièrement et considèrent une fréquence « annuelle » comme la réponse attendue ; d'autres ne posent pas du tout la question. La démarche la plus rigoureuse consiste à lire le formulaire de souscription spécifique plutôt que d'émettre des hypothèses, ce qui fait l'objet de notre article ai-je besoin d'un pentest pour une cyber-assurance ?

Quand une fois par an ne suffit pas

Le rythme annuel est un minimum, et certains environnements le dépassent rapidement. Testez plus souvent lorsque :

• Vous déployez en continu. Si la production évolue chaque semaine, un test annuel est obsolète onze mois sur douze. Dans ce cas, les équipes évoluent vers des tests à chaque livraison sur les parcours critiques, ou vers un modèle de test continu, tout en conservant le test annuel complet comme référence.
• Vous détenez des données à forte valeur. Les paiements, les dossiers de santé et les volumes importants de données personnelles augmentent l'impact financier et opérationnel d'une faille, ce qui justifie des tests plus fréquents des systèmes qui y touchent.
• Vous venez d'avoir une alerte. Après un incident, un quasi-incident ou une vulnérabilité critique dans un composant dont vous dépendiez, re-tester la zone concernée coûte moins cher que de supposer que le correctif est parfait.

Rien de tout cela ne remplace le test annuel. Cela s'y superpose, car une mission complète et cadrée menée par des experts seniors offre une profondeur d'analyse bien différente d'un re-test ciblé sur une seule modification.

L'erreur : considérer la date comme le livrable

L'erreur la plus courante concernant la fréquence consiste à traiter le pentest comme un certificat avec une date d'expiration, à l'exécuter au dernier moment et à ne rien corriger de ce qu'il a révélé. Un test commandé uniquement pour cocher une case a tendance à avoir un périmètre trop restreint pour réussir et trop superficiel pour identifier la façon dont un attaquant s'introduit réellement. La date figurant sur le rapport satisfait l'auditeur ; elle ne vous rend pas plus difficile à compromettre.

Entre deux tests programmés, votre exposition évolue continuellement, que vous la surveilliez ou non : un sous-domaine oublié, un service qui n'aurait jamais dû être public, un identifiant compromis dans une fuite de données. Connaître votre surface d'attaque externe en continu est le complément économique d'une analyse périodique approfondie, et il ne s'agit pas du même type d'achat qu'un pentest. Si vous cherchez encore à déterminer de quel service vous avez réellement besoin, contrôle, scan ou pentest complet ? fixe les limites.

À quelle fréquence devriez-vous réaliser un test d'intrusion ? Réponses rapides

À quelle fréquence devriez-vous réaliser un test d'intrusion ?

Au moins une fois tous les 12 mois, et à nouveau après toute modification significative des systèmes dans le périmètre. Cette règle en deux volets constitue le minimum pratique selon l'ensemble des normes suivies par les acheteurs. Les environnements à évolution rapide ou gérant des données à forte valeur devraient effectuer des tests plus fréquents, pouvant aller jusqu'à un test par version ou en continu.

La norme PCI DSS exige-t-elle un test d'intrusion annuel ?

Oui. L'exigence 11.4 de PCI DSS v4.0 impose des tests d'intrusion internes et externes au moins une fois tous les 12 mois et après toute modification significative de l'infrastructure ou des applications. Lorsque la segmentation isole l'environnement des données de cartes de paiement, elle doit être testée au moins tous les 12 mois pour les commerçants et au moins tous les 6 mois pour les prestataires de services.

À quelle fréquence SOC 2 et ISO 27001 exigent-ils un pentest ?

Aucun des deux ne précise de fréquence fixe. Tous deux reposent sur une approche basée sur les risques : SOC 2 laisse l'appréciation des preuves à votre auditeur, tandis qu'ISO 27001 associe les tests à votre évaluation des risques. En pratique, le rythme annuel est devenu la cadence acceptée et attendue par les auditeurs, planifiée pour s'inscrire dans la période d'observation d'un rapport SOC 2 Type 2.

Quand devriez-vous réaliser un test en dehors du cycle annuel ?

Après toute modification significative : une mise à jour majeure, un nouveau service ou sous-domaine exposé sur Internet, une migration cloud, un changement lié à l'authentification ou au SSO, une modification du réseau ou de la segmentation, ou une acquisition. Le dernier test ne décrivait l'environnement que tel qu'il était le jour où il a été réalisé.

Sources

• PCI Security Standards Council, PCI DSS v4.0 Exigence 11.4 (méthodologie de test d'intrusion, fréquence et tests de segmentation).
• AICPA Trust Services Criteria (SOC 2), rédigés sous forme d'objectifs basés sur les risques sans fréquence de test fixe.
• ISO/IEC 27001, gestion des vulnérabilités techniques basée sur les risques et vérification des mesures de sécurité.
• NIST SP 800-115, Technical Guide to Information Security Testing and Assessment, cité comme méthodologie reconnue.

Lectures complémentaires

• SOC 2 exige-t-il un test d'intrusion ?
• Ai-je besoin d'un pentest pour une cyber-assurance ?
• Combien coûte un test d'intrusion ?