Contents
Exit plans
Purpose of the Requirement
Exit plans ensure that financial entities can terminate ICT service arrangements supporting critical or important functions without causing business disruption, regulatory non-compliance, or detriment to clients.
They represent a key resilience safeguard in circumstances where ICT third-party service providers fail, degrade services, face operational disruption, or where contractual arrangements end under adverse or unexpected conditions. Exit plans guarantee continuity, integrity, and controlled transition of ICT services and data to alternative providers or back-in-house environments.
Scope of Application
Exit plans must exist for every contractual arrangement covering ICT services supporting critical or important functions.
They apply to:
- intragroup and external ICT third-party service providers
- cloud and non-cloud environments
- data processing, communication, operational technology, platforms, and infrastructure
- hybrid and multi-provider constellations
- subcontracting chains (direct and indirect)
Exit strategies and plans must be maintained both at entity level and, where applicable, at consolidated or sub-consolidated group level (Article 28(2) DORA and Article 2 RTS TPPol).
Mandatory Components of Exit Plans
Exit plans must be comprehensive, documented, actionable, scenario-based, and periodically tested. At a minimum, they must contain the following elements:
Exit Strategy and Trigger Conditions
The exit strategy must define:
- the rationale for exit (e.g., provider failure, service degradation, legal risks, contract termination)
- the risk scenarios that would trigger exit activation
- differentiation between planned exits and emergency exits
- dependencies on ICT assets, data, functions, and providers
Exit triggers must explicitly include all scenarios identified in Article 28(8) DORA and Article 10(a)–(c) RTS TPPol:
- unforeseen or persistent service interruptions
- inappropriate or failed service delivery
- material deficiencies affecting continuity
- unexpected termination of contractual arrangements
- political, legal, operational, or financial risks at the provider
Transition Plans
Exit plans must include a transition plan describing how the financial entity will:
- remove all contracted ICT services
- remove, extract, or export data from provider environments
- securely and integrally transfer data and services to:
- another ICT third-party service provider, or
- an in-house solution (re-internalisation)
Transition plans must specify:
- timelines
- roles and responsibilities
- data and system migration steps
- security and integrity measures
- criteria to ensure continuity and equivalence of services
- validation and verification procedures after transition
Identification of Alternative Solutions
Financial entities must identify realistic and feasible alternative solutions, which may include:
- secondary or backup providers
- pre-qualified replacement providers
- multicloud or multi-vendor continuity strategies
- capabilities to re-establish services on in-house or hybrid infrastructure
These alternative solutions must be sufficiently detailed to be operational without delay.
Contingency Measures
Exit plans must include contingency measures ensuring:
- business continuity despite provider failure
- access to critical data
- interim workarounds or degraded-mode operations
- bridging arrangements until full transition is completed
Contingency measures must be consistent with the ICT business continuity policy (Article 11 DORA) and ICT response and recovery plans (Article 12 DORA).
Scenario Design and Risk Assumptions
Exit plans must rely on plausible, severe-but-realistic scenarios, including:
- large-scale provider outages
- financial insolvency or market exit of provider
- geopolitical or sanctions-related disruptions
- cyber-attacks or security incidents at provider
- deterioration of service quality
- failures in subcontractor chains
Plans must be realistic, feasible, and anchored in reasonable operational, legal, and technical assumptions.
Implementation Schedule
Exit plans must include:
- a detailed implementation timeline
- dependency mapping
- sequencing logic
- critical path identification
- milestones for progress monitoring
- integration with contractual exit terms
The implementation schedule must align with termination notice periods and transition obligations in the contractual arrangement.
Testing and Review Requirements
Exit plans must be:
- tested periodically, in accordance with Article 4(2) RTS TPPol
- tested under scenarios of service interruption, degradation, or termination
- aligned with business continuity and ICT response & recovery testing frameworks
- updated based on test results, audit findings, and supervisory feedback
Testing must assess:
- feasibility of data extraction
- success of migration steps
- operational readiness of alternative solutions
- internal staff competence and resource adequacy
- dependencies across ICT assets and processes
Documented test results must be used to strengthen the exit plans and adjust assumptions where necessary.
Interdependencies with Other DORA Requirements
Exit plans are tightly linked to:
- ICT business continuity policy (Article 11 DORA; Articles 24–26 RTS RMF)
- ICT response and recovery plans (Article 11(3) DORA; Article 26 RTS RMF)
- ICT risk management framework (Article 6 DORA)
- contractual requirements under Article 30 DORA (audit rights, access rights, cooperation, data return/deletion)
- ICT third-party risk strategy and policy (Article 28(2) DORA; Articles 1–9 RTS TPPol)
- residual risk acceptance processes
- multi-vendor strategies (Article 6(9) DORA)
Exit plans must be consistent with all these frameworks and must be embedded into the overall governance architecture.
Documentation Requirements
Exit plans must be comprehensively documented, including:
- detailed plan documents per contractual arrangement
- trigger conditions and decision matrices
- mapping of critical dependencies
- alternative provider or in-house options
- scenario analyses and assumptions
- technical and operational migration guides
- test results and remediation actions
- governance and approval records
- record of periodic reviews and updates
Documentation must be searchable and auditable and must demonstrate that exit plans are feasible, tested, and aligned with regulatory requirements.
Governance and Oversight
The management body must:
- approve exit strategies and exit plans
- review them periodically
- ensure alignment with overall ICT third-party risk strategy (Article 28(2) DORA)
- ensure adequate resources for exit readiness
- oversee the results of exit plan testing
- ensure the capability to execute exit plans in practice
- ensure that exit plans do not impair regulatory compliance or service quality
Exit plans must also be included in the audit plan (Article 3(7) RTS TPPol).