DORA et le cloud : obligations de conformité pour les entreprises financières cloud-native

Le règlement DORA (Digital Operational Resilience Act), applicable depuis janvier 2025, a des implications particulièrement significatives pour les entreprises financières cloud-native — fintechs, néobanques, plateformes d'investissement, gestionnaires d'actifs numériques. Leur dépendance quasi-totale à des infrastructures cloud tierces (AWS, Azure, GCP) crée des obligations spécifiques en matière de gestion des risques TIC.

DORA et le cloud : une relation centrale

DORA place la gestion des risques liés aux tiers prestataires TIC au cœur de son dispositif (Pilier 4). Pour une fintech 100 % cloud, cela signifie que votre principal fournisseur de cloud — AWS, Azure ou GCP — est votre prestataire TIC le plus critique. DORA impose de gérer ce risque avec une rigueur accrue.

Les grands hyperscalers (AWS, Azure, GCP) ont été désignés "prestataires TIC critiques" par les Autorités Européennes de Supervision (AES) en 2025. Cette désignation leur impose des obligations directes envers les régulateurs, mais ne vous dispense pas de vos propres obligations de gestion des risques cloud.

Les obligations cloud spécifiques sous DORA

1. Cartographie et concentration du risque cloud

DORA exige une cartographie complète de vos prestataires TIC, en identifiant les fonctions critiques ou importantes (FCI) qui reposent sur le cloud. Pour une fintech, cela inclut typiquement : infrastructure d'hébergement de l'application principale, traitement des paiements et transactions, stockage des données clients et KYC, systèmes d'authentification et IAM, environnements de développement/test qui touchent à des données réelles.

DORA s'inquiète particulièrement du risque de concentration : si toute votre infrastructure critique repose sur un seul hyperscaler, une panne majeure de celui-ci peut menacer la stabilité financière. Les régulateurs peuvent imposer une stratégie multi-cloud ou des plans de continuité alternatifs.

2. Clauses contractuelles obligatoires avec les fournisseurs cloud

L'article 30 de DORA impose des clauses contractuelles précises dans vos contrats avec les prestataires TIC critiques. Pour vos contrats AWS, Azure ou GCP, les clauses suivantes doivent figurer :

• Description précise des services : périmètre exact, SLA garantis (disponibilité, RPO/RTO), niveaux de service minimaux
• Localisation des données : régions de stockage et de traitement, conditions de transfert hors UE
• Droit d'audit : droit pour l'entité financière ou un auditeur désigné d'auditer le prestataire cloud
• Obligations de notification : délais de notification des incidents affectant vos services
• Stratégie de sortie : conditions de portabilité des données, assistance lors de la migration vers un autre prestataire, durée de la phase de transition
• Sous-traitance en chaîne : liste des sous-prestataires critiques du fournisseur cloud (datacenters tiers, etc.)

Attention : les contrats standards des hyperscalers (AWS Business Associate Agreement, Azure Service Agreement) ne couvrent pas toutes ces exigences DORA. Vous devrez négocier des addendums spécifiques ou souscrire des niveaux de service supérieurs (Enterprise Support).

3. Tests de résilience cloud (TLPT)

DORA impose des tests de résilience opérationnelle numérique. Pour les entités financières d'importance systémique, les TLPT (Threat-Led Penetration Tests) doivent couvrir l'infrastructure cloud :

• Tests de base annuels : scan de vulnérabilités de l'infrastructure cloud, tests de reprise après sinistre (DR drills), vérification des sauvegardes et RTO/RPO, tests des procédures de basculement
• TLPT triennaux : pentests sophistiqués simulant des attaques réelles sur votre infrastructure cloud, réalisés par des prestataires qualifiés sous coordination des autorités

Pour les TLPT, les testeurs doivent pouvoir accéder à votre environnement cloud de production (ou un miroir fidèle). Cela nécessite une préparation contractuelle avec votre fournisseur cloud pour autoriser ces tests (clause d'autorisation de pentest dans le contrat AWS/Azure/GCP).

4. Plan de continuité et reprise cloud

DORA exige des plans de continuité d'activité (PCA) et de reprise après sinistre (PRA) couvrant les scénarios de défaillance cloud. Pour une fintech cloud-native, ces scénarios incluent : indisponibilité d'une zone de disponibilité (AZ), panne régionale AWS/Azure/GCP, corruption massive de données dans le stockage cloud, compromission des credentials IAM cloud, déni de service sur l'API cloud.

Vos RTO (Recovery Time Objective) et RPO (Recovery Point Objective) doivent être définis, documentés, et testés régulièrement. La plupart des régulateurs s'attendent à un RTO inférieur à 4 heures pour les fonctions critiques des entités financières.

Gestion du risque IAM cloud sous DORA

DORA (article 9) impose une gestion stricte des identités et des accès. Pour le cloud, cela se traduit par :

• Principe du moindre privilège strict sur tous les comptes AWS/Azure/GCP (IAM roles, pas de comptes root/owner utilisés en opération)
• MFA obligatoire sur tous les comptes cloud, notamment les comptes d'administration
• Rotation régulière des credentials et clés d'accès (rotation automatisée avec AWS Secrets Manager, Azure Key Vault, GCP Secret Manager)
• Journalisation complète de toutes les actions IAM (AWS CloudTrail, Azure Activity Log, GCP Cloud Audit Logs) avec rétention minimale de 3 ans
• Revue régulière des droits d'accès (access reviews trimestriels pour les comptes à privilèges)

Notification des incidents cloud à l'ACPR/AMF

DORA impose des délais de notification très courts pour les incidents TIC majeurs : rapport initial à l'autorité compétente dans les 4 heures après classification, rapport intermédiaire dans les 72 heures, rapport final dans un mois.

Pour les entreprises cloud-native, la chaîne de détection doit être entièrement automatisée. Vous ne pouvez pas vous permettre de découvrir un incident majeur 12 heures après qu'il se soit produit. Les outils recommandés : AWS GuardDuty + Security Hub, Microsoft Defender for Cloud, Google Security Command Center, couplés à des alertes PagerDuty ou Opsgenie avec escalade 24/7.

Plan de conformité DORA cloud en 5 étapes

Pour une fintech cloud-native, voici le chemin critique vers la conformité DORA :

• Étape 1 — Cartographie TIC : Listez tous vos prestataires cloud et SaaS avec les fonctions qu'ils supportent. Identifiez ceux qui supportent des FCI (fonctions critiques ou importantes). Évaluez la concentration du risque par fournisseur.
• Étape 2 — Revue contractuelle : Auditez vos contrats AWS/Azure/GCP et autres SaaS critiques (Stripe, Twilio, etc.) au regard des clauses DORA obligatoires. Engagez les négociations pour les addendums manquants.
• Étape 3 — Gouvernance et IAM : Renforcez votre gouvernance IAM cloud (MFA, least privilege, rotation de credentials, audit logs). Documentez votre framework de risque TIC approuvé par le board.
• Étape 4 — Chaîne de détection et notification : Déployez des outils de détection cloud (GuardDuty, Defender for Cloud) et configurez une chaîne d'alerte qui respecte le délai de 4 heures. Rédigez des procédures de notification à l'ACPR/AMF.
• Étape 5 — Tests et PCA : Planifiez vos tests de résilience cloud annuels (DR drills, tests de basculement, scan de vulnérabilités cloud). Documentez et testez vos PCA/PRA avec les RTO/RPO ciblés.