NIS2 and DORA: what your Azure platform must be able to prove
NIS2 and DORA ask for evidence, not intentions. Identity, posture, policy, logging, backup and incident response: what your Azure platform must prove.
NIS2 and DORA share the same underlying logic: having "done security" is no longer enough. You need to be able to prove it, continuously, to a regulator, an auditor or a customer. For organisations running on Azure, much of that evidence lives in the platform itself — provided it was designed to produce it.
This is not a legal walkthrough of either text. It starts from a practical question CIOs and CISOs keep asking: what exactly should our Azure environment be able to show?
This article is a technical perspective, not legal advice. To determine whether and how these rules apply to you, talk to your legal counsel or your national cybersecurity authority.
Where NIS2 and DORA stand today
DORA (Regulation (EU) 2022/2554) has applied to financial entities — banks, insurers, asset managers, payment institutions and others — since 17 January 2025. As a regulation, it applies directly with no national transposition. It covers ICT risk management, major incident reporting, resilience testing and oversight of third-party ICT providers, cloud providers included.
NIS2 (Directive (EU) 2022/2555) had to be transposed by Member States by 17 October 2024. Progress has been uneven. France, for example, had still not enacted its transposition law by mid-October 2026: the bill, passed by the Senate in March 2025, is still waiting for its floor debate in the National Assembly. Check the status in each country where you operate. What is not in doubt is the substance of the requirements, which flows from Article 21 of the directive.
Waiting for the final national text before acting would be a mistake. The expected measures — access management, logging, continuity, incident handling — take months to put in place, and customers that fall under NIS2 or DORA are often already asking for them in supplier questionnaires.
What auditors look for: evidence, not intentions
A security policy that exists only on paper carries little weight. What matters is:
- a known scope: which subscriptions, which resources, which sensitive data;
- rules enforced technically, not just documented;
- a measurable state at any point in time, and how it changes;
- traceability: who did what, when, and with which privileges;
- a tested response capability: detect, assess, notify, recover.
Azure has native services for each of these. The work is to switch them on consistently across the whole platform and keep the records.
Mapping requirements to Azure services
The table below maps the main families of measures to the services that enforce them and generate evidence. It is not exhaustive: some requirements — training, supplier management, governance — are primarily organisational.
| Requirement | Azure services | Evidence produced |
|---|---|---|
| Access control, MFA, least privilege | Microsoft Entra ID, Conditional Access, Privileged Identity Management | Access policies, sign-in logs, elevation history |
| Risk and vulnerability management | Microsoft Defender for Cloud (CSPM, workload protection plans) | Secure score, recommendations, regulatory compliance views |
| Enforced configuration rules | Azure Policy, management groups | Compliance state per subscription, logged denials |
| Logging and detection | Activity log, diagnostic settings, Log Analytics, Microsoft Sentinel | Centralised, retained logs; detection rules; incidents |
| Continuity and backup | Azure Backup, Azure Site Recovery, immutable vaults | Backup reports, documented restore tests |
| Encryption and secrets | Azure Key Vault, customer-managed keys where needed | Key inventory, rotation, access logs |
| Incident handling | Sentinel playbooks, Defender for Cloud, documented procedure | Incident timeline, time to triage and notify |
Identity is the first perimeter
Almost every attack path runs through a compromised identity. On Azure, most of the work happens in Microsoft Entra ID: phishing-resistant MFA for administrators, Conditional Access, replacing standing privileged accounts with Privileged Identity Management, and regular access reviews. An auditor will ask for the list of highly privileged accounts and proof that they are under control. You should be able to produce it in minutes.
Posture: measure continuously
Microsoft Defender for Cloud continuously assesses resource configuration against standards such as the Microsoft Cloud Security Benchmark, CIS and ISO 27001. For NIS2 and DORA, the score itself matters less than its trend: it shows that gaps are identified, prioritised and fixed.
Policy: make the rule hard to bypass
A rule that depends on every team's goodwill will eventually be bypassed. Azure Policy, assigned at management group level, lets you deny what should never exist — unjustified public IPs, unencrypted storage, unapproved regions — and audit the rest. Compliance becomes a measurable state, subscription by subscription.
Logging: centralise and retain
No logs, no investigation and no reliable notification. At a minimum, send the activity log of every subscription, Entra ID sign-in and audit logs, and diagnostic logs from critical resources to a central Log Analytics workspace with a defined retention period. Microsoft Sentinel adds detection, correlation and automated response on top.
Backup: prove you can restore
A backup that has never been restored is just an assumption. Azure Backup (with immutable vaults and soft delete to withstand ransomware) and Azure Site Recovery handle the technical side. The evidence comes from scheduled, dated and documented restore tests against RTO and RPO targets agreed with the business.
Incident response: where both texts get demanding
NIS2 requires an early warning within 24 hours of becoming aware of a significant incident, a notification within 72 hours and a final report within a month. DORA requires financial entities to classify ICT-related incidents and report major ones on similarly tight deadlines, set out in its technical standards.
Meeting those deadlines means the platform must quickly surface what you need to assess an incident: scope, timeline, accounts involved, data affected. In practice:
- active detection rules and an alerting path that reaches an on-call person;
- a severity grid shared by IT, security and management;
- playbooks for urgent actions, such as disabling an account or isolating a VM;
- a ready-to-use notification template and up-to-date contacts;
- at least one exercise a year, followed by a written review.
Where to start
You don't need to do everything at once. A sensible order for a mid-sized company:
- map your subscriptions, critical applications, sensitive data and suppliers;
- lock down privileged identities — the best effort-to-risk ratio you will find;
- centralise logs and set their retention;
- turn on Defender for Cloud and a baseline of Azure Policy at management group level;
- test a restore of one critical application;
- write down the incident process, then rehearse it.
Each step produces evidence you can reuse in an audit or a customer questionnaire. It is also what separates box-ticking compliance from security that is actually managed.
To see where your platform stands, our Azure maturity self-assessment gives you a first read in a few minutes across five areas, including security and governance. It is indicative only — for a detailed gap analysis against NIS2 or DORA, let's talk about your context.