DORA Concentration Risk: How to Build an Exit Strategy Your Regulator Will Accept

The Digital Operational Resilience Act (Regulation 2022/2554), which applies from 17 January 2025, introduces a concept that no previous EU regulation stated so explicitly: financial entities must identify, assess, and manage the risk of depending too heavily on a single ICT provider. And they must have documented exit plans for their critical providers.

This is not optional. DORA applies to credit institutions, investment firms, insurance undertakings, payment institutions, crypto-asset service providers, and virtually every other regulated financial entity in the EU. The European Supervisory Authorities (EBA, ESMA, EIOPA) are developing Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) to specify the details.

This post walks through the specific DORA requirements for concentration risk and exit strategies, then provides a practical framework for building exit plans that satisfy regulatory expectations.

What DORA Says About Concentration Risk

Article 29: ICT Concentration Risk at Entity Level

Article 29(1) requires financial entities, as part of their ICT third-party risk management, to:

“take into account whether the envisaged conclusion of a contractual arrangement in relation to ICT services supporting critical or important functions would lead to: (a) contracting with an ICT third-party service provider that is not easily substitutable; or (b) having in place multiple contractual arrangements in relation to the provision of ICT services supporting critical or important functions with the same ICT third-party service provider or with closely connected ICT third-party service providers.”

In practical terms: before entering into or renewing a contract with a cloud provider, you must assess whether doing so creates or deepens a concentration risk. If Microsoft already provides your identity, email, files, and communication, adding Azure cloud hosting to the same relationship increases concentration risk. DORA requires you to consider that before signing.

Article 29(2) goes further, requiring competent authorities to take concentration risk into account when supervising financial entities. This means your regulator will be looking at your provider portfolio and asking whether you have considered what happens if your primary provider fails.

Article 28: Exit Strategies

Article 28(8) requires financial entities to put in place “exit strategies” for ICT services supporting critical or important functions. Specifically:

“Financial entities shall put in place exit strategies for ICT services supporting critical or important functions, taking into account risks that may emerge at the level of ICT third-party service providers, in particular a possible failure of the ICT third-party service provider, a deterioration of the quality of the ICT services, any business disruption due to inappropriate or failed provision of ICT services or any material risk arising in relation to the appropriate and continuous deployment of the respective ICT service, or the termination of contractual arrangements with ICT third-party service providers under any of the circumstances listed in paragraph 7.”

The exit strategy must include:

• Alternative solutions (identified and assessed)
• Transition plans (documented and feasible)
• Provisions ensuring continuity during the transition
• Regular testing of the exit plans

The Register of Information (Article 28(3))

DORA also requires financial entities to maintain a “register of information” on all contractual arrangements with ICT third-party service providers. This register must distinguish between services supporting critical or important functions and other services. The European Supervisory Authorities published draft ITS on the register of information in 2024 (JC 2023 85), specifying the exact data fields required.

Why Most Financial Entities Are Not Ready

Based on what we see in the market:

The register exists, but it is incomplete. Most financial entities have procurement databases that list their vendors. Few have a comprehensive register that maps each vendor to the business functions it supports, the data it processes, and the concentration risk it creates.

Concentration risk is acknowledged but not assessed. Many risk assessments include a line that says “concentration risk: Microsoft 365 and Azure.” Few include a structured analysis of what happens if Microsoft becomes unavailable, how long the entity can operate without it, and what the alternative would be.

Exit strategies are aspirational. “We would migrate to an alternative provider” is not an exit strategy. An exit strategy specifies which alternative provider, how long the migration would take, what data and configurations need to be transferred, what the cost would be, and how business continuity would be maintained during the transition.

Testing is absent. DORA requires regular testing of exit plans. Almost no financial entity tests its cloud provider exit strategy. The closest most come is a disaster recovery test focused on data backup, which is necessary but not sufficient.

Building an Exit Strategy: Step by Step

Step 1: Identify Critical ICT Services

List every ICT service that supports a critical or important function. For a typical financial entity, this includes:

• Identity and access management (Azure AD / Entra ID, Okta)
• Email and calendar (Exchange Online, Gmail)
• File storage and document management (SharePoint, OneDrive, Google Drive)
• Core banking/trading/insurance platform
• CRM (Salesforce, Dynamics 365)
• Communication (Teams, Slack, Zoom)
• Cloud infrastructure (Azure, AWS, GCP)
• Payment processing infrastructure
• Regulatory reporting tools
• Data analytics and BI platforms

Step 2: Assess Concentration

For each critical service, document:

• Provider identity. Who provides it? (Including sub-processors)
• Substitutability. Can this provider be replaced? How quickly? At what cost?
• Cross-service concentration. Does the same provider supply multiple critical services? If Microsoft provides identity, email, files, communication, and cloud hosting, you have extreme concentration.
• Market concentration. Are other financial entities in your sector concentrated on the same provider? (This is relevant because a provider failure or sanctions event would affect the entire sector simultaneously.)

Step 3: Define the Exit Trigger Scenarios

An exit strategy must specify what events would trigger its activation. DORA Article 28(7) lists several:

• Material breach of applicable law or contractual terms by the provider
• Circumstances that alter the performance of the functions provided
• Weaknesses identified in the provider’s ICT risk management
• The competent authority can no longer effectively supervise the financial entity because of the arrangement

Additional scenarios to consider:

• US sanctions affecting the provider’s ability to serve EU customers
• Provider acquisition by a sanctioned entity
• Provider insolvency or business discontinuity
• Provider unilateral terms of service changes that affect data processing
• Regulatory finding that the provider constitutes a critical ICT third-party service provider under DORA’s oversight framework (Article 31), with implications for the arrangement

Step 4: Identify Alternative Providers

For each critical service, identify at least one alternative provider that could replace it. Assess:

For Microsoft 365, realistic alternatives for a financial entity:

Step 5: Document the Transition Plan

For each critical service, the transition plan should specify:

Pre-transition preparation:

• Alternative provider selected and contract negotiated (not necessarily signed, but ready)
• Data export procedures documented and tested
• Integration mapping complete (which systems connect to the current provider?)
• Staff training plan for the alternative platform
• Communication plan for clients and partners

Transition execution:

• Sequence of migration steps (e.g., DNS first, then email, then identity, then files)
• Timeline for each step (realistic, not aspirational)
• Rollback procedures for each step
• Business continuity measures during transition (e.g., running both systems in parallel)
• Data validation procedures (confirming data integrity after migration)

Post-transition validation:

• Verification that all critical functions are operational on the alternative platform
• Decommissioning of the old service
• Data deletion confirmation from the previous provider (per Article 28(8)(b))
• Updated register of information

Step 6: Estimate Costs and Timelines

Regulators will not accept an exit strategy that says “we will figure out the cost and timeline when we need to.” Provide estimates:

These are planning estimates. Actual costs depend on the complexity of your specific deployment, the number of integrations, and the quality of your data export.

Step 7: Test the Plan

DORA requires testing. At minimum:

• Annual data export test. Export data from each critical provider and verify that it can be imported into the alternative. Document the results.
• Tabletop exercise. Walk through the exit scenario with your IT team and leadership. Identify gaps and update the plan.
• Partial migration test. Migrate a non-critical service or a subset of users to the alternative platform. Identify practical issues that the paper plan did not anticipate.

Document every test, including what worked, what failed, and what was updated in the exit strategy as a result.

Step 8: Maintain and Review

The exit strategy is a living document. Review it:

• After any significant change to your ICT provider portfolio (new contract, renewal, provider acquisition)
• After any regulatory change affecting ICT third-party risk
• After any test exercise
• At least annually

Assign a named owner for each exit strategy. The owner is responsible for keeping the strategy current and for triggering reviews when circumstances change.

What Your Regulator Expects

When your competent authority reviews your DORA compliance, they will look for:

1. A complete register of information covering all ICT third-party arrangements, with critical/important functions clearly identified.
2. A documented concentration risk assessment that goes beyond “we use Microsoft for everything” to quantify the impact and identify alternatives.
3. Exit strategies for critical providers that include alternative providers, transition plans, cost estimates, and timelines.
4. Evidence of testing. Not just a statement that you test, but documented results of actual tests.
5. Named accountability. A risk owner for each critical provider relationship.

The bar is not perfection. The bar is demonstrable, documented effort to understand and manage concentration risk. The entities that will face scrutiny are the ones that have done nothing.

Starting Point

If you have no exit strategy today, start with your most concentrated provider. For most financial entities, that is Microsoft or Google. Complete the full assessment for that one provider. The exercise will teach you more about your own dependencies than any compliance framework can.

The cost of building the exit strategy is a fraction of the cost of executing it under pressure. And DORA makes the strategy itself a regulatory requirement, not a nice-to-have.

Sovereign Shift delivers the concentration risk assessment, alternative provider shortlist, and exit strategy documentation that DORA requires. See pricing and scope →