Most firms that have confirmed DORA applies to their EU-regulated entities have also, by now, acknowledged that their ICT third-party documentation does not fully meet the Article 28 standard. The acknowledgement is in the compliance register. The remediation is not yet complete.

The gap is not a failure of intent. It is a failure of specification. Compliance teams that assessed DORA exposure in 2023 and 2024 identified Article 28 as an obligation requiring exit strategies for ICT services supporting critical or important functions. What many did not produce at that stage was a clear, document-level description of what a DORA-compliant exit strategy actually contains, and how it differs from the exit planning documentation already held under PRA SS2/21 or FCA SYSC 15A.

This article provides that specification. It is written for the CTO, COO, or Head of Third Party Risk who is responsible for producing ICT supplier exit documentation that will satisfy a DORA-obligated entity's supervisory obligations. It describes precisely what a compliant DORA Article 28 exit strategy document contains, where it goes beyond the PRA and FCA standards, and what the evidence set that supports it looks like.

What Article 28 Requires: The Specific Documentation Obligations

DORA Article 28 establishes the requirements for contractual arrangements between in-scope financial entities and ICT third-party service providers. For ICT services supporting critical or important functions, the Article requires that exit strategies are developed and, where risk conditions are met, tested.

The documentation obligation has three distinct components that are frequently conflated in initial compliance assessments.

The first is the contractual provision requirement. The contract between the financial entity and its ICT provider must contain specific provisions that support exit: the right to terminate the arrangement under defined conditions including material service degradation and financial distress, obligations on the provider to cooperate with an orderly transition, data portability and return provisions specifying the format, timeline, and conditions of data return on exit, subcontracting notification rights covering where material subcontracting changes affect the service, and an adequate transition period that is defined in the contract and is sufficient to allow the financial entity to move to an alternative provider or bring the service in-house without material disruption to its critical or important functions.

The second is the exit strategy document itself. This is separate from, and more detailed than, the contractual provisions. It is an operational document held by the financial entity that sets out how an exit would actually be executed: what the exit triggers are, what the viable exit options are for this specific ICT arrangement, what the transition steps are in sequence, what resources and people are required, what the data management and portability process involves, and what the financial cost of a transition under both stressed and non-stressed conditions would be.

The third is the testing evidence. For ICT services where dependency is high, complexity is elevated, or substitutability is limited, DORA requires that the exit strategy is tested. Testing is not defined in Article 28 with the same level of prescription as testing under PRA SS1/21, but the ESA implementation guidance is clear that testing should be proportionate to the risk profile and should demonstrate the feasibility of the exit strategy under realistic conditions.

Where the DORA Standard Exceeds PRA SS2/21 and FCA SYSC 15A

The three components described above overlap substantially with exit planning obligations under PRA SS2/21 and FCA SYSC 15A. For firms managing a DORA remediation programme alongside existing PRA and FCA compliance, understanding precisely where DORA goes further is the most efficient way to identify what new work is actually required.

Contractual specificity. PRA SS2/21 requires firms to maintain exit plans and to test them for feasibility, but does not prescribe the specific contractual provisions that must be present. DORA Article 28 does. The requirement for an adequate transition period to be embedded in the contract itself, rather than simply referenced in an exit plan document, is a materially different obligation. Many UK firms have exit plans that describe a transition period but do not have contracts that guarantee the provider's cooperation and assistance during that period. That gap is a PRA and FCA compliance shortcoming, but it becomes an explicit DORA contractual obligation that requires re-papering to close.

The exit strategy as a standalone document. Under PRA SS2/21, exit planning is frequently addressed within a broader outsourcing risk management framework rather than as a standalone document per ICT service. Under DORA, the expectation, as confirmed in ESA guidance on Article 28, is that each ICT service supporting a critical or important function has a specific, documented exit strategy. Many firms that met the PRA standard for exit planning through framework-level documentation will need to produce per-service exit strategy documents to meet the DORA standard.

Substitutability as a testing trigger. PRA SS2/21 requires testing of exit plans for operational and financial feasibility, but the specific trigger of low substitutability as a condition requiring testing is more explicitly stated in DORA's framework. Firms with high-dependency, low-substitutability ICT arrangements, the clearest examples being single-source core banking platforms and highly customised insurance administration systems, need to be able to demonstrate that the exit strategy for those specific arrangements has been tested under conditions that reflect the genuine difficulty of executing an exit.

What a Compliant DORA ICT Exit Strategy Document Contains

The following sets out the required content of a DORA-compliant exit strategy document for a single ICT service supporting a critical or important function. This is the minimum evidencing standard. Missing elements create a compliance gap that a supervisory review of the EU-regulated entity would identify.

ICT service definition and criticality classification. The document must open with a clear definition of the ICT service in scope, a statement of why it supports a critical or important function for the financial entity, and the basis on which that classification was made. The classification rationale must be traceable to the firm's ICT risk management framework and must have been reviewed at a defined frequency.

Exit triggers. A documented set of conditions under which the financial entity would activate the exit strategy. Exit triggers must cover both contractual triggers (provider breach of service level, change of control, financial distress) and operational triggers (sustained service degradation below defined thresholds, critical security vulnerability, regulatory action against the provider). Triggers must be specific enough to support a decision, not so broad as to require case-by-case negotiation at the point of activation.

Viable exit options. For each ICT service, the document must identify the realistic exit options available to the financial entity: transfer to an alternative provider, insourcing of the service, decommissioning of the function, or a hybrid approach. For each option, the document must assess operational feasibility, financial cost under stressed and non-stressed conditions, and the timeline to completion. The viability assessment must be current: an assessment that was accurate in 2022 but has not been updated following material market changes, provider consolidation, or changes to the firm's technology architecture is not an adequate basis for an exit strategy.

Transition plan and timeline. The step-by-step transition plan for the primary exit option, with a realistic timeline that reflects the contractual transition period, the data portability process, the alternative provider onboarding requirements, and the regulatory notification obligations that would be triggered by a disruption to the function. The timeline must be internally consistent: an exit plan that commits to transition completion within 30 days when the contractual data return period is 60 days has a feasibility gap that the document itself makes visible.

Data management and portability. The specific data management steps required on exit: what data must be returned by the provider and in what format, what data must be migrated to the successor arrangement, what data retention obligations apply during and after transition, and what the firm's obligations are to the provider and to regulatory authorities regarding data handling during the transition period.

Financial feasibility assessment. An estimate of the financial cost of exit under both a non-stressed scenario (managed, consensual transition) and a stressed scenario (provider insolvency, no-notice exit). The stressed scenario cost should include transition management resource, alternative provider onboarding cost, data migration cost, any parallel running period costs, and the customer and counterparty impact during transition. Many firms produce non-stressed financial estimates only; the stressed scenario estimate is the one that matters for regulatory purposes.

Testing record. For services meeting the DORA testing threshold, a record of the most recent exit strategy test: what was tested, when, how, what the findings were, and what remediation actions were taken. The testing record must be attached to or referenced from the exit strategy document, not maintained separately in a testing log that is not connected to the exit strategy at the document level.

Contractual provisions reference. A reference to the specific contract provisions that support the exit strategy, confirming that the contract contains the DORA-required provisions and identifying any contractual gaps that remain open. Where contractual re-papering is in progress, the document should note the current contract position and the expected completion date.

The Most Common Documentation Gaps

Across FourthLine's work with banking and insurance clients on DORA ICT exit documentation, four gaps appear most consistently.

The first is the absent stressed-scenario financial assessment. Most firms can produce a cost estimate for a managed, cooperative exit. Very few have modelled the stressed scenario cost, and for high-dependency ICT arrangements the difference between those two numbers is often an order of magnitude. Supervisors examining Article 28 documentation will ask for the stressed scenario assessment, and its absence suggests the firm has not genuinely interrogated its exit feasibility.

The second is the disconnect between the exit strategy document and the current contract. Many exit strategy documents reference contractual provisions that have not been verified as present in the current, executed contract. The provision may have been in a previous contract version, in a term sheet that was not fully incorporated, or in a side letter that has since expired. Verifying that the exit strategy accurately reflects the contract as it currently stands is a more time-consuming exercise than it appears, and it consistently surfaces gaps.

The third is the per-service document gap. Firms that produced framework-level exit planning documentation to satisfy PRA SS2/21 have typically produced one document that covers multiple ICT arrangements at a high level. DORA's expectation of a per-service exit strategy for each critical or important function service creates a document production requirement that most firms have not yet met, and the volume of work involved is frequently larger than initially estimated.

The fourth is the missing testing record at the document level. Firms that have conducted exit testing often hold the test records in a third-party risk management system or in a testing log that is not linked to the exit strategy document itself. A supervisor examining the exit strategy for a specific ICT service should be able to find the testing record within or directly referenced from that document. If the testing record requires a separate search to locate, the governance trail is broken.

Using This Standard as a Gap Assessment Tool

A practical use of the content standard described above is to conduct a document-level review of existing ICT exit strategies for the firm's highest-risk ICT arrangements, checking each required element against the current document. The output of that review is a gap register per service that identifies which elements are present, which are absent, and which are present but not current.

For most firms, that review will identify a material gap in the contractual provisions for a significant number of ICT arrangements, a missing stressed-scenario financial assessment for the highest-risk services, and an absence of per-service documents for services currently addressed at framework level.

FourthLine's Supplier Exit Testing Managed Service includes DORA Article 28 documentation as a defined programme element, covering the per-service exit strategy documents, the contractual gap analysis, and the testing programme for high-risk ICT arrangements. For firms where the documentation gap assessment is the first priority, the Supplier Exit Testing Diagnostic produces a structured view of the current documentation position against the DORA standard, with a prioritised remediation roadmap.