Your Regulator Now Requires an Exit Plan
Vendor exit went from paranoia to paperwork. Most firms still can't produce one.

On November 18, 2025, the EU's financial supervisors designated 19 technology providers as critical to the European financial system and placed them under direct regulatory oversight: AWS, Microsoft, Google Cloud, Oracle, SAP, and the rest of a list that reads like a concentration diagram of modern finance. It was a quietly remarkable document. Regulators had spent a decade warning about cloud concentration; now they'd written the names down.
The designation is the visible half of a shift that started earlier. DORA, applying since January 17, 2025, requires financial entities to maintain documented exit strategies for their critical ICT providers, and NIS2 pushes supply-chain risk duties across a much wider set of sectors. Here's the claim of this post: vendor-exit planning has completed its migration from paranoid whiteboard exercise to supervised compliance artifact, most organizations' artifacts wouldn't survive contact with an actual exit, and the gap between those two facts is where the next few years of audit findings live.
What the rules actually ask
Strip the legal prose and DORA's demand is short: know which providers you can't operate without, contract for the right to leave them, and hold a strategy for doing so without wrecking your operations. Not a vague intention. A document, maintained, that an auditor can request, tied to registers of your ICT dependencies that supervisors now collect. The 19-name list completes the pincer: your regulator supervises your side of the dependency, and other regulators now supervise the provider's side, which means the question "what if you had to leave AWS" is no longer hypothetical enough for anyone to skip.
The trap is that a document is the cheapest thing to fake. A slide deck titled "Exit Strategy" that says "we would migrate to an alternative provider following a structured program" is the compliance equivalent of a fire plan that says "in case of fire, exit the building". It names the goal. It contains no fire.
The scope is wider than finance, too. NIS2 extends supply-chain risk duties to energy, transport, health, water, and digital infrastructure, sectors staffed by people who never expected to think about cloud concentration, and national transpositions keep adding local flavor. The regulatory pattern is consistent across all of it: dependency on a provider is treated as risk you must be able to unwind, and the burden of proof is drifting from "assure us" toward "show us".
What a real one contains
A plan that would survive an actual exit has four load-bearing parts, and each one is a thing, not a sentence. A current inventory of what you actually run, which is harder than it sounds and stale the week after it's compiled by hand. A mapping from each component to a provider-neutral equivalent, honest about the proprietary services with no clean twin. A restore of your data, executed at least once, somewhere else, with the duration written down. And a time estimate built from those three, in weeks, signed by someone whose name means something.
Run the test on your own organization. If assembling those four parts would take a quarter, you don't have an exit plan; you have a plan to have a plan, and the difference shows up precisely when the plan is needed, which is also when it's needed fast: a provider failure, a sanctions surprise, a price shock on renewal, a sovereignty ruling going the wrong way. Fire drills exist because evacuation instructions read differently in smoke.
Freshness is the fifth part, and the one plans die of first. Every element above decays: the inventory drifts with each deploy, the mapping rots as providers rename services, last year's restore proves nothing about this year's data volume. A plan reviewed annually is a photograph of a moving object. The practical fix is making the artifact a byproduct of systems that are already current, rather than a document someone must remember to update out of diligence.
The steelman: nobody ever actually exits
The standing objection is empirical and fair: full cloud exits are rare, forced ones rarer, and the compliance industry now selling exit-plan templates is extracting rent from a scenario that mostly never arrives. Auditors accepting well-formatted PDFs make it worse; if the artifact passes without being tested, the rational firm produces artifacts, and the whole regime becomes mutual theater. Anyone who's watched a business-continuity binder gather dust knows the genre.
All true, and it misses where the value lives. The plan's byproducts are worth more than the plan: the inventory is operational gold the first time an incident makes you ask "what talks to what"; the tested restore is your ransomware recovery, relabeled; the mapping is your negotiation position at every renewal, because a vendor who knows you can leave prices differently than one who knows you can't. The option's value doesn't require exercise. And regulators, whatever their pace, have started asking the theater-piercing question, which is not "show me the document" but "show me when you last tested it".
This is also, unavoidably, why we build what we build: a deterministic graph of what runs where, mapped across providers, is the exit plan's hardest section generated as a byproduct of normal operation instead of a quarterly archaeology dig. That's our stake, stated plainly.
But the argument stands without us. The regulation only wrote down what was always true: a dependency you can't unwind on your own schedule is a decision someone else will eventually make for you. When your auditor, or your board, asks for the exit plan this year, you'll produce a document either way. The only question is whether there's a fire drill behind it. When did your last one run?
Related: Multi-Cloud Is Overrated. Portability Isn't., where the option-not-deployment argument started. More about what we're building at light-cloud.com.