Tests d’intrusion fintech : exigences DORA, TLPT ou PCI DSS ?

La décision que ce guide vous aide à prendre

Définissez l’entité juridique, l’activité réglementée et l’environnement des données de cartes de paiement avant de choisir les catégories d’évaluation. L’applicabilité de DORA et la sélection pour un TLPT sont deux questions distinctes. Précisez les objectifs de sécurité du produit, même si le test d’intrusion a été déclenché par une exigence de conformité.

Identifier l’activité réglementée

Le terme fintech peut désigner un établissement de paiement réglementé, un fournisseur de logiciels ou plusieurs entités distinctes au sein d’un groupe. Déterminez quelle entité fournit le service et quelles obligations lui incombent. L’applicabilité de DORA et la sélection pour un TLPT sont deux questions liées, mais distinctes.

Cartographier séparément le périmètre des cartes de paiement

PCI DSS concerne les données des cartes de paiement et les systèmes relevant de son périmètre défini. Une application financière ne correspond pas automatiquement à un environnement de données de titulaires de cartes. Travaillez avec l’équipe conformité ou l’évaluateur responsable afin de déterminer les limites pertinentes et les éléments de preuve attendus avant de définir le test.

Rendre visibles les risques liés au produit

L’isolation des tenants, les pouvoirs des jetons de service et la gestion de l’état des transactions peuvent être importants même lorsqu’un cadre réglementaire donné ne s’applique pas. Décrivez explicitement ces objectifs métier. Un test conçu uniquement autour du nom d’un cadre peut omettre le comportement du produit qui importe le plus aux clients.

Évitez de surestimer la portée du résultat

Une évaluation technique rend compte des constats observés et de leurs limites. Elle n’accorde pas une conformité universelle à DORA, PCI ou au RGPD. Alignez le rapport sur les preuves demandées, réservez les conclusions réglementaires au processus approprié et planifiez des tests de suivi pour les contrôles modifiés par l’équipe d’ingénierie.

Distinguer l’entité de l’architecture du produit

Un produit fintech peut impliquer plusieurs entités juridiques, activités réglementées et prestataires de services. Identifiez l’entité qui exploite le service concerné et les personnes responsables des obligations applicables. Cartographiez ensuite les systèmes qui soutiennent cette activité. Ne déduisez pas une classification juridique de l’utilisation d’API de paiement, d’un partenariat bancaire ou d’une catégorie marketing. L’équipe technique peut fournir des éléments sur l’architecture et les flux de données, tandis que les fonctions juridique et conformité compétentes déterminent l’applicabilité.

Une note de définition du périmètre doit consigner la personne responsable de la décision et les questions en suspens. Cela évite qu’une proposition de prestataire devienne tacitement l’interprétation juridique de l’organisation simplement parce qu’elle contient les acronymes réglementaires appropriés.

Proportionner les affirmations d’assurance à la couverture

Pour une évaluation technique au périmètre défini, indiquez les applications, identités, environnements et méthodes effectivement couverts. Précisez si les systèmes contenant des données de titulaires de cartes, les services de support ou les interfaces avec des tiers font partie des travaux convenus. Une évaluation d’API concluante n’établit pas à elle seule la conformité à la norme PCI DSS. De même, un rapport faisant mention de DORA ne prouve pas qu’un exercice avancé fondé sur les menaces a été réalisé lorsqu’il est requis. Associez chaque livrable demandé à son usage prévu au lieu d’émettre une déclaration générale d’assurance.

Le guide comparant les tests d’intrusion bancaires au TLPT de DORA explique la différence entre les tests techniques courants et un exercice avancé encadré par une autorité. Pour en savoir plus sur le modèle de mise en œuvre du TLPT, consultez le guide TIBER-EU et DORA.

Définissez un périmètre cohérent avec un objectif explicite

Les équipes peuvent souvent réutiliser la préparation de l’architecture, des responsabilités et des éléments probants entre plusieurs axes d’assurance. Cette réutilisation ne doit pas effacer les différences d’objectifs, de méthodes ou de critères d’acceptation. Établissez une matrice reliant chaque décision métier ou exigence à l’activité de test pertinente, aux éléments probants et au responsable. Indiquez les cas où une autre évaluation ou une revue spécialisée reste nécessaire. Cela rend les achats plus efficaces sans prétendre qu’un même test satisfait toutes les obligations.

À la clôture, consignez la version testée, les limites du périmètre et les décisions en attente. Si le produit confie le traitement de données sensibles à un autre fournisseur ou ajoute une nouvelle identité de service, réexaminez la frontière concernée au lieu de supposer qu’un rapport antérieur couvre automatiquement le changement. Le résultat utile est une déclaration claire et étayée sur ce qui a été testé et sur ce que l’organisation doit encore établir.

Mettez les recommandations en pratique

Utilisez la liste de préparation pour consigner les hypothèses, ou consultez le rapport fictif de Fintech AG pour des exemples d’éléments probants et de plans de traitement. Contactez Atlant Security en fournissant une description non sensible du périmètre.