DORA and Microsoft 365: what evidence can you produce on your cloud environment?
The EU Digital Operational Resilience Act, known as DORA, has applied since 17 January 2025 to banks, insurers, asset managers and many other financial entities. For most of them, Microsoft 365 and Entra ID hold identities, email and a large share of documents. The challenge is turning that configuration into usable evidence.
DORA in a nutshell
DORA is a directly applicable EU regulation, supplemented by regulatory technical standards that spell out expectations in more detail. It rests on several pillars: ICT risk management, ICT incident management and reporting, digital operational resilience testing, ICT third-party risk management and information sharing. We will not quote specific articles here: exact scope and interpretation belong to your compliance function and legal counsel.
Where Microsoft 365 comes in
Several DORA requirements translate very concretely into a Microsoft 365 tenant:
- Access control: strong authentication, least privilege, review of privileged accounts, management of external accounts;
- Asset protection: encryption, sensitivity labels, data loss prevention;
- Logging: unified audit log enabled, appropriate retention, export to a SIEM;
- Detection: security alerts, risky sign-in detection, monitoring of configuration changes;
- Continuity: emergency access accounts, data backup in line with the shared responsibility model.
The evidence expected
A supervisor or internal auditor will not settle for a written policy. They will want to see that controls are actually in place. For Microsoft 365, that means for example: an export of Conditional Access policies and their exclusions, the list of privileged role holders and how those roles are activated (permanent or through PIM), audit and sign-in log retention periods, guest access settings, and the status of applications holding broad permissions.
Default log retention in Entra ID and Purview depends on your licences and is often shorter than what a post-incident investigation requires. Exporting logs to storage or a SIEM is usually essential.
What a configuration audit provides, and its limits
A configuration audit delivers a dated, reproducible and documented snapshot of the tenant, control by control. It feeds the risk register and remediation plan directly, and it lets you measure progress from one audit to the next. It does not, however, replace continuous monitoring, resilience testing or your incident reporting process. It is one piece of the file, not the whole file.
Repeat the measurement. Compliance evidence carries more weight when it shows a trend. A quarterly or half-yearly audit, with gaps closed between campaigns, demonstrates active risk management rather than a one-off state.
Microsoft as an ICT third-party provider
For a financial entity, Microsoft is a third-party provider that may support critical or important functions. DORA requires these arrangements to be recorded in a register of information, concentration risk to be assessed and exit strategies to be planned. Microsoft publishes documentation and contractual commitments aimed at the financial sector; reviewing them with your legal team is your responsibility. Keep the shared responsibility model in mind: Microsoft secures the platform, but tenant configuration, identities and access remain yours.
Where to start
- Map the critical functions that rely on Microsoft 365.
- Run an Entra ID and Microsoft 365 configuration audit to set a baseline.
- Prioritise gaps affecting privileged access, authentication and logging.
- Document every fix and schedule the next measurement.