La DSP2 a transformé le marché du paiement européen : authentification forte du client, ouverture des comptes bancaires par API, encadrement strict des acteurs qui manipulent des données de paiement. Pour un prestataire de services de paiement, une fintech ou un agrégateur, la question n'est pas seulement juridique : c'est celle de l'architecture cloud qui héberge et exploite la plateforme au quotidien. Cette page traite la conformité DSP2 cloud sous l'angle opérationnel : comment concevoir sur Microsoft Azure ou AWS un environnement de paiement segmenté, chiffré, journalisé et hautement disponible, conforme aux exigences DSP2 et à PCI-DSS.
- Directive (UE) 2015/2366
- Authentification forte (SCA)
- RTS 2018/389
- Open banking / API
- PCI-DSS v4.0
- La DSP2 (Directive (UE) 2015/2366) encadre les services de paiement dans l'UE : elle impose l'authentification forte du client et ouvre l'accès aux comptes via des API (open banking).
- Sont concernés les PSP (banques, établissements de paiement, de monnaie électronique), les TPP tiers (agrégateurs, initiateurs de paiement) et les fintechs qui s'appuient sur ces flux.
- La SCA combine au moins deux facteurs parmi trois : connaissance, possession, inhérence. Des exemptions encadrées existent (faible montant, analyse du risque, bénéficiaires de confiance).
- Héberger un acteur de paiement dans le cloud suppose une architecture PCI-DSS : segmentation du périmètre des données de carte, chiffrement, journalisation, haute disponibilité.
- Prévoyez un cadrage et une préparation du périmètre cloud de 3 à 10 jours (budget indicatif 7 000 à 18 000 €, sur devis selon le périmètre).
Qu'est-ce que la DSP2 et qui est concerné ?
La DSP2 (deuxième directive sur les services de paiement, Directive (UE) 2015/2366) est entrée en vigueur le 13 janvier 2018, en remplacement de la première directive. Elle poursuit trois objectifs : renforcer la sécurité des paiements, ouvrir le marché à de nouveaux acteurs, et protéger le consommateur. En France, l'autorité de supervision est l'ACPR (Autorité de contrôle prudentiel et de résolution), adossée à la Banque de France, et l'Autorité bancaire européenne (EBA) publie les orientations d'application.
La directive introduit un vocabulaire précis qu'il faut maîtriser avant de parler d'architecture, car chaque rôle porte des obligations différentes.
-
ASPSP
Le gestionnaire de compte (banque ou établissement teneur de comptes de paiement). Il doit exposer une interface d'accès aux comptes pour les acteurs tiers autorisés.
-
AISP
Le prestataire de services d'information sur les comptes : il agrège les soldes et opérations de plusieurs banques, avec le consentement du client (agrégation).
-
PISP
Le prestataire de services d'initiation de paiement : il déclenche un virement depuis le compte du client, sans détenir ses fonds (initiation de paiement).
-
PSP, CBPII, fintech
Établissements de paiement et de monnaie électronique, émetteurs d'instruments de paiement liés à une carte, et fintechs qui construisent des services sur ces flux réglementés.
Ces acteurs partagent un point commun décisif pour le cloud : ils manipulent des données de paiement (identifiants de compte, données de carte, données d'authentification) et exposent ou consomment des API exposées sur Internet. Leur infrastructure est donc à la fois une cible et un actif réglementé. C'est là que se joue la conformité opérationnelle, distincte de la conformité juridique (agrément ACPR, statut, passeport européen) qui relève d'un autre travail.
Cette page se concentre sur l'hébergement d'un acteur de paiement. Pour le panorama réglementaire général du cloud (RGPD, ISO 27001, HDS, SecNumCloud), voyez notre guide de référence sur la conformité cloud RGPD, ISO 27001 et HDS. Pour le socle technique de sécurité, appuyez-vous sur le pilier sécurisation d'infrastructure cloud.
L'authentification forte du client (SCA) et ses exemptions
L'authentification forte du client (SCA, Strong Customer Authentication) est la mesure la plus visible de la DSP2. Elle exige, pour un paiement électronique ou un accès en ligne à un compte, la combinaison d'au moins deux facteurs indépendants parmi trois catégories :
- Connaissance : quelque chose que seul le client connaît (mot de passe, code).
- Possession : quelque chose que seul le client détient (téléphone, jeton matériel, application authentifiée).
- Inhérence : quelque chose que le client est (biométrie, empreinte, reconnaissance faciale).
L'indépendance des facteurs est une exigence structurante : la compromission d'un facteur ne doit pas compromettre les autres. La SCA impose aussi le lien dynamique (dynamic linking) pour les paiements à distance : le code d'authentification doit être lié au montant et au bénéficiaire précis de l'opération, de sorte qu'un code intercepté ne puisse pas servir à une autre transaction.
La SCA n'est pas qu'une case applicative. Le lien dynamique, l'indépendance des facteurs et la protection des éléments d'authentification imposent des choix d'architecture côté serveur : isolation du service d'authentification, chiffrement des secrets, journalisation inaltérable des tentatives. Une SCA correcte dans l'interface mais mal isolée dans l'infrastructure reste une faiblesse.
Les exemptions encadrées
La DSP2 prévoit des exemptions à la SCA pour ne pas alourdir inutilement le parcours de paiement, à condition de rester dans un cadre strict et de savoir les justifier. Les principales :
| Exemption | Principe | Condition clé |
|---|---|---|
| Faible montant | Paiement à distance de faible valeur | ≤ 30 € unitaire, plafonds cumulés (montant et nombre d'opérations) |
| Analyse du risque (TRA) | Exemption selon le niveau de risque de fraude | Taux de fraude du PSP sous des seuils définis par les RTS |
| Bénéficiaires de confiance | Bénéficiaire ajouté à une liste blanche | Enregistrement du bénéficiaire via une SCA préalable |
| Paiements récurrents | Opérations de même montant, même bénéficiaire | SCA à la première échéance seulement |
| Sans contact | Paiement de proximité sans contact | ≤ 50 €, plafonds cumulés avant SCA obligatoire |
L'exemption pour analyse du risque de transaction (TRA, Transaction Risk Analysis) est la plus exigeante en matière d'architecture : elle suppose un moteur de scoring en temps réel, alimenté par des données historiques, dont la performance conditionne le droit à l'exemption. Ce moteur traite des données sensibles, doit être disponible en continu et doit conserver des traces auditables. C'est un composant qui se conçoit dès l'architecture cloud, pas un module que l'on ajoute après coup.
Les normes techniques de réglementation (RTS)
La directive fixe les principes ; les RTS (normes techniques de réglementation) fixent le détail technique opposable. Le texte central est le règlement délégué (UE) 2018/389, applicable depuis le 14 septembre 2019, relatif à l'authentification forte et à des normes ouvertes communes et sécurisées de communication (CSC, Common and Secure Communication).
Ces RTS encadrent notamment :
- Les caractéristiques de la SCA : indépendance des facteurs, lien dynamique, protection de la confidentialité et de l'intégrité des éléments personnalisés de sécurité.
- Les exemptions et les seuils de taux de fraude ouvrant droit à l'exemption TRA.
- Les interfaces d'accès aux comptes : l'ASPSP doit fournir une interface dédiée (API) ou adapter son interface client, avec un mécanisme de repli (fallback) en cas d'indisponibilité de l'interface dédiée.
- Les exigences de traçabilité : journalisation des opérations et conservation des preuves.
Pour l'infrastructure, l'implication est directe : la disponibilité et la journalisation de l'API d'accès aux comptes ne sont pas des bonnes pratiques facultatives, ce sont des exigences réglementaires. Un défaut de disponibilité de l'interface dédiée peut déclencher l'obligation de repli, avec un impact opérationnel et contractuel. La haute disponibilité devient donc un sujet de conformité, pas seulement de confort.
Open banking : API, agrégation et initiation de paiement
La DSP2 a fondé l'open banking européen. Elle oblige les banques teneuses de comptes à ouvrir, avec le consentement du client, un accès sécurisé à leurs données et à l'initiation de paiement. Concrètement, trois usages structurent l'écosystème :
- L'agrégation de comptes (AISP) : consolider dans une seule vue les comptes détenus dans plusieurs banques.
- L'initiation de paiement (PISP) : déclencher un virement directement depuis le compte du payeur, sans intermédiaire carte.
- La confirmation de disponibilité de fonds : vérifier qu'un montant est disponible avant une opération.
Techniquement, tout repose sur des API exposées et consommées sur Internet, protégées par des certificats (dont les certificats eIDAS qui identifient les acteurs autorisés), une authentification mutuelle, une gestion fine du consentement et une limitation de débit. Pour héberger ces API de façon conforme, une passerelle d'API managée est le point de contrôle central.
-
Passerelle d'API
Azure API Management ou AWS API Gateway centralisent l'authentification, la validation des certificats, le quota et la journalisation des appels open banking.
-
Authentification mutuelle
TLS mutuel (mTLS) et validation des certificats eIDAS pour n'accepter que les tiers réellement autorisés, côté ASPSP comme côté TPP.
-
Quota et anti-abus
Limitation de débit, détection d'anomalie et WAF devant les API, pour préserver la disponibilité et contenir les tentatives d'exploitation.
L'exposition d'API sur Internet est précisément la surface la plus attaquée d'un acteur de paiement. Le durcissement de cette surface (filtrage, moindre privilège, secrets, journalisation) relève des principes détaillés sur le pilier sécurisation d'infrastructure cloud, que cette page applique au cas particulier du paiement.
PCI-DSS et sécurité des données de paiement dans le cloud
Dès qu'une plateforme stocke, traite ou transmet des données de carte, la norme PCI-DSS (Payment Card Industry Data Security Standard, version 4.0) s'applique. Elle n'est pas issue de la DSP2 mais des réseaux de cartes ; les deux se cumulent pour un acteur de paiement. PCI-DSS définit 12 exigences autour de la protection de l'environnement des données de carte (CDE, Cardholder Data Environment).
Le principe cardinal dans le cloud est la segmentation : réduire au maximum le périmètre soumis à PCI-DSS en isolant strictement le CDE du reste de l'infrastructure. Plus le périmètre est petit, plus l'audit est court et le risque contenu. La tokenisation (remplacer le numéro de carte par un jeton non réversible hors coffre) est le levier le plus efficace pour sortir la majorité des composants du périmètre.
Le modèle de responsabilité partagée s'applique aussi à PCI-DSS. Azure et AWS fournissent une infrastructure attestée PCI-DSS, dont vous récupérez les attestations (portail de confiance Azure, AWS Artifact) comme éléments d'entrée. Mais la configuration du CDE, la segmentation et les preuves restent votre part.
| Exigence PCI-DSS (extrait) | Microsoft Azure | AWS |
|---|---|---|
| Segmentation du CDE | VNet dédié, sous-réseaux, NSG, Azure Firewall | VPC dédié, sous-réseaux, Security Groups, Network Firewall |
| Pare-feu applicatif | Azure WAF (Application Gateway / Front Door) | AWS WAF (CloudFront / ALB) |
| Chiffrement au repos et en transit | Disques et bases chiffrés, TLS, Azure Key Vault | EBS/RDS/S3 chiffrés, TLS, AWS KMS |
| Gestion des secrets | Azure Key Vault / Managed HSM | AWS Secrets Manager / KMS |
| Journalisation et traçabilité | Azure Monitor, Log Analytics, journaux inaltérables | CloudTrail, CloudWatch, verrouillage des journaux |
| Détection et posture | Microsoft Defender for Cloud | Amazon GuardDuty, AWS Security Hub |
| Contrôle d'accès | Entra ID, RBAC, PIM (accès juste-à-temps) | IAM Identity Center, rôles temporaires |
La tokenisation et le chiffrement fort permettent souvent de réduire le CDE à quelques composants isolés, ce qui allège l'ensemble de la démarche. C'est un arbitrage d'architecture à poser tôt, car il conditionne la durée et le coût de la certification PCI-DSS.
Une architecture Azure ou AWS conforme pour un acteur de paiement
Assembler ces briques donne une architecture cible cohérente. Les composants varient d'un fournisseur à l'autre, mais la logique reste identique : isoler, chiffrer, filtrer, journaliser, superviser.
- Fondation gouvernée (landing zone) Structurer les comptes et abonnements sur le Cloud Adoption Framework (Azure) ou Control Tower / Landing Zone Accelerator (AWS), avec séparation stricte production, recette et développement, et garde-fous en Azure Policy ou AWS Config.
- Segmentation du périmètre de paiement Isoler le CDE dans un réseau dédié (VNet / VPC), micro-segmenter les flux entre briques (front, API, moteur de scoring, stockage), n'autoriser que les communications strictement nécessaires.
- Exposition maîtrisée des API Placer les API open banking derrière une passerelle managée (API Management / API Gateway) et un WAF, avec authentification mutuelle, quota et validation des certificats.
- Chiffrement et secrets Chiffrement au repos et en transit systématique, clés gérées par le client (Key Vault / KMS), tokenisation des données de carte, aucun secret en clair dans le code ou les variables.
- Journalisation inaltérable Centraliser les journaux d'accès, d'API et d'authentification, les rendre inaltérables et les conserver selon les durées attendues (DSP2, PCI-DSS, RGPD).
- Détection et réponse Supervision continue (Defender for Cloud / GuardDuty + SIEM), alertes sur comportement anormal, runbook de réponse à incident daté.
Le bon réflexe. Décrivez cette architecture en Infrastructure as Code (Terraform ou Bicep) dès le départ. La segmentation du CDE, les règles de pare-feu et les politiques de chiffrement deviennent alors versionnées, reproductibles et prouvables devant un auditeur PCI-DSS, bien plus solides qu'une configuration modifiée à la main.
Haute disponibilité et continuité de service
Pour un acteur de paiement, l'indisponibilité n'est pas un incident technique parmi d'autres : c'est un défaut de service qui touche des transactions financières et peut déclencher des obligations réglementaires (repli d'API, notification). La continuité se conçoit donc comme une exigence de conformité, pas seulement de qualité de service.
- Multi-AZredondance sur plusieurs zones de disponibilité (Azure Availability Zones / AWS Multi-AZ)
- RTO / RPOobjectifs de reprise définis, adaptés à la criticité des flux de paiement
- 3-2-1sauvegardes redondées et immuables, isolées d'un compte compromis
- Testsexercices de bascule réels : un PRA non testé n'est pas un PRA
Les mécanismes concrets (redondance multi-zones et multi-régions, réplication synchrone ou asynchrone, sauvegardes immuables, objectifs RTO/RPO) sont détaillés sur notre page dédiée au PRA cloud, plan de reprise d'activité. Pour les acteurs financiers soumis au règlement européen de résilience, ces exigences se formalisent dans un cadre plus large que nous traitons sur la page DORA, résilience opérationnelle dans le cloud : registre des prestataires tiers, tests de résilience, stratégies de sortie et de réversibilité. La DSP2 fixe la sécurité du service de paiement ; DORA en fixe la résilience opérationnelle d'ensemble.
Gestion des accès et des secrets
Un environnement de paiement concentre des accès à très fort privilège : administration de la plateforme, accès aux données de carte, clés de chiffrement, secrets d'API. Leur maîtrise est un point de contrôle majeur, aussi bien pour la DSP2 que pour PCI-DSS.
- Moindre privilège appliqué et révisé : rôles ciblés plutôt que droits d'administration globale, revues d'accès périodiques et documentées, suppression des comptes dormants.
- Accès juste-à-temps : élévation temporaire des droits d'administration via Privileged Identity Management (Azure) ou des rôles temporaires (AWS), plutôt que des droits permanents.
- MFA généralisée sur tous les accès humains, en priorité absolue les comptes d'administration.
- Secrets hors du code : chaînes de connexion, clés d'API et certificats stockés dans Azure Key Vault ou AWS Secrets Manager, avec rotation, jamais dans un dépôt Git ni des variables en clair.
- Séparation des environnements : les identités de production ne se partagent pas avec la recette ou le développement.
La mise en œuvre technique fine de ces principes (accès conditionnel, CIEM, revues automatisées) est développée sur le pilier sécurisation d'infrastructure cloud, et leur industrialisation dans la chaîne CI/CD sur la page DevSecOps cloud.
DSP2, DORA et RGPD : comment les articuler
Un acteur de paiement européen n'est presque jamais soumis à la seule DSP2. Trois cadres se combinent, avec des finalités différentes qu'il faut savoir distinguer pour cadrer le bon effort au bon endroit.
| Cadre | Nature | Finalité | Ce qu'il impose au cloud |
|---|---|---|---|
| DSP2 | Directive européenne | Sécurité des services de paiement | SCA, RTS, API open banking, traçabilité |
| DORA | Règlement européen | Résilience opérationnelle du secteur financier | Registre des tiers, tests de résilience, réversibilité, RTO/RPO |
| RGPD | Règlement européen | Protection des données personnelles | Contrat de sous-traitance art. 28, chiffrement art. 32, encadrement des transferts |
Les recoupements sont nombreux : la journalisation sert la DSP2, DORA et le RGPD à la fois ; le chiffrement répond à PCI-DSS et à l'article 32 du RGPD ; la stratégie de sortie exigée par DORA se construit sur la même autonomie (IaC dans vos dépôts, comptes à votre nom) que celle que nous défendons par principe. Construire une architecture propre couvre donc plusieurs cadres d'un coup, à condition de tenir la matrice des preuves à jour.
Pour les acteurs qui manipulent des crypto-actifs plutôt que des instruments de paiement classiques, le cadre applicable diffère : voyez notre page MiCA, conformité cloud des crypto-actifs. Et si votre activité relève des entités essentielles ou importantes au sens de la cybersécurité générale, la page NIS2, mettre son cloud en conformité précise ces obligations transverses.
La démarche de mise en conformité DSP2 dans le cloud
Aucune conformité de paiement ne s'improvise. La trajectoire que nous cadrons, avant de mettre en relation avec les prestataires qui la mettent en œuvre, suit une logique éprouvée.
- Cadrage du périmètre Identifier les rôles réglementaires (ASPSP, AISP, PISP, PSP), les flux de données de paiement, et la frontière du CDE soumis à PCI-DSS.
- Analyse d'écart Confronter l'architecture existante ou cible aux exigences DSP2 (SCA, RTS, API), PCI-DSS et RGPD, et hiérarchiser les écarts par risque.
- Conception de l'architecture cible Segmentation du CDE, exposition maîtrisée des API, chiffrement et tokenisation, journalisation, haute disponibilité, le tout décrit en Infrastructure as Code.
- Mise en œuvre par un prestataire qualifié Construction de l'environnement Azure ou AWS et des garde-fous automatisés (Azure Policy / AWS Config), par un prestataire disposant des certifications requises.
- Preuves et documentation Constitution du dossier de preuves (segmentation, chiffrement, journaux, accès) attendu par l'auditeur PCI-DSS et le superviseur, matrice de conformité tenue à jour.
- Exploitation et surveillance continue Supervision, détection-réponse et revue de posture, dans le cadre d'une exploitation gérée.
- 3 à 10 jcadrage et préparation du périmètre cloud (selon maturité)
- 7 à 18 k€budget indicatif, sur devis selon le périmètre
- CDEpérimètre des données de carte à segmenter et réduire
- IaCarchitecture versionnée dans vos dépôts, réutilisable comme preuve
Ces montants sont un budget indicatif, présentés en fourchette et confirmés sur devis selon votre périmètre. Ils ne constituent pas un prix ferme. La certification PCI-DSS proprement dite (audit QSA) et l'agrément ACPR relèvent d'organismes tiers et sont facturés séparément.
Notre rôle : intermédiaire indépendant
Architecte Cloud est un intermédiaire indépendant. Nous ne délivrons pas d'agrément ACPR ni de certification PCI-DSS, qui relèvent d'organismes tiers, et nous ne réalisons pas nous-mêmes les prestations techniques. Nous cadrons votre besoin, clarifions le périmètre réglementaire et l'environnement des données de carte, puis nous vous mettons en relation avec des prestataires et experts qualifiés de notre réseau, sur Microsoft Azure et AWS, qui conçoivent, mettent en œuvre et exploitent l'architecture. Vous restez pleinement propriétaire de votre infrastructure : comptes cloud à votre nom, code Infrastructure as Code dans vos dépôts, documentation remise. Aucun enfermement.
Pour aller plus loin, voyez nos services cloud, notre cybersécurité cloud et notre approche du secteur finance. Un audit de conformité cloud permet de mesurer votre écart réel avant tout chantier, et le guide du cloud reprend les fondamentaux en langage clair. Pour les acteurs sensibles aux coûts d'un environnement redondé, notre audit FinOps aide à maîtriser la facture sans sacrifier la conformité.
Vous hébergez ou lancez un service de paiement soumis à la DSP2 ? Faites le point sur votre architecture avec notre diagnostic en ligne, ou échangez avec notre équipe : nous vous orientons vers des prestataires qualifiés pour un environnement Azure ou AWS conforme. Lancez votre diagnostic ou contactez-nous, réponse sous 48 h ouvrées.
FAQ : DSP2 dans le cloud
Qu'est-ce que la DSP2 ?
La DSP2 (deuxième directive sur les services de paiement, Directive (UE) 2015/2366) est le cadre européen des services de paiement, entré en vigueur le 13 janvier 2018. Elle renforce la sécurité des paiements en imposant l'authentification forte du client, ouvre le marché à de nouveaux acteurs via l'open banking, et protège le consommateur. En France, l'ACPR en assure la supervision.
Qui est concerné par la DSP2 ?
Sont concernés les prestataires de services de paiement (banques, établissements de paiement et de monnaie électronique), les prestataires tiers dits TPP (agrégateurs AISP, initiateurs de paiement PISP, émetteurs d'instruments liés à une carte), et les fintechs qui construisent des services sur ces flux réglementés. Tout acteur qui manipule des données de paiement ou expose des API d'accès aux comptes est concerné.
Qu'est-ce que l'authentification forte du client (SCA) ?
La SCA (Strong Customer Authentication) exige de combiner au moins deux facteurs indépendants parmi trois catégories : la connaissance (mot de passe, code), la possession (téléphone, jeton) et l'inhérence (biométrie). Pour les paiements à distance, elle impose aussi le lien dynamique : le code d'authentification est lié au montant et au bénéficiaire précis de l'opération.
Quelles sont les exemptions à la SCA ?
Les principales exemptions encadrées sont : les paiements à distance de faible montant (≤ 30 € unitaire, avec plafonds cumulés), l'analyse du risque de transaction (TRA) lorsque le taux de fraude reste sous les seuils des RTS, les bénéficiaires de confiance ajoutés à une liste blanche, les paiements récurrents de même montant et même bénéficiaire, et le sans contact (≤ 50 € avec plafonds cumulés). Chaque exemption doit pouvoir être justifiée.
Que sont les RTS de la DSP2 ?
Les RTS (normes techniques de réglementation) précisent les exigences techniques opposables de la directive. Le texte central est le règlement délégué (UE) 2018/389, applicable depuis le 14 septembre 2019, relatif à l'authentification forte et aux normes ouvertes communes et sécurisées de communication. Il détaille les caractéristiques de la SCA, les exemptions, les seuils de fraude et les interfaces d'accès aux comptes avec leur mécanisme de repli.
Qu'est-ce que l'open banking dans la DSP2 ?
L'open banking désigne l'ouverture, avec le consentement du client, de l'accès aux comptes bancaires par des API sécurisées. Il permet l'agrégation de comptes (AISP), l'initiation de paiement depuis le compte du payeur (PISP) et la confirmation de disponibilité de fonds. Techniquement, il repose sur des API protégées par authentification mutuelle, certificats eIDAS, gestion du consentement et limitation de débit.
La DSP2 impose-t-elle PCI-DSS ?
PCI-DSS n'est pas issue de la DSP2 : c'est la norme de sécurité des réseaux de cartes, obligatoire dès que l'on stocke, traite ou transmet des données de carte. Pour un acteur de paiement, les deux se cumulent. Dans le cloud, l'enjeu est de segmenter et réduire l'environnement des données de carte (CDE), notamment par la tokenisation, pour limiter le périmètre soumis à l'audit PCI-DSS.
Comment héberger une plateforme de paiement conforme sur Azure ou AWS ?
En construisant une architecture qui isole le périmètre des données de carte dans un réseau dédié (VNet ou VPC), expose les API derrière une passerelle managée et un WAF, chiffre au repos et en transit avec des clés gérées par le client (Key Vault ou KMS), tokenise les données de carte, journalise de façon inaltérable et assure une haute disponibilité multi-zones. Le tout décrit en Infrastructure as Code pour être prouvable.
Le cloud public est-il autorisé pour un acteur de paiement soumis à la DSP2 ?
Oui, le recours à Azure ou AWS est courant et compatible avec la DSP2 et PCI-DSS, sous réserve d'une architecture conforme et d'un encadrement contractuel du prestataire cloud (sous-traitance, localisation, réversibilité). Le fournisseur fournit une infrastructure attestée PCI-DSS, mais la configuration, la segmentation et les preuves restent votre responsabilité, selon le modèle de responsabilité partagée.
Quelle est la différence entre DSP2 et DORA ?
La DSP2 encadre la sécurité des services de paiement (authentification forte, API, données de paiement). DORA, règlement européen de résilience opérationnelle du secteur financier, encadre la capacité à résister et se remettre d'incidents : registre des prestataires tiers, gestion du risque tiers, tests de résilience, stratégies de sortie, RTO/RPO. Un acteur de paiement est souvent soumis aux deux, qui se complètent.
Comment la DSP2 s'articule-t-elle avec le RGPD ?
Les deux se cumulent. Le RGPD protège les données personnelles (dont les données de paiement en tant que données personnelles) et impose un contrat de sous-traitance (art. 28) avec le fournisseur cloud, des mesures de sécurité (art. 32) comme le chiffrement, et l'encadrement des transferts hors UE. La DSP2 ajoute la sécurité propre au paiement. Une bonne architecture (chiffrement, journalisation, accès maîtrisés) sert les deux cadres à la fois.
Combien coûte la mise en conformité DSP2 d'une plateforme cloud ?
Pour le cadrage et la préparation du périmètre cloud (analyse d'écart, architecture cible, segmentation, journalisation, plan de mise en œuvre), le budget indicatif se situe généralement entre 7 000 et 18 000 €, pour 3 à 10 jours selon le périmètre, sur devis après cadrage. La certification PCI-DSS par un auditeur QSA et l'agrément ACPR relèvent d'organismes tiers et sont facturés à part.
Qu'est-ce que la DSP3 et le PSR à venir ?
La DSP3 et le règlement sur les services de paiement (PSR) sont la révision en cours du cadre européen. Ils visent à renforcer et élargir l'open banking, à améliorer la lutte contre la fraude et à harmoniser l'application entre États membres. Concevoir dès aujourd'hui une architecture segmentée, chiffrée et journalisée en facilite l'adaptation future, sans reprise lourde.