DORA Exit Strategy for LLM Providers: Requirements and Tests

Article 28(8) does five things. It names four risks the exit strategy must account for: a possible failure of the provider, a deterioration of the quality of the ICT services, business disruption from inappropriate or failed provision (or material risk to the "appropriate and continuous deployment" of the service), and termination under any of the circumstances in Article 28(7). It sets three conditions for the exit itself: no disruption to business activities, no limit on compliance with regulatory requirements, and no detriment to the continuity and quality of services to clients. It requires exit plans to be comprehensive, documented, sufficiently tested and periodically reviewed. It requires alternative solutions and transition plans that move the service and its data "to alternative providers or reincorporate them in-house". And its last subparagraph requires "appropriate contingency measures" to maintain continuity while any of this happens.

Commission Delegated Regulation (EU) 2024/1773, the RTS on the contractual policy, turns that into plan-level detail in Article 10. The policy must require a documented exit plan for each contractual arrangement, plus periodic review and testing of that plan. Three scenarios must be considered: unforeseen and persistent service interruptions, inappropriate or failed service delivery, and the unexpected termination of the arrangement. The plan must be "realistic, feasible, based on plausible scenarios and reasonable assumptions" and have an implementation schedule "compatible with the exit and termination terms established in the contractual arrangements".

Three things DORA does not say matter as much. It sets no fixed test frequency for exit plans: the "at least yearly" figure in Article 11(6)(a) belongs to business continuity testing. It does not mandate a second provider: Article 6(9) says entities "may" define a multi-vendor strategy. And no regulator publishes an exit plan template. For significant banks, the ECB's Guide on outsourcing cloud services, published in July 2025, spells out supervisory expectations for exit plan contents. It states it is not legally binding and adds no requirements beyond DORA, so everything cited from it below is supervisory expectation or observed good practice for ECB-supervised banks and good practice by analogy for insurers and investment firms.

The exit obligation only bites for ICT services supporting a critical or important function. Article 3(22) defines that as a function whose disruption "would materially impair the financial performance of a financial entity, or the soundness or continuity of its services and activities", or whose failed performance would materially impair continuing compliance with its authorisation or other obligations under financial services law. On our reading, a hosted LLM API fits the broad definition of an ICT service in Article 3(21) on its face. The live question is the function it supports.

RTS 2024/1773 Article 3(2) requires a written methodology for deciding which services support critical or important functions. DORA Article 28(3) also requires you to inform the competent authority "when a function has become critical or important". That second clause is how LLM pilots drift into scope: a drafting assistant used by one team can become the step every complaint response passes through without anyone re-running the classification.

The table below is our reading of typical uses against the Article 3(22) limbs, not a supervisory classification.

For anything in scope, the register of information already asks the supervisor-facing questions the exit plan has to answer. Template B_07.01 under Implementing Regulation (EU) 2024/2956 records the substitutability of the provider, whether an exit plan exists, the possibility of reintegrating the service, the impact of discontinuing it, and whether alternative providers have been identified. The exit plan is the evidence behind those answers. If the register says "easily substitutable" for a model whose prompts were tuned to one model family, the exit test is where that answer gets checked.

DORA is technology-neutral. It never mentions model deprecation or drift. The mapping below from Article 28(8)'s four risk categories to LLM events is ours, and it is the part a template written for a cloud swap has no row for.

The quality row has public evidence behind it. A study of GPT-3.5 and GPT-4, first posted on arXiv in July 2023 and revised that October, compared the March and June 2023 versions of both models across seven task types, from math and code generation to medical licence questions, and found that their performance and behaviour "can vary greatly over time". That is a quality change, not an outage, and an availability check is not built to catch it.

A major outage on the first row is also a DORA incident question, with its own classification and reporting clocks, which we cover in which regulator's incident clock starts first. The exit plan and the incident process are separate obligations that get triggered by the same event.

The termination row has a wrinkle for models consumed through a platform. Under Delegated Regulation (EU) 2025/532, a provider must inform you "well in time" of intended material changes to subcontracting for services supporting critical or important functions, and you may provide for termination if it implements changes you objected to. Our interpretation: when a hyperscaler marketplace or an AI-enabled SaaS swaps a third-party model underneath your workflow, that can be a material subcontracting change, and the contract should treat it as one.

Read that against RTS Article 10's demand for a schedule "compatible with the exit and termination terms". The contract may run for three years while the model version you validated is retired in 60 days. For an LLM, the operative constraint in the exit schedule is often the shortest realistic retirement notice on the channel you use. Enterprise agreements can carry different retention terms, and that is worth negotiating, but the plan should be built on what is written down.

A plan that names a fallback provider and a gateway setting proves very little. For a model, these six items carry the weight. Each one ties to a source; where the source is the ECB Guide, it is supervisory good practice for significant banks.

DORA runs two testing regimes, and they answer different questions. Article 11(6) requires business continuity plans to be tested at least yearly, including "switchovers between the primary ICT infrastructure and the redundant capacity". Delegated Regulation (EU) 2024/1774 Article 25 extends that testing to third-party services and scenarios such as provider insolvency or failure. That is BCP testing. Exit plan testing sits in Article 28(8) and RTS 2024/1773 Article 10, and it asks whether the service can move for good. The ECB states the split in one line: "While BCM measures should ensure the continuity of services in the short term, exit plans should ensure continuity in the long term."

An AI gateway that can route traffic to a second model is worth having, and our comparison of LiteLLM, Portkey and Kong AI Gateway covers the choice. But a switchover through the gateway proves the plumbing. It does not prove that the second model extracts the right fields from a credit file or writes an AML narrative an analyst can sign. A model can return HTTP 200 on every request and still fail the workflow.

An exit test for a model, as a procedure your team can run:

How deep and how often scales with Article 4(2) proportionality. The ECB's good-practice floor for significant banks is an in-depth desktop review plus periodic tests of the most critical migration steps; for a model, the replay-and-score run is that critical step. Re-run it whenever the incumbent provider announces a retirement on a model your workflow uses. That is the moment the exit stops being hypothetical, and the result tells you whether you can meet the notice period.

A second hosted provider fixes the provider-failure row and inherits the other two. It has its own retirement schedule, with published minimums as short as 2 weeks for preview models and 45 or 60 days on several of the channels above, and its models can change behaviour under an unchanged name. Swapping one schedule you do not control for another moves the risk rather than exiting it.

An open-weight model running on hardware you control is the one alternative where your team decides when the version changes. The weights are pinned, so the model you tested is the model you run. Prompts, evaluation sets and logs stay in your own systems. You can re-run the exit test on demand rather than when a vendor's notice arrives. It is also the literal "reincorporate them in-house" route Article 28(8) names, and it changes the honest answer to the register's "possibility of reintegration" field. Keeping that model warm on a slice of real traffic turns "sufficiently tested" from a desktop exercise into a standing measurement. To be precise: DORA does not require a warm standby. It is our recommendation for meeting the testing duty credibly.

Concentration points the same way. The list of 19 critical ICT third-party providers the European Supervisory Authorities designated in November 2025 includes Amazon Web Services EMEA, Google Cloud EMEA and Microsoft Ireland Operations, and no standalone model developer. Designation puts those providers under oversight by the authorities. It does not relieve you of anything: under Article 28(1)(a) the financial entity remains fully responsible "at all times". Third-country considerations under Article 29(2) add to the case, and our post on EU AI Act data sovereignty and residency covers that reasoning.

The limits belong in the plan, not in a footnote:

Groups with US operations face a separate regime for vendor models; which LLM parts are in scope under SR 26-2 covers that side. The exit questions also belong in pre-contract due diligence, because Article 29 asks you to weigh substitutability before you sign, not after.

List every model ID used by a workflow you classify as critical or important, including the ones reached through Azure, Bedrock or Vertex. Next to each, write the published retirement notice for that channel and your estimated transition time to the alternative named in the exit plan. Where the transition time is longer than the notice, that gap is the first finding for the exit plan.

Then assign one named person to own the parity suite for each of those workflows, with a pass threshold agreed before anyone runs a test. Without a suite and a threshold, there is nothing to test the exit against.