PREUVE / Feuillet de consultation

À quelle fréquence refaire un pentest applicatif SaaS ?

Mis à jour le 1er octobre 2026

Ce qu’aucun texte ne fixe pour un éditeur SaaS

« La loi impose un pentest annuel » est faux pour un éditeur SaaS en général. Les textes cités dans les clauses de grands comptes parlent de tests réguliers, sans rythme :

• RGPD, article 32.1.d : une procédure pour tester, analyser et évaluer « régulièrement » l’efficacité des mesures de sécurité.
• NIS 2, article 21.2.f : des politiques et procédures pour évaluer l’efficacité des mesures de gestion des risques.
• Règlement d’exécution (UE) 2024/2690, annexe 6.5.2 (fournisseurs d’informatique en nuage et autres entités) : l’entité détermine, sur la base de son analyse de risques, la nécessité, la portée, la fréquence et le type de tests de sécurité.
• Cloud Controls Matrix v4 de la Cloud Security Alliance, contrôle TVM-06 : des procédures pour réaliser périodiquement des tests d’intrusion par des tiers indépendants, sans durée.

À retenir. Aucun de ces textes ne définit non plus une durée de validité d’un rapport. Quand un client écrit « de moins de douze mois », c’est sa clause qui parle.

Les rythmes qui existent vraiment

Un rythme choisi vous engage autant. SecNumCloud montre la forme d’un rythme imposé : il est écrit, et il précise qui réalise le test. Un rythme que vous choisissez vous engage autant : si votre processus interne annonce « un pentest par an » dans un cadre ISO 27001 ou dans un rapport SOC 2, l’auditeur contrôlera que vous le faites : ne promettez pas un rythme que votre équipe ne tiendra pas (voir pentest, SOC 2 et ISO 27001).

Le changement de surface d’attaque, vrai déclencheur

Le règlement 2024/2690 évoque des tests lors de la mise en place et après des mises à niveau ou modifications d’infrastructures ou d’applications jugées importantes. SecNumCloud parle de changement majeur. Ce qui rend une évolution « importante » pour un SaaS :

• une nouvelle authentification (SSO, fournisseur d’identité, MFA) ;
• un nouveau modèle de droits, un nouveau rôle, une délégation ;
• une refonte de l’isolation multi-tenant ou du stockage partagé ;
• une API exposée (REST, GraphQL, webhooks, API partenaires) ;
• une intégration qui échange des données avec un tiers ;
• un changement d’hébergeur ou de fournisseur d’identité ;
• un module traitant un type de données plus sensible.

À l’inverse, un changement d’interface, une mise à jour de dépendance sans incidence sur les droits ou un correctif de texte ne déplacent pas une frontière de confiance.

Caler le test sur le cycle de release

Une mission par an, sans lien avec les livraisons, produit un rapport sur une version qui n’existe plus au moment de la remise. Le calage suit la nature des changements :

Mettez en place trois éléments :

1. Un registre des changements de surface d’attaque tenu par les équipes produit : date, version, nature (authentification, droits, API, données), périmètre touché.
2. Une règle de déclenchement écrite dans la politique de sécurité : quelles entrées du registre exigent un test ciblé, lesquelles une mission complète.
3. Une cadence des contrôles continus : analyse de dépendances et tests statiques à chaque livraison, tests dynamiques authentifiés à intervalles réguliers, détection mensuelle si un questionnaire l’exige (voir scan ou pentest). Ils comblent l’intervalle entre deux missions sans remplacer l’analyse humaine des scénarios.

Lire une clause qui parle de validité

Avant de planifier, faites préciser au client :

• la date retenue : début du test, fin du test ou remise du rapport ;
• la version de l’application visée : celle testée ou la version en production à la date de la vente ;
• si un test ciblé sur une partie du produit compte, ou si seul un test complet est recevable ;
• si un même rapport peut servir plusieurs clients, à condition que le périmètre soit identique et que les droits de diffusion le permettent (voir partager un rapport de pentest).

Clause « annuelle ». Une clause « annuelle » sans définition se règle par écrit, avant la commande, pas à la veille de l’échéance.

Construire le calendrier de l’année

Partez des dates qui imposent un rythme : renouvellement des contrats de vos grands comptes, audit de surveillance ISO 27001 ou période d’observation SOC 2 le cas échéant, revue annuelle SecNumCloud si vous visez la qualification. Reculez ensuite depuis chacune : le test, la restitution, les corrections, le retest. Le planificateur de pentest et de retest calcule ces jalons à rebours à partir des durées que vous saisissez. Pour les analyses de fond, voir aussi le guide sur les exigences clients et l’analyse du règlement TLPT.