ISO 27001 · ISO 42001 · RGPD · PCI DSS · Loi 25

PCI DSS Analyse de risque ciblée : un modèle qu’une PME peut réellement remplir

PCI DSS Analyse de risque ciblée : un modèle qu’une PME peut réellement remplir

PCI DSS v4.0.1 laisse une entité choisir la fréquence de certaines activités — mais seulement si une analyse de risque ciblée justifie le choix. La TRA n’est pas de la paperasse facultative ; c’est le document que l’évaluateur consulte pour confirmer que votre cadence correspond à votre risque. Sans elle, la fréquence est non conforme, quoi que vous fassiez réellement.

PCI DSS v4.0 a introduit l’analyse de risque ciblée (TRA), définie à l’exigence 12.3.1. Chaque fois qu’une exigence dit qu’une activité est effectuée « à la fréquence définie dans l’analyse de risque ciblée de l’entité, » l’entité doit produire une TRA documentant l’analyse derrière la fréquence choisie. L’Information Supplement de PCI SSC (Targeted Risk Analysis Guidance, novembre 2023) est explicite sur ce que la TRA doit contenir et comment l’évaluateur la révise.

Cet article donne les éléments requis, un modèle à remplir qu’une PME peut utiliser, et un exemple travaillé pour l’exigence 11.6.1 (fréquence de détection d’altération de la page de paiement, référencée dans l’explicateur 6.4.3 / 11.6.1).

Quand une TRA est requise

Une TRA de fréquence d’activité est requise seulement quand une exigence PCI DSS le dit explicitement — « effectuée conformément à tous les éléments spécifiés à l’exigence 12.3.1. » Le guide PCI SSC liste les exigences qui en déclenchent une, avec fréquences suggérées :

ExigenceActivitéFréquence suggérée
5.2.3.1Évaluation périodique des composants identifiés non à risque de malwareAu moins tous les 6 mois
5.3.2.1Analyses périodiques de malware (si utilisées pour 5.3.2)Au moins quotidiennement
7.2.5.1Revue d’accès des comptes d’application et systèmeAu moins tous les 6 mois
8.6.3Changement périodique des mots de passe de comptes d’application/systèmeAu moins tous les 3 mois
9.5.1.2.1Inspections périodiques des dispositifs POIAu moins mensuellement
10.4.2.1Revue périodique des journaux des autres composants systèmeAu moins hebdomadairement
11.3.1.1Traitement des autres vulnérabilités (non critiques/élevées)Moyenne ≤3 mois, Faible ≤6 mois
11.6.1Mécanisme de détection de changement/altération de la page de paiementAu moins hebdomadairement
12.10.4.1Formation périodique du personnel de réponse aux incidentsAu moins annuellement + à l’embauche

Même si vous suivez la fréquence suggérée, une TRA reste requise pour documenter et justifier le choix.

Deux règles qui piègent les PME

*Une TRA ne peut pas servir à effectuer une activité moins souvent que l’exigence ne le stipule.* Si une exigence dit « au moins hebdomadairement, » votre TRA ne peut pas justifier mensuel. Pour descendre sous un minimum stipulé, vous devez utiliser l’approche personnalisée (exigence 12.3.2, une TRA différente) ou un contrôle compensatoire documenté.

*Une TRA n’est pas nécessaire pour effectuer une activité plus souvent.* Si l’exigence dit hebdomadaire et que vous faites le contrôle quotidiennement, aucune TRA requise — faites-le simplement.

La TRA se situe entre les deux : elle justifie une fréquence à ou au-dessus du plancher de l’exigence, calibrée à votre risque.

Les éléments qu’une TRA doit contenir (exigence 12.3.1)

Selon le guide PCI SSC, une TRA de fréquence identifie, pour chaque exigence applicable :

1. Les actifs spécifiques que l’exigence protège (ex. fichiers journaux, identifiants, une page de paiement). 2. La/les menace(s) ou conséquence(s) que l’exigence contrerait (ex. malware, intrus non détecté, mauvais usage d’identifiants, skimmer). 3. Les facteurs qui contribuent à la vraisemblance et/ou à l’impact — tout ce qui augmente la vulnérabilité d’un actif face à la menace (exposition à des réseaux non fiables, complexité de l’environnement, fort taux de rotation du personnel) et la criticité des composants ou le volume/sensibilité des données. 4. La fréquence choisie, avec justification de la façon dont elle traite le risque identifié. 5. La cadence de revue — la TRA est revue au moins tous les 12 mois et lors de changements pouvant impacter le risque, et mise à jour au besoin.

Le rôle de l’évaluateur est de confirmer que tous les éléments sont documentés et que l’entité a justifié comment la fréquence traite son risque. Une fréquence sans raisonnement documenté échoue.

Le modèle

Une ligne par exigence applicable. PCI SSC fournit un modèle d’exemple (PCI DSS v4.x Sample Template: Targeted Risk Analysis for Activity Frequency) ; son usage n’est pas requis, mais tous ses éléments doivent être présents.

ChampCe qu’on y met
ExigenceLe numéro d’exigence PCI DSS (ex. 11.6.1)
ActivitéL’activité dont on fixe la fréquence
Actif(s) protégé(s)Les actifs spécifiques
Menace(s) / conséquence(s)Ce que l’activité détecte ou prévient
Facteurs de vraisemblanceExposition, complexité, rotation, etc.
Facteurs d’impactCriticité des composants, sensibilité/volume des données
Fréquence choisieLa cadence, à ou au-dessus du plancher de l’exigence
JustificationUn paragraphe liant la fréquence aux facteurs ci-dessus
Date de revueAu moins annuellement ; déclencheur sur changement significatif
ResponsableQui maintient cette entrée de TRA

Un exemple travaillé : détection d’altération 11.6.1 de la page de paiement

Une PME exploite sa propre page de paiement e-commerce (SAQ A-EP) et utilise la surveillance synthétique plus le rapport de violations CSP pour 11.6.1. L’entrée de TRA :

ChampEntrée
Exigence11.6.1
ActivitéDétection de changement et d’altération des en-têtes HTTP et du contenu des scripts de la page de paiement tels que reçus par le navigateur du consommateur
Actif(s) protégé(s)La page de paiement telle que rendue dans le navigateur du client ; les données de porteur que le formulaire collecte
Menace(s) / conséquence(s)Skimming façon Magecart ; injection ou altération non autorisée de script ; relâchement de CSP
Facteurs de vraisemblanceLa page charge des scripts tiers (tag manager, analytique) — multiples vecteurs d’injection ; site e-commerce exposé internet 24/7 ; un seul développeur commit sur la page
Facteurs d’impactUn skimmer réussi exfiltre des PAN pendant toute la durée où il tourne ; violation PCI DSS directe et conséquences de marque de carte si non détecté
Fréquence choisieQuotidienne (surveillance synthétique une fois par jour ; violations CSP rapportées en quasi-temps réel et revues quotidiennement)
JustificationLa page est exposée internet avec plusieurs vecteurs de scripts tiers, donc le délai de détection fait directement varier l’exposition. La surveillance synthétique quotidienne capte un script altéré sous ~24 heures, limitant la fenêtre de violation ; le rapport de violations CSP fournit une alerte quasi-temps réel sur le schéma d’injection le plus courant. Quotidien est au-dessus du plancher hebdomadaire et correspond à l’exposition 24/7.
Date de revueAnnuellement, et lors de tout changement à l’inventaire de scripts de la page de paiement ou d’un nouveau script tiers
ResponsableResponsable IT

Cette entrée fait quelques paragraphes. Elle nomme les actifs, les menaces, les facteurs qui montent la fréquence, et lie la cadence choisie au risque. Un évaluateur qui la lit voit pourquoi quotidien et non hebdomadaire — ce qui est tout le but.

Trois erreurs à éviter

  • **TRAs copiées-collées.** Des entrées identiques sur des exigences sans rapport signalent que l’analyse n’a pas été faite. Chaque exigence a des actifs et menaces différents ; les facteurs doivent le refléter.
  • **Fréquence sous le plancher.** Une TRA ne peut pas abaisser un minimum stipulé. Si vous avez besoin d’une cadence inférieure, c’est l’approche personnalisée ou un contrôle compensatoire, pas cette TRA.
  • **Une fois pour toutes.** Le guide exige une revue annuelle et une mise à jour sur changement significatif. Une TRA datée de trois ans est non conforme quel que soit son contenu.

Comment cela s’intègre dans la série

La TRA est le document derrière chaque ligne « à la fréquence définie dans l’analyse de risque ciblée de l’entité » de PCI DSS — y compris la fréquence 11.6.1 référencée dans l’explicateur 6.4.3 / 11.6.1 et la cadence de revue des journaux impliquée par vos décisions de réduction de périmètre. C’est l’un des artefacts dont votre dépôt de SAQ dépend. Si vous exploitez aussi ISO 27001, la TRA est plus étroite que votre analyse de risque ISO 27001 — c’est une tranche spécifique au paiement, centrée sur la fréquence.

Que faire ensuite

Listez quelles exigences déclenchant une TRA dans le tableau ci-dessus s’appliquent à vous (la plupart des PME en ont 3–5). Remplissez une ligne par exigence avec le modèle, en commençant par celle dont vous êtes le moins sûr de la fréquence. Liez chaque fréquence aux facteurs, fixez une date de revue, et signez. C’est une TRA 12.3.1 conforme — quelques heures, pas un engagement de conseil.

Vous voulez une revue de vos TRAs avant votre évaluation ? Réservez une **revue de réduction de périmètre PCI + préparation** de 30 min — nous vérifions chaque entrée de TRA contre les éléments 12.3.1, signalons les fréquences qui ne survivront pas à l’évaluateur, et vous remettons les corrections. Bilingue FR/EN, sans obligation.

/fr/pci-dss-evaluation/

Obtenez votre évaluation de préparation gratuite

Cartographiez vos contrôles, identifiez vos écarts de conformité et sécurisez vos systèmes avant l'audit.

À propos de l'auteur

Articles liés

Rechercher

Restez protégé

Recevez chaque semaine des analyses de sécurité et des conseils concrets dans votre boîte de réception.