Exit Strategies Under DORA: The Art. 28(8) Requirement Nobody Is Ready For

The Requirement That Supervisors Will Test First

Among DORA's extensive requirements for ICT third-party risk management, Article 28(8) stands out for a specific reason: it requires action before the crisis, not during it. Exit strategies must be documented, maintained, and periodically tested for every ICT third-party arrangement that supports a critical or important function. They must be in place before vendor activation — not after a provider relationship deteriorates.

This is the requirement that separates paper compliance from operational resilience.

In supervisory conversations across the EU since January 2025, NCAs have consistently flagged exit strategies as the most common gap in third-party risk management programs. The pattern is familiar: institutions maintain detailed vendor registers (Art. 28(3)), conduct due diligence on new providers (Art. 28(4)), and negotiate key contractual provisions (Art. 30). But when asked to produce the exit strategy for their core banking platform's cloud hosting arrangement, or their payment processing partner, or their anti-fraud SaaS provider, the answer is frequently a one-page document that states "migrate to alternative provider within 12 months."

That is not an exit strategy. It is an aspiration.

What Article 28(8) Actually Requires

Article 28(8) states that financial entities shall ensure they are able to "exit contractual arrangements without disruption to their business activities, without limiting compliance with regulatory requirements, and without detriment to the continuity and quality of services provided to clients."

The three "without" conditions define the standard:

Without disruption to business activities. The exit must not cause service outages, processing delays, or operational degradation that would constitute an ICT incident under Art. 17. This means the transition must be planned, staged, and validated before cutover.

Without limiting compliance. During and after transition, the institution must continue to meet all regulatory requirements — including DORA itself. Data retention obligations, audit trail continuity, incident reporting capability, and third-party register maintenance must be preserved throughout.

Without detriment to clients. Customer-facing services must maintain continuity and quality. This is the hardest condition to meet for customer-critical services where any migration involves inherent risk of degradation.

Art. 28(8) further requires that exit strategies "take 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 provided, 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."

Translation: the exit strategy must work not only for planned exits (contract expiry, strategic decision to change providers) but also for unplanned exits (provider failure, quality deterioration, regulatory action, provider insolvency).

Why Most Exit Strategies Fail the Credibility Test

The Five Failure Modes

The Cloud-Native Trap

Figure 2: The cloud-native exit trap. Applications built on proprietary services have three exit paths — all requiring advance planning that Art. 28(8) demands.

The deepest exit strategy challenge faces institutions that have adopted cloud-native architectures. A payment processing application built on AWS Lambda (serverless compute), DynamoDB (proprietary NoSQL database), SQS (message queue), and CloudWatch (monitoring) is not portable. Each AWS-native service has a different API, data model, and operational behavior than its equivalent on Azure or Google Cloud.

Exiting this arrangement means one of three things:

1. Re-engineering the application to use cloud-agnostic alternatives (Kubernetes, PostgreSQL, RabbitMQ) — a project measured in months and millions
2. Building a parallel application on the target platform — effectively a new build
3. Accepting prolonged dual-running with traffic gradually migrated — expensive and operationally complex

None of these can be executed in a crisis. They require advance planning, investment, and testing — which is precisely what Art. 28(8) demands.

The 6-Phase Exit Strategy Framework

Figure 1: The 6-phase exit strategy lifecycle. Phases 1-4 build the capability; Phase 5 keeps it current; Phase 6 is triggered for planned exits (contract expiry) or unplanned exits (provider failure).

A credible exit strategy is a living operational plan, not a compliance document. The following framework structures the development and maintenance of exit strategies that meet Art. 28(8)'s three "without" conditions.

Phase 1: Assessment (Weeks 1-4)

Objective: Understand what you are exiting from and why it is difficult.

• Map every service, integration, and dependency associated with the provider arrangement
• Identify proprietary technologies, data formats, and platform-specific configurations
• Quantify data volumes, transaction rates, and performance requirements
• Assess contractual provisions: does the contract include transition assistance, data export rights, and cooperation obligations (Art. 30(2)(f))?
• Classify exit complexity:

Phase 2: Planning (Weeks 4-8)

Objective: Design the transition path.

• Identify and pre-qualify alternative providers (at minimum, confirm that the application can technically run on the alternative platform)
• Design the data migration approach: full migration, incremental sync, or parallel processing
• Plan the application migration: lift-and-shift, re-platform, or re-engineer
• Define the transition sequence: which components migrate first, which are last
• Establish rollback criteria: at what point does the migration roll back to the original provider
• Document resource requirements: teams, tools, external support, budget

Phase 3: Preparation (Weeks 8-16)

Objective: Build the capabilities needed to execute the plan.

• Negotiate transition assistance provisions into the contract (if not already present)
• Build or configure the target environment on the alternative platform
• Develop data migration tooling and validate with test datasets
• Establish monitoring and validation criteria for each migration phase
• Train teams on the alternative platform
• Secure budget approval for the transition (even if not yet triggered)

Phase 4: Validation (Weeks 16-20)

Objective: Prove that the plan works.

• Execute a tabletop exercise walking through the full transition sequence
• Perform a technical proof-of-concept: migrate a non-production instance to the alternative platform
• Validate data integrity after migration (checksums, record counts, functional verification)
• Measure performance on the alternative platform against current baselines
• Test rollback procedures
• Document gaps identified and update the plan

Phase 5: Maintenance (Ongoing)

Objective: Keep the exit strategy current.

• Review and update annually, or when the provider arrangement changes materially
• Re-validate after major platform upgrades, architectural changes, or data volume growth
• Track alternative provider market (new entrants, capability changes, pricing shifts)
• Maintain team familiarity with the alternative platform through periodic training
• Report exit strategy status to management body as part of third-party risk reporting

Phase 6: Execution (Triggered)

Objective: Execute the transition when triggered — whether planned or unplanned.

For planned exits (contract expiry, strategic change): execute the validated plan with full provider cooperation, staged migration, and controlled cutover.

For unplanned exits (provider failure, quality crisis): execute the contingency variant of the plan — typically an accelerated timeline with reduced validation, accepting higher risk in exchange for faster recovery. The unplanned exit plan should have a separate, abbreviated timeline with decision points for each phase.

Exit Complexity by Service Type

Not all ICT services are equally difficult to exit. The following assessment helps institutions prioritize exit strategy investment.

The Contractual Foundation: Art. 30(2)(f)

Exit strategies are only as strong as the contractual provisions that support them. Article 30(2)(f) requires that contracts with ICT third-party service providers supporting critical or important functions include provisions on "transition periods and adequate transition planning mechanisms" including "the obligation for the ICT third-party service provider to cooperate and to provide assistance to ensure an orderly migration."

Key contractual provisions for exit strategy credibility:

• Data export rights: Right to export all data in standard, documented formats at any time during and after the contract term
• Transition assistance: Provider obligation to provide technical assistance during migration for a defined period (typically 6-12 months after termination notice)
• Data retention post-exit: Provider obligation to retain institution data for a defined period after contract termination (to allow validation of migration completeness)
• API access during transition: Continued API access at agreed service levels during the transition period
• No penalty for exit: Exit triggers related to provider failure or quality deterioration must not incur early termination penalties
• Knowledge transfer: Provider obligation to share configuration details, integration specifications, and operational runbooks needed for migration

Institutions that negotiate these provisions at contract inception — when bargaining power is highest — have credible exit strategies. Institutions that attempt to negotiate them when an exit is already underway have limited leverage.

The Board Dimension

Art. 5 places ultimate responsibility for ICT risk management with the management body. Art. 28(8) is not an IT operations requirement — it is a governance requirement. The board should:

• Understand the institution's most critical third-party dependencies and the credibility of associated exit strategies
• Approve exit strategy investment (preparation, testing, alternative provider qualification)
• Receive periodic reporting on exit strategy readiness, including identified gaps and remediation timelines
• Challenge exit strategies that rely on untested assumptions or unrealistic timelines

The question for the board is not "do we have exit strategies?" It is "if our most critical provider failed tomorrow, could we continue serving our customers within our stated impact tolerance?" If the honest answer is no, the exit strategy needs more investment, more testing, and more scrutiny.

The institutions that will navigate the next major cloud outage, provider insolvency, or regulatory intervention with their customer relationships and regulatory standing intact are those that built credible exit strategies before they needed them. Article 28(8) is the regulatory codification of that common sense. For institutions assessing their cloud concentration risk, exit strategy credibility is the critical complement to HHI measurement.

---

This analysis reflects DORA Regulation (EU) 2022/2554 Articles 28 and 30 and associated RTS as applicable. The EBA has published additional guidance on third-party risk management expectations. Exit strategy frameworks are illustrative; institutions should adapt timelines and approaches to their specific arrangements.

---