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
A DORA exit strategy for Azure is a documented, tested plan to move a critical function off Microsoft Azure within a defined timeline, including the portability assessment, the exit triggers, and the cost. Article 28(8) requires it for arrangements supporting critical or important functions. For most institutions, the honest conclusion is that exit is technically feasible and operationally prohibitive — and a documented, risk-accepted version of that conclusion is compliant.
The mistake is treating the exit strategy as a fiction to satisfy an auditor. It is not. It is a risk assessment that happens to produce a plan. The value is in the assessment, not the fantasy that you will execute it.
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 does DORA Article 28(8) require for an exit strategy?
DORA Article 28(8) requires financial entities to have documented exit strategies for ICT third-party arrangements that support critical or important functions, ensuring they can exit without disruption to business activities, breach of regulatory requirements, or detriment to service continuity. Article 30(3)(f) reinforces this by listing exit strategies among the mandatory contractual provisions.
The requirement has a specific shape. The exit strategy must allow the entity to leave the arrangement and either bring the function in-house or move it to an alternative provider. It must do so without disrupting business activities or breaching regulatory obligations. It must account for a transition period during which both the incumbent and the successor operate. And it must be more than a statement of intent — it has to be credible enough that a supervisor reading it believes you could execute it under pressure.
For Azure, that means assessing what it would actually take to move a workload off Microsoft Azure (first mention; “Azure” thereafter). The assessment is the work. The plan is the output.
This connects directly to the third-party register and concentration analysis covered in DORA Article 28 and Microsoft as a critical third party. The exit strategy is the response to the concentration risk that register documents.
How do you assess portability of an Azure workload?
You assess portability of an Azure workload across three layers: data egress, infrastructure-as-code portability, and platform-as-a-service lock-in. Each layer carries a different difficulty and cost, and the assessment treats them separately because they fail separately.
Data egress. Can you get your data out, in a usable format, within the transition window? Azure does not charge egress on data leaving via the standard cross-region paths in the way it once universally did — and EU Data Act provisions are eroding egress fees — but volume and format remain the constraint. Petabytes of blob storage move on a timescale measured in weeks. Azure Data Box exists for physical transfer. The egress assessment records data volume, format, and the mechanism, with a realistic duration.
Infrastructure-as-code portability. If your environment is defined in Azure Resource Manager (ARM) templates or Bicep, it is Azure-specific by construction. Terraform with the AzureRM provider is portable in syntax but not in resource semantics — an azurerm_kubernetes_cluster does not become an AWS EKS cluster by changing the provider block. Portability here means how much of your IaC describes generic infrastructure versus Azure-native services. The honest answer is usually “the compute is portable, the managed services are not.”
Platform-as-a-service lock-in. This is the hard layer. Managed services trade portability for operational simplicity, and you cannot have 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 |
The portability assessment produces a per-service difficulty rating. That rating is the spine of the cost and timeline estimate.
How do you define exit triggers and estimate the timeline?
You define exit triggers as the specific, pre-agreed conditions that would cause the entity to invoke the exit strategy, and you estimate the timeline by summing the per-layer transition durations from the portability assessment. Both must exist before the plan is credible. A plan with no trigger is a plan nobody will ever execute.
Exit triggers for an Azure arrangement typically include: 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 such as a price change that breaks the business case. Each trigger names who decides and on what evidence.
The timeline estimate aggregates the layers. Data egress: weeks. IaC rebuild on the target platform: months for anything non-trivial. PaaS re-architecture — replacing Azure Cosmos DB, re-platforming off Microsoft Entra ID — quarters. A realistic full-exit timeline for a critical function on Azure is rarely under twelve months and frequently over twenty-four. The cost estimate follows the same structure: egress cost, rebuild engineering cost, parallel-run cost during transition, and the opportunity cost of the engineering capacity consumed.
Why is “exit is operationally prohibitive” a valid DORA conclusion?
“Exit is operationally prohibitive” is a valid DORA conclusion because Article 28(8) requires a documented and viable exit strategy, not a commitment to exit, and a risk that is assessed, quantified, and accepted at board level satisfies the framework. DORA is a risk-management regulation. It does not mandate that you avoid concentration; it mandates that you understand and govern it.
Most institutions, having done the portability assessment honestly, reach the same conclusion: leaving Azure for a critical function would take eighteen to thirty months, cost millions, and consume the engineering capacity that would otherwise deliver the business. That conclusion is not a compliance failure. It becomes a failure only when it is undocumented — when nobody assessed it, costed it, or accepted 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. And the board sign-off, showing the residual risk was accepted by people with authority to accept it. A supervisor reading that does not see an institution pretending it will leave Microsoft. They see one that knows precisely what staying costs and has decided, with open eyes, to stay.
This is the same evidentiary posture that runs through DORA backup and recovery — see DORA Article 12 on Azure — where documented capability matters more than theoretical perfection.
How PAA supports exit-strategy documentation
Platform Architecture Authority reads your Azure environment and produces 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 connect. That map is the raw material for the per-service lock-in rating and the timeline estimate, generated from your actual deployment rather than an architecture diagram that may be out of date. PAA is read-only and does not execute migrations; the engineering judgment about what to re-platform and what to accept stays with your architects. Crimson Owl Technologies built PAA from roughly a thousand architecture reviews, and the exit-strategy section was usually the one institutions had documented least and understood least.
Frequently asked questions
Does DORA require us to actually be able to leave Azure? DORA requires a viable, documented exit strategy, not a demonstrated migration. The strategy must be credible — assessed, costed, and 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. That means a per-service lock-in rating for the managed services your critical function depends on, the data volume and egress mechanism, and an honest statement of which components are portable and which require re-architecture. Vague assertions that “we could move if needed” do not satisfy a supervisor.
Who has to approve the exit strategy? The management body. DORA Article 28(1) places ICT third-party risk under board-level responsibility, and a decision to accept residual concentration risk because exit is prohibitive must be made by the body with authority to accept it. Approval by an architecture team alone is insufficient for 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 introduces its own concentration and complexity costs, so naming it as the exit target without assessing those costs weakens the plan. The strategy should name a realistic destination and assess the move to it specifically.
The exit strategy is not the document where you promise to leave. It is the document where you prove you understand what staying costs, and decide accordingly.
