If you run IT at an insurer that has outsourced its policy administration, the system you could least afford to lose is one you have never seen. It runs on the provider's platform. What you see of it is usually a portal, a set of reports and a service review. So when you need an exit plan for that administration, the obvious objection is fair: how do you plan to leave something you cannot look inside?
You can map the exit without seeing the systems. Map the service you buy, and turn each exit question into something the provider has to show you. The questions are the four from an earlier piece on exit strategy: can we leave, how long does it take, what does it cost, and under which law. The map is a table with one row per service and a column per question. Next to each answer goes the name of whoever gave it, and a basis column that records what the answer rests on: a test, the provider's word, or a guess. When the system belongs to someone else, the basis column matters as much as the answer.
What you buy is a configuration on a shared platform
A provider that serves several insurers or portfolios often runs them on one shared platform. If yours does, what you call your administration system is a configuration and a data set on that platform. The data is your policies and policyholders with their full history. The configuration is your product rules and policy conditions as the provider implemented them. Around both sit the interfaces: premium collection, claims payments, intermediaries, reporting to your finance and actuarial teams. Leaving means moving those three, plus something easy to forget: the knowledge of the people who configured your product rules.
Behind all of it, the provider often has suppliers of its own, for hosting, software and sometimes parts of the processing.
Because you buy a service, the row in your map is the policy administration service. Beneath it, where you can name them, go the parts that would move separately: the data, the configuration, each interface. Your product rules and policy conditions are your own documents. How the provider handled old products, closed books (portfolios no longer sold but still administered) and historic corrections when turning your rules into platform settings is a different matter. That may exist only in the platform and in a few people's heads.
Four questions, each with evidence to ask for
DORA is the EU regulation on digital operational resilience in finance, and it applies to insurers. Your policy administration may count under it as an ICT (information and communication technology) service supporting a critical or important function. If so, the contract must give you unrestricted access, inspection and audit rights, and an exit strategy with an adequate transition period. Check that yours does; if it does not, that is the first item for the renewal list.
The provider has little commercial reason to make leaving easy, and DORA's contract clauses turn a polite request into an obligation. If the provider still declines to answer, the refusal is itself an open item and a point for the contract renewal.
| Question | Ask the provider for | The answer is strong when |
|---|---|---|
| Can we leave? | A full extract of your data, with history, in a documented format; a written description of your configured product rules; a list of every interface | A sample extract exists and someone outside the provider has read it |
| How long does it take? | Their estimate for transferring your portfolio out, and the transition period in the contract | It rests on a transfer they have actually carried out, or a test load into another platform |
| What does it cost? | Exit and conversion charges, the cost of running the old and new administration side by side, and who pays for converting the data | The figures are in the contract or in a priced offer |
| Under which law? | Who owns the provider, where the platform and the data sit, and the subcontractors with their locations and owners; a foreign owner or a non-EU cloud underneath can give another country's authorities a route to your data | The subcontractor list is dated and recent |
The first row has legal backing: under DORA, every ICT services contract must provide for the return of your data in an easily accessible format when it ends. In that row, "someone outside the provider" usually means your own data people, an independent party you hire, or another provider in a tender. You arrange a test load with one of them, and its cost goes in the cost column.
Expect the first reply to point you to the provider's ISAE 3402 Type II report, the assurance report your auditor probably already relies on. It describes how the service's controls worked over the reporting period, which tells you about running the service and little about leaving it. Ask the four questions alongside it.
What the answers rest on
For an outsourced administration, most entries in the basis column start as the provider's word. That is useful in itself: it shows which parts of your exit nobody has checked.
The basis matters for the exit plan too. Under DORA, exit plans for ICT services supporting a critical or important function must be comprehensive, documented, sufficiently tested and periodically reviewed. A plan resting on the provider's word has not been tested. Whether that rule covers the whole administration contract or only its platform parts is for your compliance officer to decide; you need the map either way.
Two kinds of reply go straight into the exit plan as open items: questions left blank, and answers with no document behind them, the "trust us" kind. Each open item gets an owner and a date. The ones that need different contract terms go on the renewal list.
For example, suppose the provider gives a transfer estimate and, when asked, says it rests on general migration experience rather than on a portfolio it has moved out. The basis column then reads "provider's word". The exit plan gets an open item: agree a test extract within the coming year, loaded into a platform the provider does not run.
The effort, and what stays open
Chasing these answers takes someone in your team several rounds of correspondence, and the topic needs a place on the service review agenda more than once. Answers may come slowly and in general terms. If the provider fails or is sold, the same map serves the disruption scenario from the earlier piece. DORA's data-return requirement applies on the provider's insolvency as well as on termination.
I am not sure how to test the knowledge of the people who configured your product rules, short of a real transfer. The best I can suggest is to have the configuration choices written down and read by someone who does not work for the provider. If you have found a better test, I would like to hear it.
Before the next service review
Send the four questions for the policy administration service to the provider ahead of the next service review, and ask for the basis of each answer. Record the replies in the map with the name of whoever answered. Add every blank and every unsupported answer to the exit plan's open items, and put those items on the review agenda.
Jacques Domenie led the IT function of a bank under central-bank supervision and answered to its board, its supervisors and its auditor. He works for organisations part of the week through Delfen (delfen.com).
Contact: domenie@delfen.com or delfen.com/en/contact. The exit map is described at delfen.com/en/diensten.
Sources & further reading
- Regulation (EU) 2022/2554, the Digital Operational Resilience Act (DORA) — Article 2(1)(n): insurance and reinsurance undertakings are in scope, except small undertakings excluded from Solvency II under its Article 4 (Article 2(3)(b)); Article 28(8): an exit strategy for ICT services supporting critical or important functions, with comprehensive, documented, sufficiently tested and periodically reviewed exit plans; Article 30(2)(d): every ICT services contract provides for access, recovery and return of data in an easily accessible format on the provider's insolvency, resolution or discontinuation, or on termination; Article 30(3)(e) and (f): contracts for services supporting critical or important functions include unrestricted rights of access, inspection and audit, and exit strategies with a mandatory adequate transition period
- Verzekeraars hebben onvoldoende zicht op langer wordende uitbestedingsketens — De Nederlandsche Bank, 6 April 2022 (in Dutch)
- Staff overview of ISAE 3402, Assurance Reports on Controls at a Service Organization — IAASB (International Auditing and Assurance Standards Board), 2009
- What an exit strategy means in practice: four questions per system — Delfen, October 2026
- Exit map: which systems can you actually leave? — Delfen