En bref : portée de l'auto-évaluation SAQ D pour les marchands e-commerce
- Chaque marchand veut être sur SAQ A. La plupart appartiennent à SAQ D sans le savoir. Si votre site charge un script qui peut toucher un champ de paiement, vous n'êtes pas sur le formulaire court, quoi qu'en dise le pitch commercial.
- SAQ D couvre les 12 exigences PCI DSS et fait plus de 90 pages à remplir. Depuis que PCI DSS 4.0.1 est devenu obligatoire en mars 2025, 6.4.3 et 11.6.1 sont dans le périmètre de chaque marchand SAQ D, et les exemptions SAQ A de janvier 2025 ne s'appliquent pas.
- Si vous acceptez des données de carte sur des systèmes que vous contrôlez, mélangez les moyens de paiement ou stockez des données titulaires, complétez SAQ D et construisez dès maintenant l'inventaire de scripts 6.4.3 et la surveillance d'en-têtes 11.6.1. Si un iframe entièrement hébergé est votre seule intégration et qu'aucun script first-party ne peut le toucher, confirmez avec votre acquéreur si SAQ A convient.
Le SAQ D est le questionnaire d'auto-évaluation qui couvre tout ce que les SAQ plus courts ne couvrent pas. Il s'applique aux commerçants et aux prestataires de services dont l'environnement de paiement est trop large pour entrer dans les questionnaires plus restreints. Si votre entreprise accepte des données de carte directement sur un système que vous contrôlez, le SAQ D est probablement le formulaire que vous remplissez chaque année.
Qui doit remplir le SAQ D
Le PCI Security Standards Council publie plusieurs variantes de SAQ, chacune correspondant à un profil de commerçant précis :
| SAQ | Concerne |
|---|---|
| A | E-commerce entièrement externalisé ; les données de carte ne touchent jamais les systèmes du commerçant ; iframe hébergé ou redirection uniquement |
| A-EP | Commerçant e-commerce dont le site web influe sur la sécurité de la page de paiement (chargement de scripts, iframes avec accès aux scripts de même origine) |
| B | Machines à empreinte ou terminaux autonomes à numérotation sortante, sans stockage électronique |
| B-IP | Terminaux autonomes connectés en IP, sans stockage électronique |
| C | Application de paiement connectée à Internet, sans stockage électronique |
| C-VT | Terminaux virtuels accessibles via un navigateur, sans stockage électronique |
| P2PE | Uniquement les terminaux de paiement matériels P2PE référencés PCI |
| D | Tous les autres qui ne remplissent pas les conditions ci-dessus |
C'est dans cette dernière ligne que se retrouve la majeure partie de l'e-commerce. Tout commerçant qui accepte des données de carte sur ses propres systèmes, utilise plusieurs modes de paiement ou stocke des données de titulaires de carte remplit le SAQ D. Les prestataires de services en dessous du niveau 1 utilisent également le SAQ D.
Ce que couvre le SAQ D
Le SAQ D inclut l'intégralité des 12 exigences PCI DSS :
- Installer et maintenir des contrôles de sécurité réseau
- Appliquer des configurations sécurisées à tous les composants du système
- Protéger les données de compte stockées
- Protéger les données de titulaires de carte par une cryptographie forte pendant la transmission
- Protéger tous les systèmes et réseaux contre les logiciels malveillants
- Développer et maintenir des systèmes et des logiciels sécurisés
- Restreindre l'accès aux composants du système et aux données de titulaires de carte selon le besoin d'en connaître
- Identifier les utilisateurs et authentifier l'accès aux composants du système
- Restreindre l'accès physique aux données de titulaires de carte
- Journaliser et surveiller tous les accès aux composants du système et aux données de titulaires de carte
- Tester régulièrement la sécurité des systèmes et des réseaux
- Soutenir la sécurité de l'information par des politiques et des programmes organisationnels
Chaque exigence comporte plusieurs sous-exigences et attentes en matière de preuves. Le modèle actuel du SAQ D fait plus de 90 pages, rien que pour le remplir.
Là où le SAQ D se complique : les contrôles côté client
Les exigences 6.4.3 et 11.6.1 sont devenues obligatoires avec PCI DSS 4.0.1 en mars 2025. Toutes deux s'appliquent pleinement aux commerçants en SAQ D et portent sur le contrôle des scripts côté client sur les pages de paiement :
- 6.4.3 : tenir un inventaire de chaque script chargé sur les pages de paiement, documenter la justification métier de chacun, vérifier l'intégrité, détecter les changements non autorisés
- 11.6.1 : surveiller les en-têtes HTTP sur les pages de paiement, détecter les changements non autorisés et alerter
La plupart des commerçants qui remplissent le SAQ D pour la première fois sous la version 4.0.1 n'ont aucun élément de preuve pour l'une ou l'autre de ces exigences. Notre guide pratique pour se conformer aux exigences PCI 6.4.3 et 11.6.1 détaille à quoi doivent ressembler les preuves.
La mise à jour de janvier 2025 du SAQ A a introduit des exemptions très limitées aux exigences 6.4.3 et 11.6.1, mais ces exemptions ne s'appliquent pas au SAQ D. Si vous relevez du SAQ D, les deux exigences sont dans le périmètre.
En quoi le SAQ D diffère du SAQ A
Le SAQ A est court (moins de 30 pages) parce qu'il part du principe que les données de carte ne touchent jamais vos systèmes. Le SAQ D est long parce qu'il ne fait pas cette hypothèse. Si vous ne savez pas quel SAQ vous concerne, notre guide comment devenir une entreprise PCI DSS SAQ A passe en revue les critères du formulaire plus restreint. Si vous ne pouvez pas tous les remplir, la réponse est le SAQ D.
Une liste de vérification avant de commencer le SAQ D
- Confirmez que le SAQ D est bien le bon formulaire pour votre environnement (parlez-en à votre acquéreur en cas de doute)
- Réalisez votre schéma de périmètre couvrant chaque système qui stocke, traite ou transmet des données de titulaires de carte
- Constituez l'inventaire des scripts pour chaque page de paiement (6.4.3)
- Mettez en place la surveillance des en-têtes HTTP pour les pages de paiement (11.6.1)
- Rassemblez les preuves pour chacune des 12 exigences : exports de configuration, captures d'écran, échantillons de journaux, politiques
- Prévoyez du temps pour une revue interne avant l'attestation finale
Où cside intervient
cside gère directement les preuves pour les exigences 6.4.3 et 11.6.1. Inventaire continu des scripts, étiquetage de la justification métier, surveillance d'intégrité, détection des changements d'en-têtes et historique des alertes proviennent de la plateforme, si bien que ces deux exigences passent de « nous avons l'intention de nous conformer » à « voici les preuves ».
Pour une présentation plus détaillée de ce que produit le tableau de bord de conformité et de la façon dont il se rattache aux questions du SAQ D, consultez le guide de conformité aux exigences 6.4.3 et 11.6.1 de PCI DSS 4.0.1.
