Comment atteindre la résilience opérationnelle conforme à DORA sans dépendre d’un fournisseur cloud américain
Le Digital Operational Resilience Act (DORA, Règlement UE 2022/2554) est applicable depuis le 17 janvier 2025. Il établit des exigences uniformes en matière de sécurité des TIC pour l’ensemble du secteur financier européen. DORA s’articule autour de cinq piliers : gestion des risques TIC, gestion et reporting des incidents, tests de résilience opérationnelle numérique, gestion des risques liés aux tiers TIC et partage d’informations sur les cybermenaces. Chaque pilier suppose que les entités financières gardent un contrôle réel sur leur infrastructure TIC et sur les données traitées.
Cette hypothèse pose un problème fondamental pour les institutions financières européennes qui s’appuient sur des fournisseurs cloud dont le siège est aux États-Unis. Lorsqu’une banque utilise des plateformes critiques d’échange de données opérées par des fournisseurs soumis au CLOUD Act et à la Section 702 du FISA, sa résilience opérationnelle dépend d’un régime juridique étranger qu’elle ne maîtrise pas. Une demande d’accès aux données par le gouvernement américain ne déclenche pas les processus de gestion d’incident de la banque. Elle les contourne complètement. Le fournisseur se conforme à la demande sans en informer la banque, qui ne peut alors pas prouver la souveraineté des données exigée implicitement par le cadre de résilience de DORA.
Ce guide analyse chaque pilier de DORA à travers la dépendance aux fournisseurs cloud américains et explique comment les institutions financières européennes peuvent atteindre une véritable résilience opérationnelle grâce à une architecture souveraine qui élimine, plutôt que de gérer, le risque d’accès étranger.
Résumé Exécutif
Idée principale : Les cinq piliers de DORA exigent que les institutions financières européennes prouvent leur résilience opérationnelle en matière de gestion des risques TIC, gestion des incidents, tests de résilience, supervision des tiers et partage d’informations. Chaque pilier est compromis lorsque des plateformes de données critiques sont opérées par des fournisseurs soumis à des lois étrangères d’accès gouvernemental. Pour être conforme à DORA, il faut une architecture souveraine : chiffrement contrôlé par le client, déploiement européen à locataire unique et indépendance opérationnelle vis-à-vis de l’infrastructure des fournisseurs américains.
Pourquoi est-ce important : Les sanctions DORA peuvent atteindre 10 % du chiffre d’affaires annuel pour les entités financières et jusqu’à 5 millions d’euros pour les fournisseurs TIC critiques. En novembre 2025, les autorités européennes de supervision ont désigné 19 fournisseurs TIC comme critiques, dont AWS, Microsoft Azure et Google Cloud, les soumettant à une surveillance directe de l’UE. BaFin attend les premiers constats de conformité DORA d’ici fin 2025. Les institutions dont la résilience dépend de fournisseurs qu’elles ne peuvent pas superviser totalement s’exposent à la fois à des sanctions réglementaires et à des risques opérationnels que DORA vise justement à prévenir.
5 points clés à retenir
- Le pilier gestion des risques TIC de DORA exige un contrôle que vous ne pouvez pas déléguer à un fournisseur américain. Les entités financières doivent identifier, protéger, détecter, répondre et se remettre des risques TIC. Si le fournisseur détient les clés de chiffrement et est soumis à des lois étrangères d’accès, l’institution conserve un risque résiduel qu’elle ne peut pas atténuer par de simples clauses contractuelles.
- Les obligations de reporting d’incident supposent une visibilité totale sur les accès aux données. DORA impose la classification et le reporting des incidents TIC majeurs dans des délais stricts. Si un fournisseur américain répond à une demande gouvernementale sans prévenir la banque, celle-ci ne peut pas signaler ce qu’elle ne voit pas.
- Les tests de résilience doivent couvrir les scénarios d’accès par des gouvernements étrangers. DORA impose des évaluations de vulnérabilité, des tests de pénétration et des exercices de simulation. Les institutions doivent intégrer les demandes de données liées au CLOUD Act comme scénario de test pour toute plateforme critique opérée par un fournisseur américain.
- La gestion des risques liés aux tiers exige d’évaluer la juridiction du fournisseur, pas seulement ses certifications de sécurité. DORA impose explicitement la supervision des tiers TIC, y compris des évaluations des risques prenant en compte l’exposition juridique du fournisseur à des demandes gouvernementales étrangères.
- L’architecture souveraine élimine la dépendance au lieu de la gérer. Des clés de chiffrement contrôlées par le client, un déploiement européen à locataire unique et une résidence des données imposée par des politiques suppriment le risque d’accès étranger au niveau architectural, répondant ainsi simultanément aux cinq piliers de DORA.
Les cinq piliers de DORA et le problème de dépendance aux fournisseurs américains
Pilier 1 : Gestion des risques TIC
L’article 6 de DORA impose aux entités financières de mettre en place des cadres de gestion des risques TIC couvrant l’identification, la protection, la détection, la réponse et la reprise. Ce cadre doit traiter les risques internes et externes, y compris ceux liés aux fournisseurs tiers, avec une supervision jusqu’au niveau du conseil d’administration.
Pour les banques allemandes, le cadre BAIT de la BaFin (applicable jusqu’à fin 2026 pour les établissements en transition) impose déjà une gestion des risques IT. L’article 6(4) de DORA introduit une fonction dédiée de contrôle des risques TIC, avec des exigences d’indépendance que la BaFin juge proches mais non identiques à celles du responsable de la sécurité de l’information prévu par BAIT.
Le défi fondamental est le suivant : un cadre de gestion des risques TIC qui identifie « l’accès aux données par le gouvernement américain via un fournisseur cloud » comme un risque mais le considère acceptable en raison des clauses contractuelles types (SCC) ou du Data Privacy Framework UE-États-Unis construit sa résilience sur une base juridique incertaine. Les SCC et le DPF sont des mécanismes juridiques de transfert, pas des protections techniques. Ils n’empêchent pas une demande CLOUD Act d’aboutir. DORA exige des mesures qui gèrent réellement les risques TIC, pas seulement leur documentation. Si le risque est d’ordre architectural, la réponse doit l’être aussi.
Pilier 2 : Gestion et reporting des incidents
DORA impose des processus structurés pour détecter, classifier et déclarer les incidents TIC majeurs. Le calendrier de reporting de l’EBA exige une notification initiale dans les 4 heures suivant la classification, un rapport intermédiaire sous 72 heures et un rapport final sous un mois. Les incidents majeurs doivent être signalés aux autorités nationales compétentes.
Ce pilier suppose une visibilité totale sur les événements affectant les données de l’institution. Lorsqu’un fournisseur américain reçoit une National Security Letter ou une ordonnance FISA l’obligeant à fournir des données, il peut être légalement interdit d’en informer le client. L’institution financière n’a alors aucune visibilité sur l’accès et ne peut donc ni classifier ni déclarer l’incident. Cela crée une faille structurelle dans la gestion des incidents que nulle amélioration de processus ne peut combler, car elle est inhérente à la relation avec le fournisseur.
L’architecture souveraine résout ce problème en empêchant le fournisseur d’accéder aux données déchiffrées, quelles que soient les demandes juridiques. Lorsque l’institution contrôle les clés de chiffrement dans son propre HSM, une demande gouvernementale adressée au fournisseur ne produit que du texte chiffré. Les journaux d’audit de l’institution enregistrent tous les accès légitimes, offrant la visibilité requise par DORA pour le reporting des incidents.
Pilier 3 : Tests de résilience opérationnelle numérique
DORA impose des tests réguliers de résilience opérationnelle, incluant des évaluations de vulnérabilité, des tests de pénétration et des exercices de simulation. Les entités critiques peuvent être tenues de réaliser des tests de pénétration avancés (TLPT) alignés sur le cadre TIBER-EU.
Des tests de résilience qui excluent les scénarios d’accès par des gouvernements étrangers donnent une vision incomplète pour toute institution utilisant des services cloud opérés par des Américains. Un programme de test doit modéliser le scénario où un fournisseur de plateforme critique est contraint de fournir des données clients, et évaluer si l’architecture de l’institution empêche l’exposition des données, si les systèmes de surveillance détectent la tentative et si les procédures de réponse aux incidents s’activent correctement.
Avec un chiffrement contrôlé par le client, ce test donne un résultat clair : le fournisseur ne peut pas fournir de données lisibles. Le scénario valide alors les contrôles architecturaux, au lieu de révéler un risque impossible à atténuer.
Pilier 4 : Gestion des risques liés aux tiers TIC
Les exigences de gestion des risques liés aux tiers de DORA comptent parmi ses dispositions les plus structurantes. Les entités financières doivent évaluer et surveiller en continu les risques liés aux fournisseurs TIC, s’assurer que les contrats incluent des clauses de sécurité, des droits d’audit, de résiliation, des stratégies de sortie et des procédures de notification d’incident. Les autorités européennes de supervision ont désigné 19 fournisseurs comme tiers TIC critiques (CTPP) en novembre 2025, soumettant AWS, Microsoft Azure, Google Cloud et d’autres à une supervision directe de l’UE.
L’article 28(3) de DORA impose aux entités financières de tenir un registre des informations recensant tous les contrats avec des tiers TIC. La BaFin a exigé des établissements allemands qu’ils soumettent leur registre initial avant le 11 avril 2025. Ce registre doit détailler non seulement l’existence de la relation, mais aussi la nature des services, la localisation des données et la classification des risques.
Pour les institutions utilisant des plateformes américaines pour l’échange de données sensibles, l’évaluation des risques liés aux tiers doit prendre en compte la juridiction du fournisseur. L’EBA a précisé que se fier uniquement à des certifications comme ISO 27001 ne suffit pas. L’évaluation doit déterminer si le fournisseur peut être contraint de fournir des données clients en vertu d’une loi étrangère et si l’architecture de l’institution empêche l’exposition de données lisibles dans ce scénario.
DORA impose aussi des stratégies de sortie viables. Les institutions doivent démontrer qu’elles peuvent se séparer de tout fournisseur TIC sans perturber leurs opérations. Cette exigence vise directement le risque de dépendance à un nombre restreint de fournisseurs américains. Les institutions doivent évaluer si leur architecture actuelle permet la migration et si des fournisseurs alternatifs peuvent offrir des fonctions équivalentes sous juridiction européenne.
Pilier 5 : Partage d’informations sur les cybermenaces
DORA encourage les entités financières à participer à des dispositifs de partage d’informations sur les menaces. Si la participation n’est pas obligatoire, les institutions doivent informer les régulateurs de leurs activités de partage. Un partage efficace suppose de bien comprendre son propre paysage de menaces. Une institution qui n’a pas de visibilité sur les accès potentiels imposés par les gouvernements via ses fournisseurs cloud a un modèle de menace incomplet. L’architecture souveraine clarifie ce paysage en éliminant l’ambiguïté liée aux accès étrangers, permettant à l’institution de concentrer ses efforts de partage sur les véritables cybermenaces externes.
À quoi ressemble une architecture souveraine conforme à DORA
Pour atteindre la résilience opérationnelle exigée par DORA sans dépendance aux fournisseurs cloud américains, trois fonctions architecturales sont nécessaires, conformément au principe GTM selon lequel la souveraineté des données relève de l’architecture technique, pas d’une clause contractuelle.
Clés de chiffrement contrôlées par le client
L’institution génère et stocke les clés de chiffrement dans son propre module matériel de sécurité (HSM), situé sur site ou dans un centre de données européen contrôlé par l’institution. La plateforme cloud traite les données chiffrées, mais ne possède jamais les clés de déchiffrement. Cela diffère fondamentalement des dispositifs BYOK où le fournisseur conserve un accès au matériel de clé. Le test est simple : si le fournisseur reçoit une demande légale, peut-il fournir des données déchiffrées ? Si oui, le modèle de chiffrement ne répond pas aux exigences de gestion des risques de DORA pour les fonctions critiques.
Déploiement européen à locataire unique
Les plateformes multi-locataires servent des milliers de clients sur une infrastructure mutualisée optimisée pour la couverture mondiale du fournisseur. Un déploiement à locataire unique sur une infrastructure européenne dédiée sert un seul client sur des systèmes isolés, où les contrôles d’accès sont régis par le droit européen. Combiné à un chiffrement contrôlé par le client, le déploiement à locataire unique supprime à la fois le chemin d’accès logique (clés de chiffrement) et le chemin d’accès physique (infrastructure partagée) qui créent la dépendance au fournisseur.
Indépendance opérationnelle et capacité de sortie
DORA impose des stratégies de sortie viables pour tous les tiers TIC soutenant des fonctions critiques. Les institutions financières ont donc besoin de plateformes reposant sur des protocoles standards, permettant la portabilité des données et l’indépendance opérationnelle. L’architecture doit permettre un déploiement sur site, dans un cloud privé européen ou sur une infrastructure européenne hébergée par un fournisseur, avec la flexibilité de migrer entre ces options sans perte de données ni interruption opérationnelle. Cela répond aux préoccupations de DORA sur le risque de concentration et à l’attente de la BaFin que les fonctions externalisées puissent être rapatriées.
Alignement des piliers DORA : dépendance aux fournisseurs américains vs architecture souveraine
| Pilier DORA | Risque avec dépendance aux fournisseurs américains | Réponse de l’architecture souveraine |
|---|---|---|
| Gestion des risques TIC | Le risque d’accès étranger ne peut pas être atténué contractuellement | Risque éliminé au niveau architectural ; le fournisseur ne peut pas accéder aux données |
| Gestion des incidents | Les demandes gouvernementales peuvent contourner la visibilité et le reporting de l’institution | Traçabilité complète ; tous les accès sont visibles par l’institution |
| Tests de résilience | Le scénario d’accès étranger révèle un risque impossible à atténuer | Le scénario d’accès étranger valide les contrôles architecturaux |
| Risque tiers | La juridiction du fournisseur crée une dépendance structurelle | Clés contrôlées par le client et déploiement à locataire unique suppriment la dépendance |
| Partage d’informations | Modèle de menace incomplet à cause de l’ambiguïté des accès côté fournisseur | Paysage de menace clarifié ; concentration sur les véritables menaces externes |
Mise en œuvre : passer à une architecture souveraine conforme à DORA
Phase 1 : Cartographier les dépendances TIC critiques
Utilisez le registre des informations DORA comme point de départ. Identifiez chaque relation avec un tiers TIC soutenant des fonctions critiques ou importantes, puis évaluez la juridiction du fournisseur, le modèle de chiffrement et l’architecture de gestion des clés. Pour chaque service opéré par un Américain, documentez si le fournisseur peut accéder à des données clients déchiffrées, y compris sous contrainte légale. Cette évaluation alimente directement votre cadre de gestion des risques TIC et répond à l’attente de la BaFin d’une évaluation honnête des risques.
Phase 2 : Prioriser selon l’exposition réglementaire
Tous les services TIC ne présentent pas le même risque DORA. Priorisez les services traitant les données les plus sensibles : dossiers financiers clients, transfert sécurisé de fichiers pour les soumissions réglementaires, communications d’audit interne, enregistrements de transactions transfrontalières et correspondance au niveau du conseil. Ce sont les fonctions où un accès gouvernemental étranger crée la plus forte exposition réglementaire, réputationnelle et opérationnelle.
Phase 3 : Déployer une architecture souveraine
Transférez les fonctions prioritaires vers des plateformes offrant un chiffrement contrôlé par le client, un déploiement européen à locataire unique et une résidence des données imposée par des politiques de géorepérage. Validez par des tests indépendants que le fournisseur ne peut pas accéder aux données déchiffrées. Configurez des journaux d’audit détaillés pour répondre aux délais de reporting des incidents DORA et aux obligations de surveillance continue. Mettez en place des procédures de gestion d’incident adaptées aux capacités de la nouvelle architecture.
Phase 4 : Prouver la conformité par des éléments tangibles
La conformité DORA se démontre par des preuves, pas des déclarations. Conservez la documentation sur la génération des clés dans le HSM de l’institution, la configuration du déploiement à locataire unique, l’application du géorepérage et la traçabilité complète. Préparez ce dossier pour les contrôles de la BaFin, les audits de la BCE et les tests de résilience périodiques exigés par DORA. Une souveraineté prouvée est une souveraineté qui protège.
La résilience opérationnelle exige la souveraineté opérationnelle
Les cinq piliers de DORA définissent ce qu’est la résilience opérationnelle. Mais la résilience n’existe pas sans contrôle. Si les plateformes de données critiques d’une institution financière sont opérées par des fournisseurs soumis à des lois étrangères d’accès gouvernemental, le cadre de résilience de l’institution présente une faille structurelle qu’aucune clause contractuelle, certification ou amélioration de processus ne peut combler.
L’architecture souveraine, fondée sur un chiffrement contrôlé par le client, un déploiement européen à locataire unique et une véritable indépendance opérationnelle, comble cette faille en éliminant la dépendance au lieu de la gérer. Les institutions financières européennes qui adoptent cette architecture ne se contentent pas d’être conformes à DORA. Elles bâtissent l’infrastructure de résilience zero trust que les régulateurs financiers européens appellent de leurs vœux.
Kiteworks aide les institutions financières européennes à atteindre la résilience opérationnelle conforme à DORA
Le Réseau de données privé Kiteworks propose une architecture souveraine conçue pour répondre au cadre des cinq piliers de DORA. Kiteworks fonctionne selon un modèle de chiffrement géré par le client, où l’institution génère et conserve les clés dans son propre HSM. Kiteworks ne peut pas accéder au contenu déchiffré et ne peut pas répondre à des demandes étrangères de données lisibles, car il ne possède pas les clés.
Kiteworks se déploie en instance à locataire unique sur une infrastructure européenne dédiée, y compris sur site, dans un cloud privé ou en appliance virtuelle durcie, offrant aux institutions la flexibilité de déploiement et la capacité de sortie exigées par DORA. Le géorepérage intégré impose la résidence des données au niveau de la plateforme. Un audit logging détaillé répond aux délais de reporting des incidents DORA et fournit les preuves de surveillance continue attendues par les régulateurs. Kiteworks contribue à la conformité DORA sur les cinq piliers grâce à une approche unifiée de la gestion des risques TIC pour les contenus sensibles.
La plateforme unifie le partage sécurisé de fichiers, la protection des e-mails, le transfert sécurisé de fichiers et les formulaires web sous un même cadre de gouvernance, permettant aux institutions financières de répondre aux exigences de gestion des risques tiers de DORA sur tous les canaux d’échange de données avec une seule architecture, un seul ensemble de contrôles et un seul dossier de preuves pour la supervision.
Pour en savoir plus sur la résilience opérationnelle conforme à DORA sans dépendance aux fournisseurs cloud américains, réservez votre démo personnalisée dès aujourd’hui.
Foire aux questions
Non. DORA n’interdit pas l’utilisation de fournisseurs TIC dont le siège est aux États-Unis, mais il exige que les institutions gèrent les risques liés à ces relations. Le règlement impose une évaluation des risques, des contrôles contractuels incluant des stratégies de sortie et une surveillance continue pour tous les tiers TIC. Pour les services américains soutenant des fonctions critiques, l’évaluation des risques doit prendre en compte l’exposition au CLOUD Act et à la Section 702 du FISA. Les institutions peuvent continuer à utiliser des fournisseurs américains si elles mettent en place des contrôles architecturaux, comme des clés de chiffrement contrôlées par le client, qui éliminent la capacité du fournisseur à accéder aux données déchiffrées, neutralisant ainsi le risque d’accès étranger sur le plan technique.
Les entités financières risquent des sanctions pouvant aller jusqu’à 10 % du chiffre d’affaires annuel ou 10 millions d’euros pour les violations graves, tandis que les dirigeants peuvent être sanctionnés jusqu’à 1 million d’euros. Les sanctions DORA s’appliquent à partir du 17 janvier 2025 sans période de grâce. Les autorités compétentes peuvent procéder à des inspections, exiger la cessation des pratiques non conformes et publier des communiqués identifiant l’entité en infraction. Au-delà des sanctions financières, les institutions s’exposent à une atteinte à la réputation et à une perte de confiance des clients. La BaFin a annoncé qu’elle renforcerait la supervision des externalisations en 2025 et attend les premiers constats de conformité d’ici fin 2025, ce qui fait de la mise en œuvre rapide d’une architecture souveraine une priorité.
La désignation de 19 fournisseurs critiques par les ESA en novembre 2025 les soumet à une supervision directe de l’UE, mais cela ne réduit pas les obligations de conformité des banques. Ces dernières doivent toujours réaliser des évaluations de risques indépendantes, maintenir des contrôles contractuels et mettre en place des stratégies de sortie pour ces fournisseurs. Cette désignation signifie que les régulateurs examinent désormais à la fois la gestion des risques de la banque et les opérations du fournisseur. Les banques doivent voir cela comme un renforcement du contrôle de leurs relations avec les tiers, et non comme une validation réglementaire de ces fournisseurs. Mettre en œuvre un chiffrement contrôlé par le client et un déploiement à locataire unique démontre que la banque a traité les risques spécifiques liés à ces fournisseurs désignés.
Les banques allemandes doivent se concentrer sur trois priorités : compléter le registre des informations DORA, garantir la conformité contractuelle des relations TIC et documenter les mesures architecturales de réduction des risques. La BaFin a exigé la soumission du registre initial avant le 11 avril 2025 et a indiqué que l’ajustement des contrats avec les tiers TIC est une priorité immédiate. La BaFin attend un calendrier de conformité basé sur les risques, où les institutions démontrent leurs avancées. Les banques doivent documenter leur architecture de gestion des clés de chiffrement, les contrôles de résidence des données et les cadres de gouvernance des données comme preuves d’une gestion réelle des risques. Pour les établissements passant de BAIT à DORA, le document d’analyse des écarts de la BaFin propose une comparaison pratique des exigences anciennes et nouvelles en matière de gestion des risques TIC.
Les offres cloud souverain répondent à certaines préoccupations de dépendance, mais impliquent souvent des partenariats avec des fournisseurs américains, ce qui peut maintenir une dépendance technologique américaine dans l’infrastructure sous-jacente. DORA exige que les institutions évaluent l’ensemble de la supply chain, y compris les sous-traitances. Un cloud souverain construit sur la technologie Microsoft Azure peut toujours impliquer des dépendances au code américain et des points de contact opérationnels. Les institutions doivent évaluer si l’offre souveraine garantit une véritable indépendance, des clés de chiffrement contrôlées par le client et un contrôle opérationnel total, ou si la souveraineté s’accompagne de fonctions réduites et de tarifs premium. La question clé reste de savoir si un acteur de la chaîne peut accéder à des données déchiffrées sous contrainte légale étrangère, quelle que soit la marque du service. Les institutions doivent appliquer les mêmes critères zero trust à toute offre cloud souverain qu’à n’importe quel autre fournisseur.
Ressources complémentaires
- Article de blog
Souveraineté des données : bonne pratique ou exigence réglementaire ? - eBook
Souveraineté des données et RGPD - Article de blog
Les pièges à éviter en matière de souveraineté des données - Article de blog
Bonnes pratiques pour la souveraineté des données - Article de blog
Souveraineté des données et RGPD [Comprendre la sécurité des données]