Conformité DORA pour les infrastructures cloud : Guide AWS & Azure 2025

Le Digital Operational Resilience Act (DORA — UE 2022/2554) est pleinement applicable depuis le 17 janvier 2025. Si votre institution fonctionne sur AWS ou Azure et opère dans les services bancaires, l'assurance, la gestion d'investissements ou les services de paiement, les exigences TIC de DORA sont désormais juridiquement contraignantes. Ce guide associe les obligations d'infrastructure du règlement à des vérifications concrètes de configuration cloud.

Qui est concerné par DORA ?

DORA s'applique à un large éventail d'entités financières opérant dans l'UE :

• Les établissements de crédit (banques) et les établissements de paiement
• Les entreprises d'investissement et les sociétés de gestion d'actifs
• Les entreprises d'assurance et de réassurance
• Les prestataires de services sur crypto-actifs (CASPs)
• Les prestataires tiers de services TIC désignés comme « critiques » par les ESA

Contrairement à NIS2, qui utilise des seuils d'effectifs et de revenus, DORA s'applique par secteur — pas par taille. Une fintech de deux personnes acceptant des paiements entre dans le champ d'application tout autant qu'une grande banque.

Exigences de gestion du risque TIC DORA (Articles 5–16)

Le chapitre II de DORA définit un cadre complet de gestion du risque TIC. Pour l'infrastructure cloud, cela se décompose en cinq domaines techniques :

1. Identification et classification (Art. 8)

• Tous les actifs TIC inventoriés — y compris les comptes cloud, les régions et les services
• Les fonctions métier soutenues par chaque actif documentées
• Classification des données appliquée à toutes les ressources de stockage (S3, RDS, Azure Blob, SQL)
• Dépendances vis-à-vis des fournisseurs tiers TIC (AWS, Azure) formellement documentées

2. Protection (Art. 9)

• MFA imposé sur tous les utilisateurs IAM et comptes privilégiés
• Chiffrement au repos sur tous les stockages : S3 (SSE-KMS), RDS, EBS, DynamoDB, Azure SQL (TDE), Azure Storage
• Chiffrement en transit : TLS 1.2+ imposé, pas de suites de chiffrement obsolètes
• Segmentation réseau : pas de groupes de sécurité ouverts sur 0.0.0.0/0 sur les ports sensibles
• Rotation des clés KMS activée (minimum annuel)
• Secrets stockés dans AWS Secrets Manager ou Azure Key Vault — jamais dans les variables d'environnement

3. Détection (Art. 10)

• CloudTrail activé dans toutes les régions avec validation des fichiers journaux et chiffrement KMS
• Rétention Azure Monitor / Activity Log ≥ 12 mois
• GuardDuty activé pour la détection d'anomalies et de menaces
• VPC Flow Logs et Azure NSG Flow Logs actifs
• Alarmes CloudWatch sur l'utilisation du compte root, les modifications de politique IAM et les échecs d'authentification
• Intégration SIEM centralisée avec stockage de journaux infalsifiable

4. Réponse et récupération (Art. 11–12)

• Sauvegardes automatiques RDS avec ≥7 jours de rétention ; restaurations testées documentées
• Multi-AZ activé pour les bases de données de production
• Versioning S3 et réplication inter-région pour les données critiques
• Sauvegarde géo-redondante Azure SQL activée
• Recovery Time Objective (RTO) et Recovery Point Objective (RPO) formellement définis
• Plan de continuité d'activité mis à jour au moins annuellement et après les incidents majeurs

5. Apprentissage et évolution (Art. 13)

• Revues post-incident documentées avec analyse des causes profondes
• Flux de renseignement sur les menaces intégrés dans les outils de détection
• Scan de vulnérabilités sur tous les workloads EC2 et conteneurs (Amazon Inspector, Defender for Cloud)
• Gestion des correctifs dans des SLA définis (DORA ne précise pas les délais — vous devez les définir et les prouver)

Notification d'incidents (Article 19) — l'horloge des 72 heures

DORA établit un calendrier strict de notification en trois étapes pour les incidents TIC majeurs :

• Notification initiale : dans les 4 heures suivant la classification comme majeur (ou 24h après la première prise de connaissance)
• Rapport intermédiaire : dans les 72 heures — évaluation de l'impact mise à jour et statut de confinement
• Rapport final : dans 1 mois — analyse complète des causes profondes et mesures correctives

Cela exige que votre stack de détection et d'alerte puisse identifier, classifier et escalader un incident TIC en quelques heures. Les alarmes CloudWatch, les findings GuardDuty routés vers PagerDuty ou Slack, et un processus de classification documenté sont des exigences minimales.

Risque tiers TIC (Articles 28–44)

DORA impose des obligations significatives sur la façon dont vous gérez les fournisseurs cloud comme AWS et Azure. Exigences clés :

• Arrangements contractuels écrits avec tous les fournisseurs tiers TIC (Art. 30) — votre MSA et DPA cloud satisfont la base
• Registre de toutes les dépendances tiers TIC maintenu et mis à jour
• Stratégie de sortie documentée pour les dépendances tiers critiques
• Évaluation annuelle du risque de concentration tiers — si 90 % de votre workload fonctionne sur un seul fournisseur cloud, cela doit être évalué et atténué
• Pour les fournisseurs tiers TIC critiques (désignés par les ESA) : un cadre de supervision renforcé s'applique directement — actuellement en évaluation pour les grands hyperscalers cloud

DORA vs NIS2 — quels chevauchements ?

DORA et NIS2 partagent environ 40 % des contrôles techniques au niveau de l'infrastructure. Les deux exigent chiffrement, contrôle d'accès, journalisation, réponse aux incidents et continuité d'activité. Les différences clés :

• Portée : NIS2 couvre largement les infrastructures critiques ; DORA est spécifique au secteur financier
• Délais d'incidents : NIS2 exige une alerte précoce de 24h + notification de 72h ; DORA exige 4h initial + 72h intermédiaire + 1 mois final
• Risque tiers : DORA va beaucoup plus loin — Art. 28-44 sont largement absents de NIS2
• Tests : DORA impose des TLPT (Threat-Led Penetration Testing) annuels pour les entités significatives — NIS2 recommande mais n'impose pas

Si votre organisation est soumise aux deux, corriger les lacunes NIS2 en premier couvre la majeure partie de la base DORA — puis concentrez-vous sur les ajouts spécifiques DORA (registres tiers, TLPT, processus de classification en 4h).

Sanctions DORA

Les autorités de surveillance (autorités nationales compétentes — ANC) peuvent imposer :

• Des amendes administratives jusqu'à 1 % du chiffre d'affaires quotidien moyen mondial par violation, par jour de non-conformité
• Des astreintes jusqu'à 1 % du chiffre d'affaires quotidien pendant 6 mois maximum
• Des déclarations publiques nommant l'institution et la nature de la violation
• Pour les fournisseurs tiers TIC critiques : amendes jusqu'à €5 millions ou 1 % du chiffre d'affaires mondial

Comment automatiser les vérifications de conformité DORA

Les exigences de risque TIC de DORA se mappent directement sur la configuration d'infrastructure. Chaque exigence de chiffrement, de contrôle d'accès et de journalisation dans les articles 9-10 peut être vérifiée automatiquement contre votre environnement cloud live.

ConformScan exécute des vérifications mappées DORA sur vos comptes AWS et Azure en moins de 2 minutes — couvrant le chiffrement au repos et en transit, les contrôles IAM, la complétude de la journalisation, la configuration des sauvegardes et l'exposition réseau. Vous obtenez :

• Des findings mappés DORA avec des comptes à rebours SLA (3 → 14 → 30 jours, alignés sur les délais Art. 19)
• Vue multi-framework : voyez quels findings affectent simultanément DORA, NIS2 et ISO 27001
• Code de remédiation Terraform et CLI pour chaque finding
• Rapports PDF prêts pour votre responsable conformité, auditeur ou soumission ANC
• Scans quotidiens planifiés pour détecter la dérive de configuration avant qu'elle devienne un incident à déclarer

Par où commencer

Si vous démarrez votre programme de conformité DORA aujourd'hui, priorisez dans cet ordre :

1. Effectuer un scan de référence — connaître votre exposition actuelle dans tous les domaines de risque TIC
2. Corriger les findings critiques en premier — lacunes de chiffrement, bases de données publiques, MFA manquant
3. Construire votre registre d'actifs TIC — documenter les comptes cloud, services et dépendances tiers
4. Établir votre processus de classification des incidents — l'horloge des 4h commence quand vous en avez connaissance, pas quand vous décidez que c'est majeur
5. Documenter les contrats tiers — examiner vos MSA AWS et Azure par rapport aux exigences DORA Art. 30

DORA n'est pas un projet avec une date de fin — il exige une surveillance continue de votre posture de risque TIC. Le scanning automatisé via conformscan.com garantit que vos contrôles restent efficaces entre les audits.