Microsoft DORA Compliance: Fix Setup & Config Errors
Why This Is Happening
If you're a compliance officer, Azure admin, or IT lead at a bank, insurer, or trading platform inside the European Union , and your Microsoft DORA compliance configuration is failing, incomplete, or throwing up audit gaps , you're not alone. I've worked with dozens of financial institutions who were blindsided by how much groundwork their Microsoft cloud environment needed after January 17, 2025, when the EU Digital Operational Resilience Act (Regulation (EU) 2022/2554) came into force.
Here's the frustrating part: Microsoft's portals and admin centers don't have a single "DORA compliance" toggle you flip on. The regulation spans ICT risk management, incident reporting, operational resilience testing, and third-party oversight, and each of those maps to different parts of the Microsoft ecosystem. Azure Policy. Microsoft Sentinel. Microsoft Purview. The Compliance Manager in Microsoft 365. Most teams try to patch these together without a unified framework and end up with coverage gaps that an auditor will catch immediately.
DORA applies to a wide range of financial services entities, banks, insurance companies, stock exchanges, trading platforms, that operate in the EU, as well as to the ICT third-party providers (like Microsoft) who serve them. Microsoft is preparing to be formally designated as a Critical ICT Third-Party Provider (CTPP) under DORA, meaning the European Supervisory Authorities, EBA, EIOPA, and ESMA, will have direct oversight powers over Microsoft's cloud services at some point. That's a big deal for your contracts and your audit trail.
The root causes of Microsoft DORA compliance failures usually fall into three buckets. First, teams haven't mapped their Microsoft Online Services contracts against DORA's contractual requirements, DORA mandates specific clauses between FSI entities and their ICT providers. Second, the ICT risk management framework inside Microsoft's tools isn't configured to continuously monitor and classify ICT assets and dependencies the way DORA requires. Third, incident detection and notification pipelines, particularly using Microsoft Sentinel and Microsoft Defender, aren't tuned for the specific reporting timelines DORA demands.
None of this means Microsoft isn't DORA-ready. It absolutely is. The problem is configuration, not capability. Let's fix it. Browse all Microsoft fix guides →
The Quick Fix, Try This First
Before you dive into the full configuration overhaul, start with Microsoft Compliance Manager. This is the fastest way to get a baseline DORA gap assessment for your Microsoft 365 and Azure environment, and most teams skip it entirely.
Open the Microsoft Purview compliance portal at compliance.microsoft.com. In the left navigation panel, click Compliance Manager. On the Compliance Manager dashboard, click Add assessments. Search for "DORA" in the regulation search box. If your tenant has the right licensing (Microsoft 365 E3 or E5, or the appropriate Purview add-on), you'll see a DORA assessment template. Select it, assign it to the correct group, and click Create assessment.
Once the assessment generates, it takes anywhere from 30 seconds to a few minutes, you'll get a compliance score and a prioritized list of improvement actions. This score is not your final DORA compliance status; it's a starting point. But it immediately surfaces which Microsoft controls are already in place (things like MFA enforcement, encryption at rest, audit logging) and which gaps need manual remediation.
Pay close attention to the Microsoft-managed actions versus customer-managed actions. Microsoft handles a significant portion of the underlying infrastructure controls, patching, physical security, network resilience, but the customer-managed actions are entirely on you. These typically include ICT asset classification, access control policies, incident response playbooks, and contractual documentation.
After the assessment loads, export the action items to Excel using the Export to Excel button in the top-right of the assessment view. Share this with your DORA project team. This single export gives you a defensible, timestamped baseline that you can reference in regulatory conversations.
DORA requires financial entities to have a formal internal governance and control framework for ICT risk management. This isn't just a policy document, it needs to be operationally embedded in your tools. Microsoft Purview is where you do this for your Microsoft environment.
Navigate to the Microsoft Purview compliance portal (compliance.microsoft.com). Go to Data lifecycle management > Policies. Under Information protection, click Labels and create a classification taxonomy that maps to your ICT asset categories. DORA specifically requires you to identify, classify, and document all ICT-supported business functions, information assets, and ICT assets. Your label taxonomy should reflect those categories, think: Critical Business Function Data, Regulated Financial Data, Internal Operational Data.
Next, set up Data Loss Prevention (DLP) policies under Data loss prevention > Policies > Create policy. Choose Custom policy and scope it to Exchange, SharePoint, OneDrive, and Teams. This creates an automated detection layer over your information assets, a direct DORA requirement under the ICT systems and protocols specification.
For your ICT dependency mapping, use Microsoft Defender for Cloud Apps. Go to Cloud Discovery > Discovered apps. This gives you a live inventory of every cloud application your users are accessing from your corporate environment. Export this quarterly and store it as evidence of your ICT asset and dependency register. If you find shadow IT apps handling financial data, those need to be brought into your DORA third-party risk register immediately.
If your configuration completes correctly, you'll see active DLP policies showing a status of On with a green indicator, and your Cloud Discovery dashboard will be populating with app activity within 24-48 hours of enabling the connector.
DORA mandates that financial entities have mechanisms to promptly detect anomalous activities, network performance issues, and ICT-related incidents, with defined alert thresholds and criteria that trigger incident response processes. Microsoft Sentinel is your primary tool for this inside the Microsoft ecosystem.
In the Azure portal (portal.azure.com), search for Microsoft Sentinel and open your workspace. If you haven't deployed Sentinel yet, click Create Microsoft Sentinel and associate it with a Log Analytics workspace in your EU Azure region (West Europe or North Europe) to keep data residency aligned with DORA's expectations for EU financial entities.
Once inside Sentinel, go to Content hub (left navigation). Search for and install the following content packs, these are pre-built detection rules aligned to financial services threat scenarios:
- Microsoft Defender XDR
- Azure Active Directory
- Microsoft 365
- Azure Activity
- Financial Services (if available in your region)After installing, go to Analytics > Rule templates. Sort by Severity: High. Enable rules covering: anomalous login activity, impossible travel, mass file downloads, privileged role assignment changes, and network performance anomalies. These map directly to DORA's detection requirements.
Critically, go to Settings > Workspace settings > Data retention and set retention to a minimum of 365 days. DORA's incident reporting and post-incident review requirements mean you need at least 12 months of log data readily accessible. If cost is a concern, configure interactive retention for 90 days and archive retention for the remaining 9 months, both satisfy the DORA evidence requirement.
You'll know this step is working when the Overview dashboard in Sentinel shows active incidents being generated and your Log Analytics workspace is ingesting data from all connected sources.
One of DORA's most operationally demanding requirements is the notification of major ICT incidents to competent authorities within defined timeframes. DORA sets out a tiered notification structure: an initial notification, an intermediate report, and a final report. You need an automated workflow that can support this, manual processes will fail under pressure.
Start by defining what constitutes a "major ICT incident" in your environment. DORA's classification criteria include: number of clients affected, duration of the incident, geographic spread, impact on critical or important functions, and economic impact. Build a classification matrix in a SharePoint list or a Microsoft Lists table with these five dimensions and score each incident automatically.
Next, open Power Automate (make.powerautomate.com). Create a new automated cloud flow triggered by When a Microsoft Sentinel incident is created or updated (use the Microsoft Sentinel connector). Add a condition that checks the incident severity (High or Critical). When the condition is met, the flow should:
1. Post a Teams adaptive card to your Security Operations channel
2. Create a task in Microsoft Planner under your "DORA Incident Response" plan
3. Send an email via Outlook to your designated DORA incident coordinator
4. Log a timestamped record to your SharePoint incident registerThe Teams adaptive card should include: incident ID, classification, affected systems, time of first detection, and a direct link to the Sentinel incident. This creates the auditable notification chain that regulators will ask to see during oversight assessments.
For the formal regulatory notification itself (to EBA, EIOPA, or ESMA depending on your sector), that submission happens outside Microsoft's tools, but your Power Automate flow gives you the timestamped evidence that your internal detection and escalation process worked correctly and within the required timeframes. Store the flow run history in a dedicated SharePoint document library as part of your DORA evidence pack.
This step catches most financial institutions off guard, and it's one of the most common DORA compliance failures I see in Microsoft environments. DORA mandates specific contractual requirements between ICT third-party service providers and FSI entities. Your existing Microsoft Online Services Agreement and Data Processing Agreement may not include every clause DORA requires without amendment or additional addenda.
Start by downloading the current Microsoft Product Terms from microsoft.com/licensing/terms and the Microsoft Data Processing Agreement (DPA) from microsoft.com/licensing/docs. Cross-reference these against DORA Article 30, which specifies the minimum contractual provisions required for ICT services supporting critical or important functions.
Key contractual elements that DORA requires, and that you should verify exist in your Microsoft agreements, include:
- Full description of all services and functions to be provided
- Locations where data is processed and stored (EU data residency)
- Provisions on availability, authenticity, integrity, and confidentiality of data
- Specification of SLAs (uptime, response times, recovery time objectives)
- Microsoft's cooperation obligations in incidents and inspections
- Termination rights and data portability provisions
- Subcontracting arrangements (Microsoft's supply chain)Microsoft has proactively aligned its standard contractual provisions to EBA, ESMA, and EIOPA guidance, which forms the baseline framework for DORA's contractual requirements. However, for critical or important functions, you may need to request additional provisions through your Microsoft account team or through the Compliance Program for Microsoft Cloud (CPMC).
Document this review. Create a contractual gap analysis spreadsheet with each DORA Article 30 requirement in column A, the corresponding Microsoft contract clause reference in column B, and a gap/compliant status in column C. This is exactly the evidence an ESA oversight team will request when reviewing your third-party risk management.
DORA requires financial entities to test their digital operational resilience, including through threat-led penetration testing (TLPT) for significant entities. For your Microsoft Azure workloads, Azure Chaos Studio is the native tool for designing and running controlled resilience experiments that generate the kind of evidence DORA's testing requirements call for.
In the Azure portal, search for Azure Chaos Studio. Click Targets in the left menu. Select the resources you want to include in resilience testing, Virtual Machines, AKS clusters, App Services, SQL databases. For each resource, click Enable targets and choose between Service-direct (no agent required, tests the Azure control plane) and Agent-based (requires the Chaos Studio agent installed on the VM for OS-level fault injection).
Create your first experiment by clicking Experiments > Create. Build a branch-step-action structure:
Branch 1 (Availability test):
Step 1: CPU Pressure fault (85% CPU for 10 minutes) on App Service
Step 2: Wait 5 minutes
Step 3: Network latency fault (500ms delay) on SQL connection
Branch 2 (Recovery test):
Step 1: VM shutdown fault on one node of your cluster
Step 2: Measure recovery time against your RTO objectiveRun experiments in a staging environment first. DORA's resilience testing requirements include documenting the test scope, methodology, results, and remediation actions. Export the Chaos Studio experiment results from the Experiment history tab (JSON format) and store these in your DORA evidence library in SharePoint. Each experiment run has a unique run ID and timestamped start/end times, that's your audit trail.
For TLPT specifically (required for significant financial entities), Azure Chaos Studio supports this as an infrastructure layer. Your threat intelligence team or external TLPT provider will need coordination access. Work with your Microsoft account team to arrange the appropriate access controls and non-disclosure arrangements that DORA requires for TLPT engagements.
Advanced Troubleshooting
If you've completed the five steps above and your Compliance Manager score still shows gaps, or if your internal audit team is flagging specific DORA article failures, here's where to dig deeper.
Azure Policy for continuous ICT risk monitoring: Go to the Azure portal > Policy > Definitions. Filter by category: Security Center. Look for the built-in initiative called Microsoft cloud security benchmark (formerly Azure Security Benchmark). Assign this initiative to your subscription. It automatically evaluates 200+ controls across your Azure resources and flags non-compliant resources in real time. This is the closest thing to DORA's continuous ICT risk monitoring requirement natively inside Azure.
Event Viewer for local compliance agent issues: If your Microsoft Purview Information Protection client or Sentinel data connector isn't reporting correctly, open Event Viewer (eventvwr.msc) on the affected machine. Navigate to Applications and Services Logs > Microsoft > AIP (for Purview labeling). Look for Event ID 910 (label policy refresh failure) or Event ID 902 (authentication failure). These typically indicate the machine's Azure AD token has expired or the Purview sensitivity label policy hasn't synced. Run this PowerShell command to force a policy refresh:
Reset-InformationProtectionSettings -OnStartupGroup Policy for enterprise-wide DORA control enforcement: For domain-joined machines in on-premises or hybrid environments, use Group Policy to enforce DORA-relevant security baselines. Download the Microsoft Security Compliance Toolkit from the Microsoft Download Center. Import the Windows 11 or Windows Server 2022 security baseline GPOs into your Group Policy Management Console. The security baseline GPOs enforce audit logging, credential guard, and network protection settings that align directly with DORA's ICT systems and protocols specifications.
Registry paths for Sentinel agent configuration: If your Azure Monitor Agent (AMA) is failing to forward logs to Sentinel, check the registry path:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Azure\MonitoringAgentLook for the WorkspaceId and WorkspaceKey values. If these are missing or incorrect, your logs aren't reaching Sentinel. Re-run the AMA onboarding from the Sentinel Data connectors page, selecting your affected machines.
Microsoft Entra ID (formerly Azure AD) Conditional Access for access control: DORA's ICT risk management framework requires controls over access to ICT systems. Go to Entra admin center (entra.microsoft.com) > Protection > Conditional Access. Ensure you have policies enforcing MFA for all users, blocking legacy authentication protocols, and requiring compliant devices for access to financial data. Run the What If tool to test your policy stack before enabling policies in enforcement mode.
Prevention & Best Practices
DORA isn't a one-time certification. It's an ongoing operational compliance obligation, and that's actually a good thing for your security posture, because it forces you to keep your Microsoft environment genuinely hardened rather than just checkbox-compliant.
The most important preventive measure is establishing a quarterly DORA review cycle. Set a recurring meeting every 90 days to re-export your Compliance Manager assessment, review your Sentinel incident statistics, audit your ICT asset register in Purview, and check whether your Microsoft contractual arrangements have been updated by Microsoft (they do update the Product Terms periodically, and some updates affect your DORA-relevant clauses).
Second, assign a named DORA Microsoft Workload Owner, one person who owns the relationship between your DORA obligations and your Microsoft environment configuration. This person should have at minimum the Compliance Administrator role in Microsoft 365 and Security Reader in Azure. Without a named owner, configuration drift happens silently and your compliance score erodes between audits.
Third, integrate your Microsoft Secure Score with your DORA risk register. Go to security.microsoft.com > Secure score. Your Microsoft Secure Score measures your security posture across Microsoft 365 and Azure. Any score below 70% is a risk indicator that likely maps to DORA ICT risk management gaps. Treat Secure Score improvement as a DORA compliance task, not just a security best practice.
Finally, test your incident response playbook at least twice a year using a tabletop exercise that includes your Sentinel alert-to-notification workflow. DORA's operational resilience testing requirements aren't just about infrastructure, they include your team's ability to execute under pressure. Document every tabletop exercise with attendees, scenarios tested, findings, and remediation actions. That documentation is DORA evidence.
- Enable Microsoft Purview's DORA assessment template in Compliance Manager today, it takes 10 minutes and gives you an instant gap list
- Set Sentinel log retention to 365 days minimum, DORA's incident reporting look-back period demands it
- Run the Microsoft Security Baseline GPO against your domain, it covers 40+ DORA ICT protocol requirements automatically
- Request the Microsoft DORA contractual addendum through your account team before your next annual contract renewal
Frequently Asked Questions
Does Microsoft count as a Critical ICT Third-Party Provider (CTPP) under DORA?
Microsoft is preparing to be formally designated as a Critical ICT Third-Party Provider under DORA, meaning the European Supervisory Authorities, EBA, EIOPA, and ESMA, will have direct supervisory powers over relevant Microsoft cloud services once that designation occurs. This doesn't change your compliance obligations as a financial entity, but it does mean Microsoft will be subject to heightened regulatory scrutiny and will be required to comply with specific provisions applicable to CTPPs. For your purposes, Microsoft is treating this designation as a near-certainty and has committed to compliance, which is actually reassuring from a supply chain risk perspective.
We're using Microsoft 365 Business Premium, not E5, do we still need DORA compliance controls?
DORA obligations apply to your organization as a financial entity, the Microsoft license tier you hold doesn't change that. What your license tier does change is which Microsoft tools are available to you for meeting those obligations. Business Premium gives you Defender for Business, basic Purview Information Protection, and Entra ID P1. You won't have Sentinel, Purview Advanced Compliance, or the full Compliance Manager DORA assessment template. For regulated FSI entities with Business Premium, I strongly recommend a licensing conversation with your Microsoft partner, the compliance gap between Business Premium and E5 is significant for DORA purposes.
Does DORA require us to get Microsoft to sign something specific, or is the standard contract enough?
DORA Article 30 specifies minimum contractual provisions that must be present in agreements between FSI entities and ICT third-party service providers supporting critical or important functions. Microsoft's standard Online Services Terms and DPA align to EBA, ESMA, and EIOPA guidance, which forms the baseline for DORA's contractual requirements, but you should conduct a formal gap analysis against Article 30 for your specific use case. For critical function workloads running on Azure or Microsoft 365, you may need additional commitments around audit rights, SLAs, and sub-processor transparency. Your Microsoft account team can discuss DORA-specific contractual provisions and direct you to the Compliance Program for Microsoft Cloud for more complex scenarios.
What does DORA's threat-led penetration testing (TLPT) requirement mean for our Azure environment?
TLPT under DORA is a red team exercise driven by real threat intelligence specific to your sector, not a standard vulnerability scan. For Azure workloads, you need to engage an approved external TLPT provider who will simulate advanced persistent threat techniques against your live environment (with appropriate safeguards). Microsoft allows authorized TLPT engagements against Azure under its penetration testing rules of engagement, provided you notify Microsoft at least 48 hours in advance via the Azure penetration testing notification form. Azure Chaos Studio can complement TLPT by validating recovery capabilities after simulated attack scenarios. The TLPT applies to significant financial entities, your regulator will confirm whether you fall into that category.
How long do we have to report a major ICT incident to regulators under DORA, and how does Microsoft Sentinel help?
DORA sets a tiered notification timeline: an initial notification to your competent authority within 4 hours of classifying an incident as major (and no later than 24 hours of first detection), an intermediate report within 72 hours, and a final report within one month. Microsoft Sentinel accelerates your ability to meet the initial 4-hour window by detecting and alerting on anomalous activity in near real-time. The key is having your Sentinel analytics rules tuned to your DORA incident classification criteria, and your Power Automate escalation workflow pre-built so that when a high-severity incident fires in Sentinel, your team is notified in minutes, not hours. The actual regulatory submission goes through your national competent authority's reporting portal, but Sentinel gives you the evidence base and the timestamp trail.
Our organization operates outside the EU but we have EU customers, does DORA apply to our Microsoft environment?
DORA's scope explicitly covers ICT third-party service providers who provide services to EU FSI entities, regardless of where the provider is located. If your organization provides ICT services, even indirectly, to EU-regulated financial entities, DORA's requirements may reach you depending on whether you're designated as critical. For FSI entities operating outside the EU but serving EU clients, the obligations typically apply to the EU-facing operations and the ICT systems supporting them. Your Microsoft environment that processes data for EU clients should be configured to DORA standards for those workloads. Consult your legal counsel on the precise scoping for your organization's structure, and use the Compliance Manager assessment to understand where your current Microsoft configuration stands against the standard.