Sovereign Cloud Exit Planning: Contractual Portability and Data Repatriation

Sovereign cloud exit planning is the structured process by which an organisation legally enforces its right to leave a cloud or SaaS provider, technically recovers its data in a usable state, and operationally transitions to a destination infrastructure without losing business continuity. For regulated European organisations, this process is no longer optional: Regulation (EU) 2023/2854 (the Data Act), Regulation (EU) 2022/2554 (DORA), and the NIS-2 Directive each impose enforceable obligations on providers and users alike, and supervisors across finance, healthcare, and public administration are beginning to ask for evidence that exit procedures actually work.

What the Data Act Requires From Cloud Providers, and Where Contracts Must Go Further

Data Act Chapter VI (Articles 23-31) establishes minimum switching rights that every cloud service provider offering services in the EU must honour from 12 September 2025. Existing contracts concluded before that date must be brought into conformity by 12 September 2027.

Article 25 requires providers to give customers at least 30 days’ prior notice before imposing any change that affects switching. Article 26 sets a maximum porting period of 30 calendar days for standard datasets, extendable to 7 months only in exceptional and documented circumstances. Article 27 mandates that all egress fees be reduced to zero by September 2027 at the latest. Article 29 obliges providers to furnish “switching assistance” in a format and with documentation sufficient for the destination provider or the customer’s own team to reconstruct the service.

These are floor rights, not ceilings. Regulated buyers in finance, healthcare, and the public sector face continuity and audit obligations that the statutory minimum does not fully address. Contracts should therefore go beyond Article 26 by specifying a porting window that aligns with the organisation’s own recovery time objective, typically shorter than 30 days for critical workloads. They should also define the exact format of exported data (for example, open standards such as ODF for documents, LDIF for directory data, and SQL dumps in an agreed schema version for databases), require cryptographic checksums on delivered packages, and fix a named escrow or verification agent who confirms receipt and integrity before the porting period is declared complete.

DORA Articles 28-30: Translating Concentration Risk Into Binding Contract Clauses

For financial entities, DORA Articles 28-30 create the most operationally demanding exit obligations in European law. Article 28 requires that all ICT third-party contracts supporting critical or important functions include explicit exit provisions. Article 29 mandates a documented exit strategy maintained by the financial entity itself, covering transition periods, alternative arrangements, and continuity safeguards. Article 30 addresses ICT concentration risk, requiring entities to assess whether reliance on a single provider or a small group of providers creates systemic exposure.

The European Banking Authority’s Guidelines on ICT and Security Risk Management (EBA/GL/2019/04) reinforce this by requiring financial entities to assess the substitutability of providers and to maintain evidence that an exit can be executed within a defined timeframe without material disruption to the delivery of financial services.

“Concentration risk in ICT is not merely a technical concern; it is a systemic financial stability issue. Financial entities must be able to exit a critical provider without disruption to their core functions.” (European Banking Authority, EBA/GL/2019/04)

Contract clauses that satisfy EBA, EIOPA, and ESMA supervisory expectations should include: a defined maximum transition period (typically 12 months for complex workloads, 3 months for simpler SaaS); a mandatory data handover schedule with milestone dates; a provision obliging the provider to continue operating the service at current service levels for the full transition period even after notice of termination is given; a requirement to provide full access to configuration data, API schemas, and integration documentation; and a prohibition on service degradation, feature withdrawal, or price increases during the transition window. These clauses must be negotiated at contract inception, not at the point of exit.

The Technical Repatriation Protocol: What Exit Clauses Must Specify

A legally enforceable exit clause is necessary but not sufficient. Without a technically precise repatriation protocol embedded in the agreement, the organisation arrives at migration day with ambiguous deliverables and a provider that fulfils the letter of the contract by handing over an unusable archive.

A complete technical repatriation protocol should address four domains:

Organisations replacing Microsoft 365 or Google Workspace with a sovereign Nextcloud-based environment should also specify that email exports conform to MBOX or EML with RFC 5322 headers intact, and that calendar and contact data is delivered as iCal and vCard respectively, to avoid re-keying contact records manually at the destination.

Pre-Negotiating and Testing Exit Procedures: Demonstrating Compliance to NIS-2 and DORA Supervisors

Negotiating exit rights at contract inception is the prerequisite; demonstrating that those rights are exercisable is what satisfies a regulator. NIS-2 Article 21 requires organisations in scope to implement business continuity measures and to test them. DORA Article 26 requires financial entities to test their ICT continuity plans, and supervisors increasingly treat untested exit strategies as a compliance gap rather than a paper formality.

A dry-run migration exercise is the practical mechanism. The organisation selects a representative subset of its data, typically 5-10% of total volume including at least one instance of each data category in scope, exports it from the incumbent provider using the contractually specified process, validates checksums and metadata, reconstructs permissions in a staging environment at the destination, and documents the elapsed time and any deviations from the protocol. The results are retained as audit evidence. Annual frequency is the current industry baseline, supported by EBA supervisory expectations.

Supply chain attacks targeting cloud providers represent a growing reason to treat exit readiness as a live operational posture. ENISA Threat Landscape 2023 found that 17% of intrusions analysed involved supply chain compromise, meaning an organisation may need to execute an exit under adversarial conditions, not only as a planned commercial transition.

Data Act Standard Contractual Clauses and Their Interaction With GDPR Article 28

The Commission Implementing Regulation on Data Act standard contractual clauses for cloud switching provides template language that organisations can incorporate directly or use as a baseline for negotiation. These clauses cover the mechanics of portability: format, timeline, egress fee elimination, and switching assistance obligations. They are designed to be compliant with Articles 23-31 of the Data Act without further amendment, though regulated buyers should supplement them with sector-specific additions as described above.

“The Data Act ensures that users are not trapped with one cloud provider. Switching assistance and the elimination of egress fees are fundamental to a competitive and trustworthy European cloud market.” (European Commission, Data Act explainer)

GDPR Article 28 operates on a different axis but must be read in conjunction with Data Act clauses wherever the cloud service processes personal data. Article 28 requires that the processor agreement address sub-processor controls, deletion of personal data on termination, and audit rights. The critical intersection is deletion timing: Data Act portability clauses define when the provider must complete data export; GDPR Article 28 processor agreements must specify that provider-side deletion of personal data occurs only after the organisation has confirmed receipt and integrity of the export, not before. Misalignment between these two timelines creates a scenario in which personal data is deleted before the organisation can verify that its own copy is complete and usable.

IBM’s Cost of a Data Breach Report 2023 recorded an average breach cost of USD 4.45 million, the highest in the report’s 18-year history. Organisations with inadequate data recovery procedures faced materially higher costs, underscoring that exit readiness is also a risk quantification issue, not purely a compliance checkbox.

Using the CADA Cloud Sovereignty Framework and EU Cloud Sovereignty Standards to Evaluate Exit Destinations

Selecting a sovereign exit destination requires more than a provider’s marketing claim. The CADA Cloud Sovereignty Framework, which assigns SEAL levels to cloud offerings based on verifiable criteria, gives compliance officers a structured tool for this evaluation. SEAL criteria examine the legal jurisdiction of the provider entity and its ultimate parent, the physical and logical location of data processing, the technical controls preventing access under foreign jurisdiction (such as the US CLOUD Act or FISA Section 702), and the audit and certification evidence supporting those controls.

Eurostat reported that 45.2% of EU enterprises with 10 or more employees used cloud computing in 2023, yet a large proportion of that capacity remains hosted on infrastructure subject to non-EU jurisdiction. Compliance officers benchmarking a proposed sovereign destination, such as a Swiss-hosted private cloud under the revised Federal Act on Data Protection (revFADP), or a French-hosted offering certified under SecNumCloud, should map each SEAL criterion against the provider’s documentation and request contractual representations where documentation is absent.

The EU Cloud Sovereignty Framework, developed within ENISA and the European Cloud User Coalition, adds a second layer of benchmarking focused on portability and interoperability standards. Compliance officers should verify that the proposed destination supports the same open data formats required in the incumbent provider’s exit clause, that it participates in a recognised certification scheme (ISO 27001, SOC 2 Type II, BSI C5), and that its own exit terms are at least as favourable as those negotiated with the departing provider. Sovereign cloud exit planning that creates a new lock-in at the destination merely transfers the risk rather than eliminating it.

FAQ

When do the egress fee elimination obligations under the Data Act take effect for existing cloud contracts?

Data Act Chapter VI entered into force with Regulation (EU) 2023/2854 and applies from 12 September 2025. Existing contracts concluded before that date must be brought into compliance by 12 September 2027, giving regulated buyers a defined window to renegotiate or terminate non-compliant agreements.

Does a DORA-compliant exit strategy clause need to cover SaaS as well as IaaS and PaaS providers?

Yes. DORA Articles 28-30 apply to all ICT third-party service providers supporting critical or important functions, regardless of service layer. A financial entity must map every SaaS tool that touches a critical function and ensure each agreement contains an exit plan with defined transition periods, data handover procedures, and continuity safeguards.

How do Data Act standard contractual clauses interact with GDPR Article 28 processor agreements?

They are complementary and must both be present in regulated cloud contracts. The Data Act standard contractual clauses govern portability mechanics: format, timeline, egress fees, and switching assistance. GDPR Article 28 governs the lawful basis, sub-processor controls, deletion obligations, and audit rights for personal data. Where a cloud service processes personal data and falls under Data Act scope, both sets of clauses must be aligned, particularly on deletion timing: provider-side deletion of personal data must not occur until the organisation has confirmed receipt and integrity of its own export.

What does the CADA Cloud Sovereignty Framework SEAL classification assess, and how does it help choose an exit destination?

The CADA framework assigns SEAL levels based on the legal jurisdiction of the provider and its parent company, the location and isolation of data processing, technical controls preventing foreign law enforcement access, and audit and certification evidence. Compliance officers can use SEAL levels as a structured checklist to verify that a proposed sovereign destination actually removes the jurisdictional exposure present in a hyperscaler contract, rather than simply marketing itself as sovereign.

What is a dry-run migration exercise and how often should it be performed to satisfy NIS-2 and DORA supervisors?

A dry-run migration exercise is a time-boxed test in which the organisation exports a defined dataset from the incumbent provider, transforms it into the target format, validates metadata and permission integrity, and imports it into the destination environment without committing to a final cutover. NIS-2 requires demonstrable continuity measures, and DORA explicitly expects financial entities to test exit procedures. Annual testing is the current minimum, with results documented and available for regulatory inspection.