Building a DORA Exit Strategy for Azure: What Article 28(8) Requires
What a DORA exit strategy for Azure must contain under Article 28(8): portability assessment, exit triggers, timeline, cost, and a risk-accepted conclusion. For cloud architects.
Marc Dekeyser |
Building a DORA Exit Strategy for Azure: What Article 28(8) Requires
Most exit strategies for Azure are written to be filed, not executed. That is the wrong instinct, and a supervisor can smell it.
Here is the honest position for most financial institutions: exit from Azure for a critical function is technically feasible and operationally prohibitive. A documented, costed, board-accepted version of that conclusion is compliant. Article 28(8) requires the plan for any arrangement supporting critical or important functions. It does not require you to believe you will ever run it.
So treat the exit strategy as what it actually is. A risk assessment that happens to produce a plan. The value lives in the assessment. Not in the fantasy that you will execute it one Tuesday afternoon.
Key takeaways
- DORA Article 28(8) requires exit strategies for ICT arrangements supporting critical or important functions; Article 30(3) makes the exit plan a mandatory contract element.
- The plan rests on a portability assessment of three layers: data egress, infrastructure-as-code portability, and platform-as-a-service lock-in.
- The hardest lock-in points are managed services: Azure SQL Database, Azure Cosmos DB, Azure Service Bus, and Microsoft Entra ID.
- Exit triggers must be defined in advance: provider failure, contract breach, supervisory direction, unacceptable concentration.
- “Exit is feasible but operationally prohibitive, risk accepted at board level” is a valid DORA position when it is documented, costed, and signed.
What Article 28(8) actually asks for
Article 28(8) wants a documented exit strategy for any ICT third-party arrangement supporting a critical or important function. The point of it: you can leave without disrupting business activities, breaching a regulatory requirement, or degrading service continuity. Article 30(3)(f) then lists the exit strategy among the mandatory contractual provisions, so it lands in the contract too.
The requirement has a specific shape. You must be able to leave the arrangement and either bring the function in-house or move it to another provider. Without breaking business continuity or your regulatory obligations. It has to account for a transition period where the incumbent and the successor both run at once. And it has to read as credible. Credible enough that a supervisor believes you could execute it under pressure, not just that you drafted it.
For Azure, that means working out what it would take to move a workload off Microsoft Azure. The assessment is the work. The plan is what falls out of it.
This is the other side of the third-party register and concentration analysis in DORA Article 28 and Microsoft as a critical third party. The register documents the concentration risk. The exit strategy is your answer to it.
Portability, in three layers
Split the assessment into three layers: data egress, infrastructure-as-code portability, and platform-as-a-service lock-in. They carry different difficulty and different cost. Keep them separate, because they fail separately.
Start with data egress. Can you get your data out, in a usable format, inside the transition window? Azure no longer charges egress on data leaving via the standard cross-region paths the way it once did across the board, and EU Data Act provisions are eroding egress fees further. Volume and format are what actually bite. Petabytes of blob storage move on a timescale measured in weeks, not hours. For the genuinely large sets there is Azure Data Box, which ships the data physically. Record the volume, the format, the mechanism, and a duration you would defend in a room.
Then infrastructure-as-code. If your environment lives in Azure Resource Manager (ARM) templates or Bicep, it is Azure-specific by construction. No argument there. Terraform with the AzureRM provider looks more portable, but that is syntax, not semantics. An azurerm_kubernetes_cluster does not turn into an AWS EKS cluster because you swapped the provider block. So the real question is how much of your IaC describes generic infrastructure versus Azure-native services. The honest answer, most of the time: the compute is portable, the managed services are not.
That brings you to platform-as-a-service. The hard layer. Managed services trade portability for operational simplicity, and you do not get both.
| Azure service | Lock-in driver | Portability difficulty |
|---|---|---|
| Azure SQL Database | T-SQL plus Azure-specific features (elastic pools, serverless tiers) | Moderate — migrates to SQL Server, harder to non-Microsoft engines |
| Azure Cosmos DB | Proprietary multi-model API, request-unit model | High — no drop-in equivalent |
| Azure Service Bus | Proprietary messaging semantics, sessions, dead-lettering | High — requires re-architecture to alternative broker |
| Microsoft Entra ID | Identity provider for entire estate, federation, conditional access | Very high — touches every application |
| Azure Kubernetes Service | Kubernetes itself is portable; AKS-specific add-ons are not | Low–moderate |
Out of this falls a per-service difficulty rating. That rating is the spine of everything downstream: the cost, the timeline, all of it.
Triggers and timeline
A plan with no trigger is a plan nobody executes. So define the triggers first: the specific, pre-agreed conditions that make the entity invoke the exit. Then build the timeline by summing the per-layer transition durations from the portability work. Both have to exist before anyone should call the plan credible.
For an Azure arrangement, the triggers usually cover sustained failure to meet contractual service levels, a material breach of the Data Processing Addendum, a supervisory direction from De Nederlandsche Bank (DNB) or the European Supervisory Authorities, a Union-level designation event under DORA Articles 31–44, an unacceptable shift in concentration risk, or a commercial event (a price change that breaks the business case counts). Name who decides on each, and on what evidence. A trigger nobody owns is decoration.
Now add up the layers. Data egress runs to weeks. IaC rebuild on the target platform runs to months for anything non-trivial. PaaS re-architecture (replacing Azure Cosmos DB, re-platforming off Microsoft Entra ID) runs to quarters. Put it together and a realistic full-exit timeline for a critical function on Azure is rarely under twelve months and frequently over twenty-four. The cost estimate mirrors the same structure: egress cost, rebuild engineering cost, parallel-run cost during the transition, and the opportunity cost of the engineering capacity you burn getting there.
Why “operationally prohibitive” is a valid answer
DORA is a risk-management regulation. It does not tell you to avoid concentration. It tells you to understand it and govern it. So a risk that is assessed, quantified, and accepted at board level satisfies the framework. Article 28(8) asks for a documented and viable exit strategy, not a commitment to exit.
Do the portability assessment honestly and most institutions land in the same place. Leaving Azure for a critical function would take eighteen to thirty months, cost millions, and eat the engineering capacity that would otherwise build the business. None of that is a compliance failure. It becomes one only when it is undocumented. When nobody assessed it, costed it, or signed for it.
The compliant version has four parts:
- The portability assessment, showing you know exactly where the lock-in lives.
- The timeline and cost, showing you have quantified the exit.
- The triggers, showing you know when you would act despite the cost.
- The board sign-off, showing the residual risk was accepted by people with the authority to accept it.
Read that, and a supervisor does not see an institution pretending it will leave Microsoft. They see one that knows precisely what staying costs and has chosen, eyes open, to stay.
Same evidentiary posture runs through DORA backup and recovery (see DORA Article 12 on Azure), where documented capability beats theoretical perfection.
Where PAA fits
Platform Architecture Authority reads your Azure environment and builds the dependency map the portability assessment needs: which workloads depend on Azure SQL Database, Azure Cosmos DB, Azure Service Bus, and Microsoft Entra ID, and how those dependencies wire together. That map is the raw material for the per-service lock-in rating and the timeline, generated from what is actually deployed, not from an architecture diagram that went stale two reorgs ago. PAA is read-only. It does not execute migrations. The judgment about what to re-platform and what to accept stays with your architects, where it belongs.
Crimson Owl Technologies built PAA off roughly a thousand architecture reviews. The exit-strategy section was reliably the one institutions had documented least and understood least.
Frequently asked questions
Does DORA require us to actually be able to leave Azure? It requires a viable, documented exit strategy, not a demonstrated migration. The strategy has to be credible (assessed, costed, governed), but Article 28(8) accepts that exit from a hyperscaler is a major undertaking. A risk-accepted decision to remain, backed by a real assessment, is compliant. An absent or fictional plan is not.
How detailed must the portability assessment be? Detailed enough to support a credible timeline and cost. So: a per-service lock-in rating for the managed services your critical function depends on, the data volume and egress mechanism, and an honest split of which components are portable and which need re-architecture. “We could move if needed” satisfies nobody.
Who has to approve the exit strategy? The management body. Article 28(1) puts ICT third-party risk under board-level responsibility, and accepting residual concentration risk because exit is prohibitive is a call for the body with authority to make it. Sign-off from an architecture team alone does not cover a critical-function arrangement.
Should the exit strategy assume multi-cloud as the destination? Not necessarily. The destination can be another provider, an in-house build, or a different region. Multi-cloud carries its own concentration and complexity costs, and naming it as the target without assessing those costs weakens the plan. Name a realistic destination and assess the move to that one specifically.
The exit strategy is not where you promise to leave. It is where you prove you understand what staying costs — and decide accordingly.
