Publié le 7 juillet 2026 · Conformité & sécurité cloud

DORA et sécurité cloud : ce que le règlement change pour vos environnements AWS, Azure et GCP

Le règlement DORA (Digital Operational Resilience Act, règlement UE 2022/2554) est en application directe dans toute l’Union européenne depuis le 17 janvier 2025. Il vise les entités financières au sens large : banques, assurances, sociétés de gestion, établissements de paiement, prestataires de services sur crypto-actifs (PSAN), et bien d’autres. Si votre organisation entre dans ce périmètre et qu’elle s’appuie sur AWS, Azure ou GCP — ce qui est aujourd’hui la norme — alors le cloud n’est pas un détail de mise en œuvre : il se trouve au centre de plusieurs obligations du texte.

La raison est simple : en consommant des services cloud, vous confiez une partie de votre résilience opérationnelle à un prestataire tiers de services TIC, catégorie que DORA encadre explicitement. Cet article ne paraphrase pas le règlement : il traduit chacun de ses cinq piliers en contrôles de sécurité cloud vérifiables, sur AWS, Azure et GCP, et précise ce que l’année 2026 change pour les équipes qui doivent démontrer leur conformité.

DORA en bref : cinq piliers

DORA structure la résilience opérationnelle numérique autour de cinq piliers. Il est utile de les avoir en tête avant de parler technique, car chacun se projette différemment sur vos environnements cloud.

1. Gouvernance et gestion du risque lié aux TIC. L’organe de direction est responsable : il doit approuver le cadre de gestion du risque, l’inventaire des actifs et des dépendances, et s’assurer de son maintien dans le temps. 2. Gestion, classification et notification des incidents majeurs liés aux TIC. Les incidents doivent être détectés, classés selon des critères harmonisés, puis notifiés aux autorités compétentes dans des délais contraints. 3. Tests de résilience opérationnelle numérique. Des tests réguliers sont exigés, allant du test de vulnérabilité aux tests avancés dits TLPT (threat-led penetration testing, inspirés de TIBER-EU) pour les entités les plus significatives. 4. Gestion du risque lié aux prestataires tiers de TIC. Elle inclut la tenue d’un registre d’information (RoI) recensant tous les accords contractuels portant sur des services TIC, à remettre aux autorités. 5. Partage d’informations sur les cybermenaces entre entités, sur une base volontaire.

En France, les autorités compétentes sont l’ACPR pour la banque et l’assurance, et l’AMF pour les marchés ; l’ANSSI intervient sur la coordination et la notification des incidents. Un point majeur pour le cloud : les prestataires tiers critiques de services TIC — typiquement les grands hyperscalers — peuvent être désignés comme critiques et placés sous la supervision directe des autorités européennes de surveillance (les AES : EBA, ESMA, EIOPA). Cette supervision porte sur le fournisseur, mais elle ne vous décharge en rien de vos propres obligations sur ce que vous déployez dans son cloud.

Pourquoi le cloud est au cœur de DORA

Deux notions expliquent la place centrale du cloud dans le règlement. La première est le modèle de responsabilité partagée. Le fournisseur sécurise le cloud — datacenters, hyperviseur, réseau physique ; vous sécurisez ce qui se trouve dans le cloud — configurations, identités, données, workloads. DORA vous tient responsable de votre part, et la frontière exacte varie selon les services : une base managée et une VM brute ne placent pas le curseur au même endroit. Documenter qui fait quoi est déjà un exercice de conformité en soi.

La seconde notion est le risque de concentration. Faire reposer l’essentiel de votre production sur un seul hyperscaler, dans une seule région, crée une dépendance dont la défaillance affecterait toute votre activité — exactement le type de risque systémique que DORA cherche à contenir. Le règlement attend de vous une évaluation lucide de cette concentration, mais aussi une stratégie de sortie et de réversibilité : êtes-vous techniquement capable de migrer et de récupérer vos données dans un format exploitable ? À cela s’ajoutent la sous-traitance en chaîne, la localisation et le chiffrement des données, et un droit d’audit et d’accès contractuellement garanti.

Des piliers DORA aux contrôles cloud concrets

Les exigences de DORA restent volontairement technologiquement neutres. La difficulté opérationnelle consiste à les traduire en contrôles précis sur AWS, Azure et GCP. Voici comment chaque pilier se projette dans la pratique.

Gestion du risque tiers et registre d’information. Le RoI suppose de savoir exactement quels services cloud vous consommez, dans quelles régions et pour quelles fonctions critiques. Or l’inventaire réel diverge presque toujours de l’inventaire déclaré : comptes oubliés, services activés par une équipe sans validation, ressources orphelines. Un inventaire continu et sans agent des ressources AWS, Azure et GCP — le socle d’un CNAPP — alimente directement cette cartographie et la maintient à jour.

Notification des incidents majeurs. Détecter puis qualifier un incident suppose une journalisation exhaustive et exploitable : CloudTrail sur tous les comptes AWS, Azure Monitor et journaux d’activité côté Azure, Cloud Logging côté GCP — le tout centralisé, immuable et conservé sur une durée suffisante. Un compte de production sans journalisation est un angle mort qui vous rend incapable de reconstituer un incident, donc de le notifier dans les délais.

Tests de résilience opérationnelle. DORA attend un programme de tests gradué. Pour le cloud, cela va de l’analyse continue des vulnérabilités et des expositions à des exercices offensifs ciblés. Un pentest d’infrastructure cloud éprouve concrètement vos chemins d’attaque ; pour les entités significatives, les tests avancés TLPT vont plus loin en simulant des scénarios de menace réalistes de bout en bout.

Gouvernance et cartographie des dépendances. La responsabilité de l’organe de direction se nourrit d’une vision claire des dépendances entre actifs, identités et données. La cartographie des identités humaines et machines, et surtout des chemins d’attaque qui relient une exposition à une donnée sensible, transforme une obligation abstraite en une image concrète du risque réel.

Ce que 2026 change concrètement

L’année 2025 a été une phase d’accompagnement, ponctuée de premiers contrôles ciblés : les autorités ont laissé le temps aux entités de structurer leur démarche. 2026 marque l’intensification des audits de conformité. La tolérance implicite de la première année laisse place à des demandes de preuves formelles : registre d’information à jour et remis dans les formats attendus, traçabilité des incidents, programme de tests documenté, contrats fournisseurs conformes.

Le changement de nature est important : en 2025, affirmer que l’on « travaillait sur le sujet » pouvait suffire ; en 2026, il faut montrer. Or beaucoup d’organisations découvrent à ce moment que leur inventaire cloud est incomplet, que certains comptes n’ont jamais eu de journalisation, ou que personne ne sait situer précisément quelle identité peut accéder à quelle donnée. Ces lacunes ne se comblent pas la veille d’un audit : elles supposent une posture outillée et mesurée en continu.

Comment un CNAPP et un audit aident à démontrer la conformité

Répétons-le d’emblée : aucun outil ne rend conforme à DORA, qui reste avant tout une affaire de gouvernance, de contrats et d’organisation. Mais plusieurs piliers ont une composante technique forte, et c’est là qu’une plateforme et un regard externe apportent des preuves tangibles.

Un CNAPP fournit une posture continue : il inventorie en permanence vos ressources AWS, Azure et GCP, mesure leur conformité à des référentiels (CIS, ISO 27001, cadres réglementaires) et signale toute dérive. Il produit la cartographie des identités et des chemins d’attaque en corrélant configurations, workloads et permissions dans un graphe unique, ce qui alimente directement la gouvernance du risque TIC. Enfin, ses rapports datés constituent une preuve de conformité exploitable en audit : état de la posture à un instant donné, historique des corrections, couverture de la journalisation.

L’audit et le pentest complètent ce dispositif par une évaluation indépendante. Un audit de sécurité cloud établit un état des lieux objectif de vos environnements ; un pentest d’infrastructure cloud éprouve concrètement la résilience attendue par le pilier de tests. Notre offre de conformité cloud aide à relier ces preuves techniques aux exigences du règlement.

En tant qu’éditeur français d’un CNAPP agentless établi dans l’Union européenne, Cyvex se place du côté des enjeux de souveraineté et de maîtrise du risque tiers que DORA met en avant. Nous ne vendons pas une conformité clé en main : nous outillons les piliers techniques et documentons les preuves qui font la différence le jour de l’audit.

Questions fréquentes

DORA s’applique-t-il à mon entreprise si j’utilise le cloud ?

DORA s’applique en fonction de votre statut, pas de votre usage du cloud. Le règlement vise les entités financières au sens large : banques, assurances, sociétés de gestion, établissements de paiement, prestataires de services sur crypto-actifs, et bien d’autres. Si vous relevez de l’une de ces catégories, DORA s’applique que vous soyez dans le cloud ou non. En revanche, dès lors que vous utilisez AWS, Azure ou GCP, votre fournisseur devient un prestataire tiers de services TIC au sens du règlement, et le pilier de gestion du risque tiers s’active pleinement : contrat conforme, registre d’information, stratégie de sortie et surveillance continue de la posture.

DORA impose-t-il d’héberger ses données en Europe ?

Non, DORA n’impose pas en lui-même la localisation des données dans l’Union européenne. Son exigence porte sur la maîtrise du risque lié au prestataire tiers : évaluation des risques de concentration, clauses contractuelles adéquates, droit d’audit et d’accès, et surtout une stratégie de sortie et de réversibilité crédible. La localisation peut néanmoins être imposée par d’autres cadres qui s’appliquent en parallèle : le RGPD pour les transferts de données personnelles, ou une qualification SecNumCloud pour certaines données sensibles. DORA et ces cadres se cumulent : il faut lire les exigences ensemble, pas isolément.

Quelle différence entre DORA et NIS2 ?

NIS2 est une directive à large spectre qui vise la cybersécurité de nombreux secteurs essentiels et importants (énergie, transport, santé, administration, etc.). DORA est un règlement sectoriel dédié au secteur financier et centré sur la résilience opérationnelle numérique. En vertu du principe de lex specialis, pour les entités financières couvertes par DORA, ce sont les exigences de DORA qui priment sur celles de NIS2 pour les mêmes sujets. Nous détaillons le volet cloud de la directive dans notre article sur NIS2 et la conformité cloud.

Un CNAPP suffit-il pour être conforme à DORA ?

Non : un outil n’est jamais la conformité. DORA est un règlement de gouvernance qui exige des politiques, des rôles, des contrats, des tests et une organisation, dont une part importante est documentaire et humaine. Un CNAPP ne couvre pas ces volets. En revanche, il outille concrètement plusieurs piliers techniques : inventaire continu des services cloud consommés, cartographie des identités et des chemins d’attaque pour la gestion du risque, journalisation exploitable pour la détection et la notification d’incidents, et production de preuves de posture pour les audits. Le CNAPP est un moyen de preuve et de contrôle, pas un certificat de conformité.