ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
A cloud exit plan is the documented answer to a question most organizations avoid until it is urgent: how do we leave this cloud service, with our data intact, our operations running and our obligations met? It covers when you would leave, how your data and configuration come back, how the provider proves it has deleted what it holds, and how work moves to a new provider or back in-house. Writing it before you sign, and testing it afterwards, is far cheaper than improvising during a dispute or an outage.
This guide explains what a cloud exit plan should contain, how the ISO 27017 and ISO 27018 standards connect to it, what the EU Data Act says about switching providers, and how to build a plan you can actually use. It is general information and not legal advice.
Exit is not only about a broken relationship. Reasons to leave include price rises, a security incident, a provider failure or acquisition, a change in law, poor performance, and a simple strategic decision to move. In each case, the customer’s difficulty is the same: data and workloads live in someone else’s environment, in formats and services that may not be portable, under contract terms that were written for the start of the relationship and not the end.
Regulators and standards increasingly expect a plan. Financial entities in the EU face exit-strategy expectations for critical ICT services, which our guide to the DORA exit strategy covers. Outside finance, good third-party risk practice asks for the same, and it is a routine question in supplier assessments. See our guide to SaaS vendor risk assessment for how exit fits into due diligence.
| Section | What it settles |
|---|---|
| Scope and criticality | Which service, which data, which business processes depend on it |
| Exit triggers | Events that start the plan: breach, insolvency, price change, failure to meet service levels |
| Roles | Who decides, who executes, who communicates |
| Data return | What is exported, in which formats, by when |
| Deletion | What the provider deletes, when, and what evidence it gives |
| Transition | How services run during the move and where they go next |
| Costs | Fees, staff time, parallel running |
| Testing | How and when the plan is rehearsed |
ISO/IEC 27017 gives guidance for information security controls in cloud services, for both providers and customers, and ISO/IEC 27018 covers protection of personal data in public clouds acting as data processors. Both have new editions. ISO shows the 2015 edition of ISO/IEC 27017 as withdrawn on 27 July 2026, replaced by ISO/IEC 27017:2026, and lists ISO/IEC 27018:2025 as the current edition of that standard, replacing the 2019 text. You can check the status on the ISO page for ISO/IEC 27017.
The 2015 edition of ISO 27017 included a control on removal of cloud service customer assets, which addressed the return and removal of customer assets on termination. If you are working with the newer edition, the numbering and structure differ, so check where the equivalent guidance now sits. Our overview of ISO 27017 explains the changes. For personal data, ISO 27018 is about how a public cloud provider handles it as a processor, including limits on use and how it is erased. The exit plan should show how those commitments are met at the end of the contract, especially for return and secure erasure.
For customers in the EU, the Data Act adds legal weight. The European Commission states that the switching rules apply from 12 September 2025. Under them, customers can switch data-processing service providers with a maximum notice period of two months, a 30-day transition period for data export and migration is provided for, and switching charges are being phased out: reduced charges are allowed until 12 January 2027 and prohibited after that. Read the Commission’s summary on the Data Act policy page, and check the text of the regulation and your contract for scope, since the rules apply to particular kinds of services and customers.
The practical effect is that the exit plan should map contract terms to these rights, and any clause that seems to contradict them should go to legal review. Plan your timelines around the notice and transition periods as a baseline.
The following is a hypothetical illustration. A mid-sized company uses a cloud-based customer relationship system holding personal data of 400,000 customers. Its cloud exit plan lists the data objects, attachments, custom fields, automations and user permissions, and notes that a standard export omits automations and attachment metadata. The contract promises export in an open format within 30 days of request and deletion within 60 days after that, with a certificate. During the annual test, the team exports a sample and restores it into a test environment, and finds that date fields are exported in a different format that breaks the import. They record the fix, ask the provider for a corrected export template, and update the plan. When the provider is later acquired and prices rise, the plan tells them what to do on day one, and the exit is completed without loss of data.
These two are the heart of the plan. On return, insist on complete data in a usable, documented format, along with metadata and anything else needed to make the data meaningful, such as schemas and reference tables. Agree the method, whether by API, bulk export or physical transfer, and the time window. On deletion, ask for a defined schedule, coverage of backups and copies held by sub-processors, and written confirmation. Do not delete your own copy until you have verified the data you received, because you may not be able to go back. Where personal data is involved, keep evidence of deletion for your records, since you may need to show it to a regulator or a customer.
The plan is only as strong as the contract behind it. Negotiate termination assistance, export formats, timelines, deletion and evidence up front, when you have most leverage, and record them in the service agreement. Our guide to the cloud service agreement lists the clauses to look for, and the shared responsibility matrix helps you see who is accountable for what while the service runs and at the point of exit.
You will need a plan for each critical service, a contract checklist, a data return specification, a deletion confirmation template, a test report and a decision record. The ISO 27017 and ISO 27018 Toolkit provides cloud security and PII templates that you can adapt to your suppliers and services. Keep the plan short, specific and reviewed, since a plan that nobody reads offers no protection.
It depends on your sector. Some regulations, such as DORA for financial entities, expect exit strategies for critical services, and many customers and auditors ask for one as good practice.
All your data, including copies in backups and with sub-processors, according to a defined schedule and with written confirmation. Agree the details in the contract.
Under the EU Data Act’s switching rules, notice can be at most two months and a 30-day transition period applies, subject to the scope of the rules and your contract.
Yes. At minimum, test a data export and restore, and run a table-top exercise. Untested exit plans usually fail on formats and dependencies.
They provide guidance on cloud security and on protecting personal data in public clouds, including handling of customer assets and data at the end of service. Check the current editions for exact wording.
September 30, 2026
