NIS2 et DORA : ce que votre plateforme Azure doit pouvoir démontrer
NIS2 et DORA exigent des preuves, pas des intentions. Identités, posture, politiques, journalisation, sauvegarde, incidents : ce qu'Azure doit démontrer.
NIS2 et DORA partagent une logique : il ne suffit plus d'avoir « fait de la sécurité », il faut pouvoir le démontrer, de façon continue, à une autorité, à un auditeur ou à un client. Pour une organisation qui s'appuie sur Azure, une grande partie de ces preuves se trouve dans la plateforme elle-même — à condition qu'elle ait été conçue pour les produire.
Cet article ne fait pas le tour juridique des deux textes. Il part d'une question pratique que posent souvent les DSI et les RSSI : concrètement, qu'est-ce que notre environnement Azure doit être capable de montrer ?
Cet article est une lecture technique et ne constitue pas un conseil juridique. Pour qualifier votre éligibilité et vos obligations, rapprochez-vous de votre conseil ou de l'ANSSI.
Où en sont NIS2 et DORA ?
DORA (règlement (UE) 2022/2554) s'applique depuis le 17 janvier 2025 aux entités financières : banques, assurances, sociétés de gestion, établissements de paiement, etc. C'est un règlement : il est directement applicable, sans transposition. Il couvre la gestion du risque lié aux TIC, la notification des incidents majeurs, les tests de résilience et la maîtrise des prestataires TIC tiers — dont les fournisseurs cloud.
NIS2 (directive (UE) 2022/2555) devait être transposée par les États membres avant le 17 octobre 2024. En France, à la mi-octobre 2026, la loi de transposition n'est toujours pas promulguée : le projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité, adopté par le Sénat en mars 2025, attend encore son examen en séance à l'Assemblée nationale. Le calendrier reste donc incertain, mais le contenu des exigences, lui, est connu : il découle de l'article 21 de la directive.
Attendre le texte définitif pour commencer serait une erreur. Les mesures attendues — gestion des accès, journalisation, continuité, traitement des incidents — demandent des mois de mise en œuvre, et vos clients soumis à NIS2 ou à DORA vous les demandent souvent déjà dans leurs questionnaires fournisseurs.
Ce qu'un auditeur attend : des preuves, pas des intentions
Une politique de sécurité rédigée mais non appliquée ne pèse pas grand-chose. Ce qui compte :
- un périmètre connu : quels abonnements, quelles ressources, quelles données sensibles ;
- des règles appliquées techniquement, pas seulement documentées ;
- un état mesurable à un instant donné, et son évolution dans le temps ;
- une traçabilité : qui a fait quoi, quand, avec quel niveau de privilège ;
- une capacité de réaction testée : détecter, qualifier, notifier, restaurer.
Azure offre des services natifs pour chacun de ces points. Le travail consiste à les activer de façon cohérente, à l'échelle de toute la plateforme, et à en conserver les traces.
Les exigences, traduites en services Azure
Le tableau ci-dessous rapproche les grandes familles de mesures des services qui permettent de les appliquer et d'en produire la preuve. Il ne prétend pas à l'exhaustivité : certaines exigences (formation, gestion des fournisseurs, gouvernance) relèvent d'abord de l'organisation.
| Exigence | Services Azure | Preuve produite |
|---|---|---|
| Contrôle d'accès, MFA, moindre privilège | Microsoft Entra ID, accès conditionnel, Privileged Identity Management | Politiques d'accès, journaux de connexion, historique des élévations |
| Gestion des risques et des vulnérabilités | Microsoft Defender for Cloud (CSPM, plans de protection) | Score de sécurité, recommandations, conformité aux référentiels |
| Règles de configuration imposées | Azure Policy, groupes d'administration | État de conformité par abonnement, refus tracés |
| Journalisation et détection | Journal d'activité, paramètres de diagnostic, Log Analytics, Microsoft Sentinel | Journaux centralisés et conservés, règles de détection, incidents |
| Continuité et sauvegarde | Azure Backup, Azure Site Recovery, coffres immuables | Rapports de sauvegarde, tests de restauration documentés |
| Chiffrement et secrets | Azure Key Vault, clés gérées par le client si nécessaire | Inventaire des clés, rotation, journaux d'accès |
| Traitement des incidents | Sentinel (playbooks), Defender for Cloud, procédure documentée | Chronologie de l'incident, délais de qualification et de notification |
Identités : le premier périmètre
La quasi-totalité des scénarios d'attaque passe par une identité compromise. Sur Azure, c'est dans Microsoft Entra ID que se joue l'essentiel : MFA résistante au phishing pour les administrateurs, accès conditionnel, suppression des comptes à privilèges permanents au profit de Privileged Identity Management, revues d'accès périodiques. Un auditeur demandera la liste des comptes à hauts privilèges et la preuve qu'ils sont maîtrisés — elle doit pouvoir sortir en quelques minutes.
Posture : mesurer en continu
Microsoft Defender for Cloud évalue en continu la configuration des ressources et l'aligne sur des référentiels (Microsoft Cloud Security Benchmark, CIS, ISO 27001…). L'intérêt pour NIS2 et DORA n'est pas le score en lui-même, mais sa trajectoire : il montre que les écarts sont identifiés, priorisés et corrigés.
Politiques : rendre la règle non contournable
Une règle qui dépend de la bonne volonté de chaque équipe finit par être contournée. Azure Policy, appliqué au niveau des groupes d'administration, permet d'interdire ce qui ne doit pas exister (adresses IP publiques non justifiées, stockage sans chiffrement, régions non autorisées) et d'auditer le reste. La conformité devient un état mesurable, abonnement par abonnement.
Journalisation : centraliser et conserver
Sans journaux, pas d'enquête ni de notification fiable. Il faut a minima collecter le journal d'activité de tous les abonnements, les journaux de connexion et d'audit d'Entra ID et les journaux de diagnostic des ressources critiques dans un espace Log Analytics central, avec une durée de conservation définie. Microsoft Sentinel ajoute la détection, la corrélation et l'automatisation de la réponse.
Sauvegarde : prouver qu'on sait restaurer
Une sauvegarde jamais restaurée n'est qu'une hypothèse. Azure Backup (avec coffres immuables et suppression réversible pour résister à un rançongiciel) et Azure Site Recovery couvrent la technique ; la preuve, elle, vient des tests de restauration planifiés, datés et documentés, avec des objectifs RTO/RPO validés par les métiers.
Le processus d'incident : là où les deux textes sont exigeants
NIS2 prévoit une alerte précoce dans les 24 heures suivant la prise de connaissance d'un incident significatif, une notification dans les 72 heures, puis un rapport final dans le mois. DORA impose aux entités financières une classification des incidents liés aux TIC et des délais de notification également très courts, précisés par ses normes techniques.
Tenir ces délais suppose que la plateforme fournisse rapidement les éléments de qualification : périmètre touché, chronologie, comptes impliqués, données concernées. Concrètement :
- des règles de détection actives et un circuit d'alerte qui aboutit à une personne d'astreinte ;
- une grille de qualification de la gravité, partagée entre IT, sécurité et direction ;
- des playbooks pour les gestes urgents (désactiver un compte, isoler une machine) ;
- un modèle de notification prêt à l'emploi et des contacts à jour ;
- un exercice au moins annuel, avec un retour d'expérience écrit.
Par où commencer
Inutile de tout lancer en même temps. Un ordre raisonnable pour une ETI :
- cartographier : abonnements, applications critiques, données sensibles, prestataires ;
- sécuriser les identités à privilèges, c'est le meilleur rapport effort/risque ;
- centraliser les journaux et fixer leur durée de conservation ;
- activer Defender for Cloud et un socle Azure Policy au niveau des groupes d'administration ;
- tester une restauration sur une application critique ;
- formaliser le processus d'incident, puis l'exercer.
Chaque étape produit une preuve réutilisable dans un audit ou un questionnaire client. C'est aussi ce qui distingue une conformité de façade d'une sécurité réellement pilotée.
Pour situer votre plateforme, notre autodiagnostic de maturité Azure donne une première lecture en quelques minutes sur cinq axes, dont la sécurité et la gouvernance. Il reste indicatif : pour une analyse détaillée de vos écarts face à NIS2 ou DORA, parlons de votre contexte.