Summary: Most organisations put a great deal of energy into selecting and onboarding a critical IT or SaaS supplier – but few have a plan for leaving one. A termination clause is not an exit plan. A practical exit strategy covers the service, data, integrations, identity, alternatives, transition, supplier support and closure – and it needs to be tested before it is needed. For financial entities, DORA makes the question an explicit requirement.

When a new supplier is brought in, a lot of effort goes into onboarding:

due diligence
security review
contract negotiation
data processing agreement
integrations
training and rollout

But the question rarely asked is the one that matters most for resilience: How do we get out of here if we have to?

The supplier may go bankrupt, be acquired, suffer a serious incident, change its terms, raise prices sharply or simply stop delivering what you need. If the only plan at that point is “we terminate the contract”, you have no options – and a negotiating position of zero.

Termination is not the same as exit

Being able to terminate a contract is a legal matter. Being able to leave a supplier without the business grinding to a halt is something else entirely. A real exit needs to answer:

How do we get our data out – complete, in a usable format and within a reasonable time?
What happens to the integrations that other systems depend on?
Who takes over the service – internally or another supplier?
How long does the transition take in practice?
How do we keep the business running in the meantime?
Which permissions, keys and identities need to be moved or revoked?
What support is the supplier obliged to provide – and what does it cost?
How do we ensure that data is actually deleted at the supplier afterwards?

If the answers are missing, you have a termination clause, not an exit plan.

DORA makes the question very concrete

For financial entities, exit strategies are no longer good practice but a requirement. DORA requires documented exit strategies for ICT services supporting critical or important functions. The strategies must be comprehensive, documented, sufficiently tested and reviewed periodically, and they must enable an exit without disrupting business activities, without limiting compliance with regulatory requirements and without detriment to the continuity and quality of services provided to clients.

DORA also requires contracts to include termination rights and a transition period during which the supplier continues to deliver, to reduce the risk of disruption. In other words: exit must be planned, contracted and tested – not improvised.

But the logic applies to every organisation with critical supplier dependencies. The Swedish Cybersecurity Act and ISO 27001 require supplier control and continuity, and a business that cannot leave its most important supplier has a weak point in its operational resilience – regardless of sector.

What should a practical exit plan contain?

An exit plan does not need to be a hundred-page document. It needs to answer the right questions across eight areas.

The service

Which business processes depend on the service, and how critical are they?
How long can the business cope without the service?
Which functions are irreplaceable and which can be temporarily simplified?

Data

What data is held by the supplier, including configuration, history, logs and attachments?
In which format can it be exported, and is that format usable without the supplier’s tools?
How long does a full export take, and have you tried it?

Integrations

Which systems send data to or retrieve data from the service?
Which APIs, file flows and automations stop working on exit?
Are the integrations documented, or does the knowledge sit with individual people?

Identity and access

Is the service connected to your identity solution, or does it have its own accounts and passwords?
Which API keys, certificates and service accounts need to be revoked or moved?
Does the supplier hold permissions in your environment that must be terminated?

Alternatives

Are there realistic alternative suppliers, or an internal solution?
How long does it take to get an alternative into operation?
Is there a temporary fallback that keeps the business running during the transition?

Transition

Who leads the transition, and what resources are required?
In what order are data, integrations and users moved?
How do you verify that everything has transferred correctly before the old service is shut down?

Supplier support

What is the supplier contractually obliged to do on exit – export, transition period, migration support?
What does the support cost, and how long is the transition period?
What happens if the supplier no longer exists or does not cooperate?

Deletion and closure

How and when is your data deleted at the supplier and its sub-processors?
Do you receive a confirmation or a certificate of deletion?
Which contracts, licences and permissions must be formally closed?

Test the exit before you need it

An exit plan that has never been tested is an assumption. The test does not have to mean actually switching suppliers – but it does need to prove that the critical steps work. Questions to try out in practice:

Can you perform a full data export today, and how long does it take?
Can the export be loaded into another tool, or is it only readable in the supplier’s system?
Do the numbers of records, attachments and history match what you expect?
Do you know exactly which integrations stop working, and have you tried switching one off?
Can you revoke the supplier’s access to your environment within an hour?
Have you walked through the exit scenario in a tabletop exercise with the business, IT and legal?
Do the time estimates in your plan hold up when compared with the test?

Testing selected parts – the export, one integration, the access revocation – is often enough to uncover the assumptions that do not hold.

When should the plan be reviewed?

An exit plan is perishable. It should be reviewed at least annually, and additionally whenever any of the following occurs:

the supplier is acquired, changes ownership or changes strategy
the supplier suffers a serious incident or runs into financial difficulty
the service takes on a more critical role in your business
new integrations or new data flows are introduced
the supplier changes sub-processor, operating model or region
the contract is renewed or the terms change
regulatory requirements change
a test has shown that the plan did not hold

It works best when the exit plan is part of ongoing third-party risk management – not a separate document someone happens to find once the crisis has already arrived.

How Kristensson i Skåne can help

We help organisations move from a termination clause to a working exit strategy. Depending on your needs, we can contribute with:

criticality assessment of suppliers and services
third-party risk analysis
exit strategy and exit plan for critical suppliers
contractual requirements for exit, transition period and data export
mapping of dependencies, integrations and data flows
linking to business continuity and crisis management
exit tabletop exercises with the business, IT and legal
testing of selected parts of the exit plan
ongoing supplier review and reassessment

The best time to build an exit plan is before you need it. The second best time is now.

Do you know how to leave your critical suppliers? Read more about our financial regulations and DORA services or contact us for an informal conversation.

Sources: Regulation (EU) 2022/2554 (DORA), Article 28 on general principles for managing ICT third-party risk, including exit strategies, and Article 30 on contractual arrangements; the Swedish Cybersecurity Act (2025:1506); ISO/IEC 27001:2022, controls for supplier relationships and continuity.

This text is general information and does not constitute legal advice in an individual matter.