Vendor Exit Is a Data-Governance Test

An exit clause proves you have a lawyer. Extracting your data proves you have an exit.

An exit clause proves you have a lawyer. Extracting your data proves you have an exit.

Your outsourcing contract has an exit clause. Good. Now try to get your data out. Not view it in the vendor's screen — extract it, complete, with every relationship intact, and load it somewhere else.

Most firms discover the true state of their exit readiness at the worst possible moment: when they are already leaving. A platform decision has been made, a migration is underway, and only then does the firm learn that the data it thought it owned can be displayed inside the incumbent application but cannot be pulled out in a complete, relational, usable form. The narrative notes are there on screen. The links between them and the underlying client record are not exportable without additional engineering. The attachments live in one place; the records that reference them live in another; and nothing guarantees they can be reunited.

This is not a migration inconvenience. It is a governance finding. A firm that cannot recover its own data in a usable state has not actually retained control of that data, whatever the contract says.

An exit clause is not an exit

The JFSC guidance is direct that a firm's existing Outsourcing Policy applies to AI and third-party services, and that firms must maintain fallback and exit plans, understand their material dependencies, and keep appropriate contractual oversight. The word that does the work there is plan. A clause in a contract is not a plan. A plan is something you can execute, and the only way to know you can execute an exit is to have tried to extract a representative slice of your data and prove it comes out whole.

The pattern I return to is that firms conflate three very different things: the right to leave, the ability to leave, and the readiness to leave. The right is contractual. The ability is technical. The readiness is operational — it is the difference between a documented exit plan and a tested one. I have never seen a firm surprised by the first. I have repeatedly seen firms surprised by the second and third.

Vendor exit is not a legal question. It is a data-governance test — and like any control, it is only real once you have evidence it operates.

The three things exit actually tests

A serious exit test probes three properties of your data that a demo will never reveal, because a demo shows you the data inside the system that owns it.

1. Completeness

Can you extract every record, not just the ones the standard report was built to show? The records that break migrations are almost never the mainstream ones. They are the edge cases — the closed accounts, the historic entities, the free-text notes captured before the current template existed. A completeness test deliberately goes looking for those.

2. Relational integrity

When the data comes out, do the relationships survive? A client record that arrives without its link to the underlying trust, the associated correspondence, or the historic transactions is not your data restored — it is a pile of fragments that happens to contain your data. The primary keys and foreign keys that hold the model together inside the vendor's database must be exposed and preserved on the way out, or you are reconstructing them by hand.

3. Fidelity of narrative and attachments

The hardest content to extract is usually the most valuable: the narrative notes, the annotations, the attached documents, the audit history. These are frequently viewable but not exportable with a reliable link back to the record they belong to. That gap is exactly where a firm's institutional memory lives, and it is exactly what a screen-based demo hides.

Why this is a regulatory problem, not just an IT one

The stakes are higher in regulated financial services than in most sectors, because the inability to retrieve your own data collides with obligations that assume you can. Data-subject access requests assume you can find and produce an individual's records. Records-retention rules assume the record survives a change of system. Regulatory production assumes you can reconstruct what happened and why. An AML file whose narrative rationale cannot be extracted from a departing platform is not merely inconvenient — it is a control that may not survive the transition.

For AI-enabled services this widens further. Portability has to cover not only the source data but the logs, the evidence and the outputs needed to reconstruct or explain a regulated decision after the fact. If an outsourced AI service made or informed decisions, exiting it means being able to recover the trail that shows how those decisions were reached. A firm that cannot do that has an explainability gap that only becomes visible at exit — which is the worst time to find it.

Test the exit before you renew, not before you leave

The single most useful change a firm can make is to move the exit test forward in time — to run it before renewal, while the relationship is healthy and the vendor is motivated to help, rather than during a contested migration. Table 1 sets out what that test looks like in practice.

Table 1 — The exit test: what to prove before you renew a material outsourcing arrangement

There is a cadence to this that matters as much as the test itself. Exit readiness is not a one-off certification; it decays. A representative extract that came out cleanly two years ago tells you little about a platform that has since been upgraded, re-architected, or acquired by a new owner with different priorities. The firms that treat exit as a live control re-run the test on a defined rhythm — tied to renewals and to any material change in the vendor's ownership or architecture — rather than filing a successful extract and assuming it holds forever. A control you tested once and never again is a control you are only guessing still works.

The result of this test is not a document. It is confidence — the specific, evidenced confidence that if the firm ever needed to leave, it could, with its data and its institutional memory intact. That confidence is worth far more at the negotiating table than any exit clause, because a vendor who knows you have proven you can leave is a vendor who competes to keep you.

You have the contractual right to leave your most critical platform. When did you last extract a representative dataset and prove — not assume — that your data would come out complete, linked and usable?

Next: who should define the shape of your data — you or your vendor? Stop Letting the Vendor Define Your Data Model.

Sources: JFSC, Guidance on the use of AI in Jersey's financial services sector (2026) — Principle 2 (third-party/outsourcing, logging and auditability) and Principle 5 (explainability, evidence); Government of Jersey et al., Jersey AI Playbook (2026).

Professional disclaimer: The views expressed are my own and are shared for general informational purposes. This content is intentionally non-confidential and does not include proprietary, client-specific, or employer-sensitive information. It is not legal, regulatory, investment, or professional advice; readers should seek appropriate advice for their circumstances.

Financial services leader (20+ years) | Lean Six Sigma Green Belt | London School of Economics (LSE) AI Leadership Accelerator

A version of this article was first published on LinkedIn as part of the Sequence body of work. This is the canonical version.

The views expressed are the author's own and shared for general information. This content is intentionally non-confidential and does not include proprietary, client-specific or employer-sensitive information. It is not legal, regulatory, investment or professional advice. © 2026 Paul Soares. Sequence is the trading name of Sequence Advisory Limited (in formation) · hello@sequenceadvisory.com