Microsoft's Concentration Risk Framework: A Cloud Provider Writes Its Own DORA Compliance Guide

Inside the Framework: What Microsoft Proposed

Microsoft's concentration risk framework was structured around four dimensions that financial institutions should assess: dependency depth, concentration factors, exit complexity, and contractual provisions.

Dependency Depth Assessment

The framework proposed a taxonomy for classifying workload dependency on cloud services, ranging from shallow dependencies (infrastructure-as-a-service where the application is portable across providers) to deep dependencies (platform-specific services using proprietary APIs, managed databases with provider-specific features, and AI/ML services trained on provider-specific infrastructure).

For financial institutions, this taxonomy is directly relevant to DORA Art. 29's concentration risk assessment. Workloads with shallow dependencies pose lower concentration risk because migration to an alternative provider is technically feasible within reasonable timeframes. Workloads with deep dependencies — particularly those using provider-specific managed services — create lock-in that makes exit strategies significantly more complex and costly.

The practical implication is that financial institutions should actively manage dependency depth as a risk factor. Using provider-specific services may offer short-term operational advantages, but each deepening of dependency increases the concentration risk and complicates exit planning. Architecture decisions that favor portability over provider-specific optimization reduce long-term concentration risk — a trade-off that DORA Art. 29 implicitly requires institutions to evaluate.

Concentration Factor Analysis

Microsoft's framework identified several dimensions of concentration risk that institutions should monitor: the percentage of critical workloads hosted with a single provider, the geographic concentration of workloads within a single provider's regions, the depth of integration with provider-specific services, the availability of alternative providers for equivalent services, and the institution's organizational capability to manage multi-cloud environments.

This multi-dimensional analysis goes beyond the simplistic "how much do we spend with this provider" approach that many institutions initially adopted for DORA Art. 29 compliance. Concentration risk is not just about spending — it is about the operational dependency that spending creates. An institution that spends modestly with a cloud provider but hosts its core banking system on that provider's platform has a deeper concentration risk than an institution that spends more but uses the provider only for non-critical workloads.

Exit Strategy Tiers

Perhaps the most practically useful element of the framework was its tiered approach to exit strategies. Microsoft proposed three tiers based on workload complexity and criticality. Tier 1 covered data-level portability — ensuring that all data can be exported in standard formats (JSON, CSV, Parquet) at any time, with documented export procedures and tested export capabilities. Tier 2 covered application-level portability — workloads that can be migrated to alternative providers within a defined timeframe (typically 3-12 months) using containerization, infrastructure-as-code, and abstraction layers. Tier 3 covered deeply integrated workloads requiring multi-year migration planning — including core banking systems, complex data analytics pipelines, and AI/ML models trained on provider-specific infrastructure.

The tiered approach is realistic. It acknowledges that not all workloads can be quickly migrated, and that exit strategies must be proportionate to the complexity and criticality of the workload. For DORA Art. 30 compliance, this tiered approach provides a practical framework for the exit strategy provisions that contracts with ICT providers must include.

The Provider Who Acknowledged the Problem

On February 2, 2026, Microsoft published a detailed framework addressing cloud concentration risk and exit strategies in the context of DORA compliance. This was a remarkable document — a major cloud provider publicly acknowledging that its own market dominance creates concentration risk for the financial sector, and providing a structured approach for institutions to manage that risk.

The publication was strategic. DORA Art. 28-29 requires financial entities to assess concentration risk in their ICT third-party arrangements, and Art. 31 establishes the framework for designating Critical ICT Third-Party Providers (CTPPs). Microsoft Azure, as one of the three dominant cloud platforms serving European finance, was likely to be among the first providers designated as a CTPP. By proactively publishing a concentration risk and exit strategy framework, Microsoft was simultaneously demonstrating good faith engagement with the regulatory process and shaping the terms of the conversation about cloud concentration risk.

The framework addressed a genuine pain point for financial institutions. DORA Art. 28(2) requires institutions to assess whether contracting with a particular ICT provider would create undue concentration risk. Art. 29 requires an ongoing assessment of ICT concentration risk. Art. 30 specifies that contracts with ICT providers must include exit strategies and transition plans. But the practical challenge of implementing these requirements for major cloud platforms — where migration to an alternative provider is a multi-year, multi-million-dollar undertaking — had left many compliance teams struggling.

Microsoft's framework did not pretend that exit from a major cloud provider is simple. Instead, it acknowledged the complexity and proposed a structured approach that included assessing the degree of dependency (workload criticality, data sensitivity, integration depth), identifying concentration risk factors (single-cloud vs. multi-cloud, regional distribution, service substitutability), developing tiered exit strategies (ranging from data portability provisions for low-complexity workloads to multi-year migration plans for deeply integrated systems), and defining contractual provisions that support exit planning (data export formats, API documentation, transition assistance commitments).

For the DORA compliance community, the Microsoft framework was both useful and provocative. Useful because it provided practical guidance that compliance teams could adapt to their own institutions. Provocative because it raised the question of whether a cloud provider's self-authored concentration risk framework adequately addresses the risks that the provider itself creates.

DORA Art. 28-30 Through Microsoft's Lens

Microsoft's framework provides a cloud provider's perspective on DORA's third-party risk management requirements — a perspective that is valuable precisely because it comes from the entity that creates the concentration risk.

Art. 28 — Provider Self-Assessment

DORA Art. 28 requires financial entities to manage ICT third-party risk. Microsoft's framework effectively inverted this: it provided the provider's own assessment of the risks its services create for financial institutions. This provider self-assessment is unusual — most risk management frameworks assume that risk assessment is the customer's responsibility. Microsoft's approach acknowledged that the provider has better visibility into its own architecture, capabilities, and limitations, and that sharing this visibility improves the quality of the customer's risk assessment.

For financial institutions, provider self-assessments should be treated as valuable inputs to, but not substitutes for, independent risk assessment. A provider's framework naturally emphasizes the mitigations it offers while potentially underemphasizing the risks it creates. Independent assessment — supplemented by provider transparency — produces the most complete picture.

Art. 29 — Concentration Risk from the Provider's Perspective

Microsoft's concentration factor analysis aligned with DORA Art. 29's requirements for ongoing concentration risk assessment. The framework's multi-dimensional approach — considering dependency depth, geographic concentration, service substitutability, and organizational capability — provides a more sophisticated assessment methodology than the spending-based approaches that many institutions initially adopted.

The framework also addressed a frequently overlooked dimension of concentration risk: the institution's organizational capability to manage alternatives. Even if technically feasible alternatives exist, an institution that has trained all its technical staff on Azure, built all its automation around Azure APIs, and organized its operations around Azure's management paradigms faces significant organizational switching costs that affect the practical viability of exit strategies.

Art. 30 — Exit Strategy Realism

The tiered exit strategy approach is perhaps the most significant contribution of Microsoft's framework to DORA Art. 30 compliance. The regulation requires contracts to include exit strategies, but does not prescribe the form those strategies must take. Microsoft's framework acknowledged the practical reality that exit from a major cloud platform is not a single event but a staged process that may take years for deeply integrated workloads.

This realism is important for DORA compliance. An exit strategy that claims all workloads can be migrated within 30 days is not credible for a bank running its core banking system on a cloud platform. A tiered strategy that provides immediate data portability (Tier 1), 3-12 month application migration for portable workloads (Tier 2), and multi-year planning for deeply integrated systems (Tier 3) is more honest and more useful.

For supervisory authorities assessing DORA Art. 30 compliance, the tiered approach suggests that exit strategy adequacy should be evaluated relative to workload complexity, not against a universal timeline. The key questions are: can data be exported? Can portable workloads be migrated within reasonable timeframes? Is there a credible plan for deeply integrated systems? These questions are more useful than "can you exit within 30 days?" for most real-world cloud deployments.

Provider-Led Frameworks: Opportunity and Risk

Microsoft's concentration risk framework is a significant development in the DORA ecosystem, but it must be evaluated with appropriate skepticism. A framework authored by the entity that creates the concentration risk has inherent limitations alongside its genuine value.

The Value

The framework provides practical, detailed guidance that compliance teams can immediately use. It acknowledges the complexity of cloud exit planning with more honesty than most regulatory guidance. It offers a structured methodology for concentration risk assessment that goes beyond simplistic metrics. And it signals that major cloud providers are engaging constructively with DORA's requirements rather than resisting them.

For financial institutions, the framework's exit strategy tiers provide a realistic basis for DORA Art. 30 contract negotiations. Rather than demanding impossible 30-day exit timelines, institutions can negotiate tiered provisions that match the framework's approach — immediate data portability, medium-term application migration, and long-term planning for deeply integrated systems.

The Limitations

The framework's limitations are inherent in its authorship. Microsoft has a commercial interest in maintaining customers' cloud deployments. A framework that makes exit planning appear manageable reduces regulatory pressure for multi-cloud strategies or cloud-avoidance policies that would directly impact Microsoft's revenue. The framework's emphasis on "managing" concentration risk rather than "reducing" it is a provider-favorable framing.

Specific limitations include: the framework underemphasizes the organizational switching costs that make exit from a cloud platform difficult even when technical migration is feasible; the tiered exit strategy approach normalizes multi-year exit timelines that may be too long for genuine crisis scenarios; and the framework does not adequately address the scenario where the provider itself fails or is sanctioned — a scenario where exit planning must be executed under duress rather than as a planned transition.

Independent Assessment Is Non-Negotiable

For DORA compliance, provider-authored frameworks should inform but not replace independent risk assessment. Financial institutions must conduct their own concentration risk analysis, develop their own exit strategies (informed by but not limited to the provider's framework), and test their exit capabilities independently.

Supervisory authorities should recognize provider-authored frameworks as evidence of provider engagement with the regulatory process, but should not treat them as sufficient evidence of the financial institution's compliance with Art. 28-30. The institution's obligation is to manage its own risk — not to accept the provider's risk assessment.

Implications for CTPP Oversight

As DORA Art. 31 CTPP designation processes advance, provider-authored concentration risk frameworks may become a standard element of the oversight relationship. Designated CTPPs could be required to publish and maintain such frameworks as part of their transparency obligations. The quality and completeness of these frameworks could become an input to the Lead Overseer's assessment of the provider's governance and risk management.

For the cloud industry, Microsoft's early publication of a concentration risk framework sets a competitive standard. AWS and Google Cloud will face pressure to publish equivalent frameworks — or explain why they have not. The normalization of provider transparency about concentration risk serves the financial sector's interests, even if the frameworks themselves require independent validation.