Avez-vous besoin de PCI SSF ou de PCI DSS ? Voici la différence

Pour faire simple : PCI SSF concerne le logiciel, et PCI DSS concerne tout le reste.

Si vous développez ou vendez des logiciels liés aux paiements, PCI SSF vous concerne. Si vous stockez, traitez ou manipulez des données de titulaires de carte d'une quelconque façon (votre site web, serveur ou infrastructure d'hébergement inclus), c'est la conformité PCI DSS qui s'applique.

Ces deux référentiels émanent du même organisme (PCI SSC), mais ils répondent à des problématiques très différentes au sein de l'écosystème.

La plupart des gens n'entendent parler que des exigences PCI DSS, car c'est celui qui touche les marchands, les éditeurs SaaS et pratiquement toute entité gérant une page de paiement. Mais PCI SSF ? Celui-là s'adresse aux entreprises qui développent les logiciels de paiement qui font tourner ces systèmes.

Décortiquons tout ça.

Qu'est-ce que PCI SSF ?

PCI SSF signifie Payment Card Industry Software Security Framework. C'est le successeur plus récent et plus flexible de PA-DSS, l'ancienne version.

Là où PCI DSS se concentre sur la protection des données, PCI SSF porte entièrement sur la protection du logiciel qui manipule ces données. Cela englobe le code qui fait tourner votre système de point de vente, votre application de portefeuille mobile ou votre module de paiement en ligne.

PCI SSF repose en réalité sur deux normes :

• Secure Software Standard : se concentre sur la sécurité du logiciel lui-même. Est-il durci ? Protège-t-il les données des titulaires de carte ? Dispose-t-il d'un contrôle d'accès approprié ?
• Secure Software Lifecycle (Secure SLC) : s'intéresse à la façon dont le logiciel est conçu. Votre SDLC (cycle de développement logiciel) est-il sécurisé ? Corrigez-vous rapidement les vulnérabilités ? La sécurité est-elle une priorité de premier plan ?

En d'autres termes : PCI SSF s'intéresse à la façon dont votre logiciel est écrit, maintenu et mis à jour. Si votre base de code est bancale, n'espérez pas passer une évaluation SSF.

À qui s'adresse PCI SSF ?

Voici le test :

• Vendez-vous ou distribuez-vous des applications de paiement ?
• Votre logiciel gère-t-il des paiements directement (même s'il ne stocke jamais de données de titulaires de carte) ?
• Souhaitez-vous figurer sur la liste des logiciels de paiement validés par le PCI SSC ?

Si vous avez répondu oui à l'une de ces questions, les exigences PCI SSF s'appliquent à vous.

Quel type de logiciel est dans le périmètre ?

Si vous développez des outils distribués impliqués dans le flux de données des titulaires de carte, vous êtes probablement dans le périmètre.

Voici ce qui est généralement concerné :

• Systèmes POS : logiciels installés sur les terminaux de caisse physiques.
• Applications de paiement mobile : applications qui acceptent les paiements par carte via une interface mobile.
• SDK de paiement : composants ou bibliothèques de paiement intégrables que les marchands embarquent dans leurs sites ou applications.
• Clients légers : applications légères qui gèrent le routage des transactions ou la saisie utilisateur, mais s'appuient sur des API externes.
• Logiciels de kiosque ou de terminal : tout code alimentant des systèmes accessibles au public qui acceptent des cartes.

Et voici ce qui n'est généralement pas dans le périmètre :

• Applications à usage interne uniquement : outils développés et utilisés au sein de votre propre organisation, sans distribution.
• Systèmes back-office : ERP ou outils d'analyse qui ne touchent pas au flux de paiement.
• Pages hébergées sans logique embarquée : si votre logiciel se contente de rediriger vers ou d'encadrer une page hébergée conforme PCI, cela seul ne déclenche pas nécessairement SSF.

Si votre logiciel est vendu, commercialisé sous marque blanche ou distribué, et qu'il prend en charge les paiements par carte, SSF s'applique presque certainement.

Exemples d'entreprises soumises à PCI SSF :

Voici quelques exemples. Notez que nous n'avons aucune affiliation avec les entreprises citées ci-dessous :

1. Éditeurs de systèmes POS

Exemple : Toast, Lightspeed, Square (pile logicielle matérielle).

• Ils créent des logiciels distribués installés sur des appareils physiques dans les environnements de commerce de détail et d'hôtellerie-restauration.
• Le logiciel accepte les paiements par carte et s'interface directement avec les lecteurs de carte.
• Relève généralement du Secure Software Standard.

2. Développeurs d'applications de paiement mobile

Exemple : SumUp, Zettle (by PayPal), Revolut Business.

• Applications mobiles permettant aux petites entreprises ou aux particuliers d'accepter des paiements par carte.
• Impliquent souvent des lecteurs de carte Bluetooth et gèrent la saisie des données de carte via téléphone ou tablette.
• La sécurité du logiciel dans ces applications doit être vérifiée de bout en bout.

3. Fournisseurs de SDK de paiement ou de bibliothèques de paiement

Exemple :

• Ces entreprises fournissent des composants intégrables que les marchands utilisent pour accepter des paiements.
• Même si les données de carte sont rapidement tokenisées, le SDK gère tout de même une logique sensible.
• La validation prouve que le SDK ne crée pas de nouvelles surfaces d'attaque.

4. Plateformes de commerce avec paiements intégrés

Exemple : Shopify, BigCommerce, Ecwid.

• Plateformes proposant des modules de paiement intégrés que les marchands utilisent « clé en main ».
• Le logiciel sous-jacent facilitant ce paiement nécessite souvent une validation SSF s'il est distribué.

5. Éditeurs de logiciels pour kiosques et terminaux

Exemple : Nayax, Ingenico, Verifone (pour les développements logiciels personnalisés)

• Utilisés dans les distributeurs automatiques, les bornes de billetterie et les caisses en libre-service.
• Le logiciel doit satisfaire aux exigences de résistance à la falsification, d'intégrité des mises à jour et de communications sécurisées.
• Ces environnements sont souvent « sans surveillance », ce qui rend SSF encore plus pertinent.

6. Solutions de passerelle en marque blanche

Exemple : Payrix, BlueSnap, Corepay

• Proposent une infrastructure de paiement que d'autres plateformes intègrent ou revendent.
• Le composant logiciel distribué (champs hébergés, SDK, plugins) nécessite souvent une validation.
• Aide également les clients entreprises à réduire leur propre périmètre PCI.

7. Outils de paiement axés sur la sécurité

Exemple : Very Good Security (VGS), Basis Theory, TokenEx

• Ces entreprises traitent des données sensibles dans des environnements de type proxy ou dans des coffres-forts.
• Leurs SDK côté client ou bibliothèques navigateur peuvent nécessiter une validation SSF selon la façon dont les données de carte circulent.

Que requiert concrètement PCI SSF ?

Être conforme PCI SSF ne se résume pas à un code propre ou à de bonnes intentions. Le référentiel définit des objectifs de sécurité clairs que votre logiciel doit atteindre. Et ils sont vérifiés lors d'une évaluation.

Quelques attentes clés :

• Aucun stockage de données sensibles : le logiciel ne doit jamais stocker en clair les numéros de carte complets, les codes CVV ou les données de piste magnétique.
• Cryptographie correctement mise en œuvre : des algorithmes reconnus par l'industrie avec une gestion appropriée des clés sont requis.
• Intégrité des mises à jour : les mises à jour logicielles doivent être authentifiées et signées pour prévenir toute falsification.
• Paramètres par défaut sécurisés : les mots de passe administrateur, les paramètres de configuration et les politiques d'accès doivent être livrés dans un état durci.
• Protection contre la falsification : votre application doit détecter et répondre aux tentatives de modification du comportement à l'exécution (ex. : injection, scraping mémoire).
• Contrôle d'accès : les rôles et les permissions doivent être clairement définis, appliqués et journalisés.
• Journalisation et traçabilité : les journaux d'audit doivent être disponibles, sécurisés et résistants à la modification.
• SDLC documenté : votre cycle de développement doit démontrer que la sécurité est intégrée à chaque étape. De la conception à la livraison.

En résumé : les évaluateurs s'attendront à ce que vous prouviez que la sécurité n'est pas une réflexion après coup.

À quoi ressemble le processus de validation ?

La validation PCI SSF est formelle et structurée. Elle est réalisée par un Secure Software Assessor (SSA). Pas d'auto-évaluation ! Elle aboutit à la publication de votre produit sur le site du PCI SSC.

Voici une vue d'ensemble du processus :

• Définition du périmètre : identifiez les produits ou composants soumis à l'évaluation. Vous devrez préciser les fonctionnalités dans le périmètre et leur place dans le flux de paiement.

• Analyse des écarts (optionnelle) : certains éditeurs commencent par une pré-évaluation pour identifier les lacunes majeures avant le début du processus formel. Ce n'est pas obligatoire, mais cela peut faire gagner du temps par la suite.

• Évaluation formelle : l'évaluateur examine :

• Remédiation (si nécessaire) : si des problèmes sont identifiés, vous les corrigez, mettez à jour la documentation et soumettez les preuves des modifications.

• Soumission au PCI SSC : une fois que votre évaluateur est satisfait, il transmet un rapport au PCI SSC pour examen.

• Publication : si approuvé, votre logiciel est publié sur la liste officielle des applications de paiement validées.

Les délais varient, mais la plupart des évaluations prennent de quelques semaines à quelques mois selon le périmètre, la maturité de la base de code et la clarté de la documentation.

Qu'est-ce que PCI DSS ?

PCI DSS (Payment Card Industry Data Security Standard) est celui que la plupart ont probablement déjà entendu, et il cible toutes les autres entreprises qui effectuent des transactions sur leur site.

Dans les grandes lignes, PCI DSS stipule :

Si vous manipulez des données de titulaires de carte, vous devez les protéger, ..., et voici 12 façons de le faire.

Et si vous avez lu notre analyse approfondie de PCI DSS 4.0.1, vous savez que ces 12 façons ne se résument pas à « cocher une case ». On parle de :

• Contrôles de sécurité réseau
• Protection anti-malware
• Gestion des vulnérabilités
• Surveillance et journalisation
• Développement logiciel sécurisé
• Inventaire des scripts (bonjour, PCI 6.4.3 👋)
• Sécurisation des en-têtes de paiement (re-bonjour, 11.6.1 👋)

Que vous soyez un marchand avec SAQ A, un prestataire de services ou un développeur d'application Shopify utilisant des champs hébergés, PCI DSS est le référentiel qui s'applique à votre environnement de traitement des cartes en production.

Voici des liens vers des informations que nous avons précédemment publiées sur PCI DSS, dans l'ordre de lecture recommandé :

• Comment se conformer à PCI 6.4.3 et 11.6.1
• La grande mise à jour PCI DSS de janvier 2025
• L'analyse complète de PCI DSS 4.0.1
• Comment devenir une entreprise SAQ A ?
• Le risque de ne protéger que vos pages de paiement

Alors, quelle est la différence ?

Voici une comparaison côte à côte :

Une entreprise peut-elle être soumise aux deux ?

Absolument. Imaginons que vous développiez et vendiez un plugin de paiement (PCI SSF), mais que vous utilisiez également ce plugin sur votre propre site e-commerce (PCI DSS). Vous devez alors gérer les deux : sécuriser votre base de code, et sécuriser votre infrastructure.

Même si vous ne manipulez pas directement les données de carte (ex. : marchands SAQ A utilisant Stripe ou des concurrents avec des champs hébergés), vous restez soumis à PCI DSS, probablement aux exigences de la version 4.0 comme 6.4.3 et 11.6.1 qui vous rendent responsable des scripts tiers et de l'intégrité du DOM.