DORA sur Azure
Audit-readiness DORA sur Azure, avec des preuves continues plutôt que du conseil récurrent
DORA est, par construction, un régime continu : gestion permanente du risque ICT, tests de résilience obligatoires et registre de tiers à tenir à jour. Governator prend en charge la partie Azure sous forme de tooling managée, pas comme un cycle annuel de conseil.
Ce que DORA exige réellement de votre environnement Azure
Le règlement DORA (Règlement (UE) 2022/2554) est entré en application le 17 janvier 2025 pour les entités financières opérant dans l'UE : banques, assureurs, entreprises d'investissement, établissements de paiement, prestataires de services sur crypto-actifs et bien d'autres. Contrairement à NIS2, qui est transversal, DORA est sectoriel et explicitement prescriptif. Il définit quatre piliers que chaque entité concernée doit démontrer, ainsi qu'un cinquième volet sur le partage d'informations.
Sur Microsoft Azure, les briques sous-jacentes existent : Defender for Cloud, Sentinel, Azure Backup, Site Recovery, Lighthouse, ainsi que les logs d'activité et de coût. Ce qui n'existe pas par défaut, c'est la couche de preuves qui démontre, dans une forme exploitable par le régulateur, que les quatre piliers DORA fonctionnent en continu et que le registre de tiers est à jour.
Governator collecte les preuves Azure, rattache chaque constat à l'article DORA concerné, maintient le registre des tiers ICT (y compris la cartographie service-principal-vers-fournisseur que la plupart des équipes laissent de côté) et produit la trace des tests de résilience à la demande.
Les quatre piliers sur Azure
À chaque pilier correspond un modèle de preuve Azure spécifique. Le tableau ci-dessous résume ce que Governator collecte en continu pour soutenir un audit DORA.
Cadre de gestion du risque ICT
Un cadre documenté et approuvé par la direction qui rattache les contrôles aux risques identifiés, avec revue périodique et entretien démontrable.
Preuves Azure collectées par Governator
Tableau de bord regulatory de Defender for Cloud, état de conformité Azure Policy, registre d'exemptions avec dates de revue, tendance du Secure Score.
Gestion et notification des incidents ICT
Classification, notification et analyse post-incident des incidents ICT majeurs dans les délais définis par le régulateur.
Preuves Azure collectées par Governator
Incidents Sentinel avec métadonnées de timeline, traces du workflow d'alertes Defender, attestations de runbooks, registre des comptes-rendus post-incident.
Tests de résilience opérationnelle numérique
Tests scénarisés annuels pour les entités concernées, plus Threat-Led Penetration Testing (TLPT) tous les trois ans pour les entités significatives.
Preuves Azure collectées par Governator
Attestations des plans de test, matrice de couverture des scénarios, preuves d'actions correctives, résultats de retests datés.
Gestion du risque ICT lié aux tiers
Un registre tenu à jour de tous les contrats ICT avec des tiers, incluant l'évaluation de criticité, la couverture contractuelle et les stratégies de sortie pour les fournisseurs critiques.
Preuves Azure collectées par Governator
Inventaire des service principals rattaché aux fournisseurs tiers, périmètre RBAC par fournisseur, registre des délégations Lighthouse, métadonnées contractuelles.
Pourquoi l'assurance continue convient mieux à DORA que le conseil annuel
DORA a été conçu, dès le texte réglementaire, comme un régime continu. Le registre des tiers ne peut pas dater de douze mois. Les tests de résilience constituent une obligation récurrente, pas un projet. Les notifications d'incidents sont déclenchées par les événements, pas par le calendrier d'audit. Un modèle où l'on commande une évaluation de readiness tous les douze mois, où l'on récupère un nouveau PDF et où l'on accepte la dérive entre deux passages s'accorde mal avec cette régulation.
Le mode assurance continue de Governator est conçu pour cette forme. Le registre des tiers reste à jour parce que l'inventaire des service principals et des délégations Lighthouse tourne selon un planning. La trace des tests de résilience s'enrichit entre les tests formels au lieu d'être reconstruite en fin d'année. Les métadonnées de timeline d'incidents sont captées dès qu'ils se produisent, prêtes pour les fenêtres de notification définies par le régulateur. Et surtout, le budget récurrent finance la chaîne d'outils qui produit des preuves à la demande, plutôt que la commande annuelle d'un livrable de readiness identique.
- ✓Registre des tiers réconcilié avec votre inventaire vivant de service principals et de délégations Lighthouse.
- ✓Trace des tests de résilience avec attestations datées et preuves d'actions correctives, maintenue à jour entre deux cycles TLPT.
- ✓Métadonnées de timeline d'incidents issues de Sentinel et Defender pour les fenêtres de classification définies par le régulateur.
- ✓Le budget récurrent passe des missions externes annuelles de readiness à une tooling managée qui produit à la demande des preuves fraîches.
Ce que Microsoft fournit, et ce qu'il ne fournit pas
Ce que Microsoft fournit
- ✓Defender for Cloud et Secure Score pour l'identification des risques ICT
- ✓Sentinel pour la détection d'incidents et les données de timeline
- ✓Azure Backup, Site Recovery, ainsi que la redondance par zone et par région
- ✓Activity Log et piste d'audit au niveau ressource
- ✓Télémétrie des délégations Lighthouse pour les accès cross-tenant
Ce que Microsoft ne fournit pas
- ✓Le rattachement de chaque constat aux articles DORA (5–14, 17–23, 24–27, 28–44)
- ✓Un registre des tiers ICT entretenu et lié aux accès Azure réels
- ✓Un registre des tests de résilience avec attestations datées et actions correctives
- ✓Des métadonnées de classification d'incidents alignées sur les délais de notification DORA
- ✓Un export pré-audit avec executive summary et matrice de preuves par article
- ✓Un tableau de bord d'assurance continue qui démontre un fonctionnement durable, pas un instantané
Le tableau de bord regulatory de Defender intègre désormais une initiative DORA, ce qui constitue un point de départ utile pour les contrôles des Articles 5–14. Il n'entretient pas pour autant le registre des tiers, la trace des tests de résilience ou les métadonnées de classification d'incidents qu'attend DORA. C'est cette couche opérationnelle que Governator apporte.
Par où commencer
La plupart des entités financières exploitant des workloads Azure démarrent par une évaluation de readiness DORA dans laquelle Governator établit la baseline des quatre piliers : preuves de gestion du risque ICT, alignement des notifications d'incidents, trace des tests de résilience et registre des tiers. L'évaluation produit une roadmap de remédiation cadrée et un dossier de preuves prêt pour le régulateur à un instant T. Ensuite, l'assurance continue maintient le registre à jour, la trace de tests datée et le dossier d'audit régénérable à la demande.
Commencez par un Azure Health Check piloté par Governator
Pas sûr par où commencer ? Une revue rapide d'architecture vous donne une image claire. Sans engagement.
- ✓ Scorecard des risques : identité, réseau, gouvernance et sécurité
- ✓ Top 10 des problèmes classés par impact et effort
- ✓ Feuille de route 30-60-90 jours avec quick wins