On 8 July 2026, Aire, the group Stackscale belongs to, held the first webinar in its Despeja tu Cloud series. The sessions aim to explain the regulatory, technical and geopolitical changes reshaping how companies procure infrastructure. Zigor Gaubeca, CIO at Aire, and David Aibar Carretero, Head of Sales, raised a question that should reach every boardroom: if a judge asked today which jurisdiction governs the company’s critical data, would there be a clear and documented answer?
The answer does not depend solely on the country where the data centre is located. A workload may run physically in Madrid, Paris or Frankfurt and still be exposed to the laws of a third country because of the provider’s nationality, corporate structure or effective control. This is why cloud sovereignty is increasingly becoming part of business continuity planning, alongside cybersecurity, backups, high availability and Disaster Recovery.
Cloud sovereignty: the key points in 20 seconds
- Hosting data in Europe does not in itself guarantee that it is governed exclusively by European law.
- Jurisdiction also depends on the company providing the service, its parent company, its subcontractors and who possesses, holds or controls the information.
- The US CLOUD Act may apply to data stored outside the United States when it is controlled by a provider subject to US jurisdiction.
- This does not allow arbitrary access to any information. There must be a valid and specific legal request linked to a legal proceeding.
- The European Data Act, generally applicable since 12 September 2025, requires providers to reduce contractual, commercial and technical barriers to switching cloud providers.
- From 12 January 2027, providers will no longer be allowed to charge the switching fees defined by the Data Act, although migrations will still involve technical and operational costs.
- On 3 June 2026, the European Commission presented the proposal for the Cloud and AI Development Act, CADA, which introduces a common framework for assessing different levels of cloud and Artificial Intelligence sovereignty.
- Sovereignty does not require companies to abandon hyperscalers. It requires them to understand their dependencies, diversify where a real risk exists and maintain a viable alternative.
- An exit plan that has never been tested is not yet an operational plan.
The location of the data centre does not determine the whole jurisdiction
For years, many infrastructure decisions were considered complete once the provider confirmed that it offered a European region. This was a reasonable criterion: keeping data within the European Union brings it closer to users and corporate systems, can reduce latency and helps meet certain data residency requirements.
But physical location only answers part of the question.
It is also necessary to understand which legal entity signs the contract, where its parent company is incorporated, from which countries the service can be administered, who controls the encryption keys, which subcontractors are involved and which laws apply to the corporate group.
The CLOUD Act, approved in the United States in 2018, establishes that providers of electronic communication services or remote computing services must preserve, back up or disclose information under their “possession, custody or control”, regardless of whether it is stored inside or outside the United States.
This does not mean that an authority can access all data hosted by a provider without cause. There must be a valid order, request or legal procedure relating to specific information. Providers may also challenge certain requests and use the legal remedies available under the applicable legislation.
The risk for a European company appears where different jurisdictions overlap. On the one hand, the company must comply with the General Data Protection Regulation, rules on international transfers and its contractual obligations. On the other, it may depend on a provider that is subject to requests from a third country.
European data residency remains important, but it is not enough to describe the legal exposure of a platform.
A complete assessment should answer at least the following questions:
| Area | Question the company must answer |
|---|---|
| Location | In which countries and data centres is the data stored, processed and replicated? |
| Provider | Which legal entity signs the contract, and where are its parent company and relevant subsidiaries incorporated? |
| Jurisdiction | Which foreign laws may affect the service or the provider? |
| Operations | From which countries can support and administration staff access the platform? |
| Encryption | Who generates, controls, stores and can recover the encryption keys? |
| Subcontracting | Which third parties are involved in the service and from which territories do they operate? |
| Government access | How does the provider respond to requests from domestic or foreign authorities? |
| Portability | Which data, images, configurations, logs and metadata can be exported? |
| Exit | Which deadlines, costs, formats and restrictions apply when the service ends? |
The answer should not be scattered across contracts, technical appendices, privacy policies and sales presentations. Technology, security, compliance, procurement and management teams need a common map that explains where the data is, who can administer it and what would happen if it had to be moved.
What changes under the European Data Act
The Data Act introduces specific obligations to make it easier to switch between providers of data processing services. These include IaaS services, cloud platforms and other models in which a company processes or stores information using resources contracted from a third party.
The regulation requires providers to remove commercial, technical, contractual and organisational obstacles that prevent customers from switching to another provider, moving data to their own infrastructure or using several providers simultaneously.
Contracts must specify the categories of data and digital assets that can be transferred, the available formats, known technical limitations and the period during which the information can still be retrieved after the transition has ended. They must also provide for the source provider to cooperate in maintaining continuity and supporting the customer’s exit strategy.
As a general rule, the maximum transition period is 30 calendar days once the contractual notice period has ended, which itself cannot exceed two months. If that deadline is technically unfeasible, the provider must justify this and propose an alternative period that may not exceed seven months.
On 12 January 2027, so-called switching charges will disappear. These are the fees imposed by the source provider for actions that the Data Act requires it to perform during the switch.
That does not make a cloud migration free.
The company will still have to bear the costs of consulting, engineering, data transfer, bandwidth, application adaptation, parallel operations, testing, new licences and training. Nor does the regulation automatically eliminate early termination penalties or the cost of additional work that falls outside the regulated switching process.
The Data Act reduces barriers, but it cannot by itself undo an architecture built around services that are exclusive to a single platform. The greater the use of proprietary databases, serverless functions, identity tools, queues, APIs or provider-specific managed services, the more complex the exit will be.
The regulation also requires providers to publish the jurisdiction governing the infrastructure used for each service and a general description of the technical, organisational and contractual measures adopted to prevent international government access that conflicts with European law.
At this point, it is useful to distinguish between different types of information. The Data Act provisions on international government access focus on non-personal data. Personal data remains subject to the GDPR and the rest of the European privacy framework.
CADA and Europe’s new sovereignty levels
On 3 June 2026, the European Commission presented the proposal for the Cloud and AI Development Act. CADA aims to expand European capacity in data centres, cloud and Artificial Intelligence, make it easier to deploy new infrastructure and reduce dependencies considered risky.
The proposal introduces a European sovereignty framework with four assurance levels. The first is based on data being processed and stored on infrastructure located within the European Union. The higher levels add requirements relating to independence from third countries, transparency across the software supply chain, European ownership and control, and the absence of external interference.
The distinction between these levels reflects a central idea: location still matters, but it is not the same as control.
CADA also provides for common criteria in public procurement, stronger support for open source technologies and measures to accelerate the deployment of cloud and data centre infrastructure. The Commission also proposes at least tripling Europe’s data centre capacity over the next five to seven years.
It is still a legislative proposal. Its content may change during negotiations in the European Parliament and the Council. Even so, the political direction is clear: dependence on infrastructure and providers from third countries is no longer viewed solely as an issue of competition or privacy, but also as a risk to the resilience of public administrations, hospitals, banks, industrial organisations and essential services.
Cloud providers will increasingly be assessed against a combination of criteria: security, portability, interoperability, jurisdiction, operational control, sustainability and the ability to maintain service during legal or geopolitical change.
Operational sovereignty: design the exit before it is needed
One of the most useful ideas discussed during the webinar was the distinction between sovereignty as an institutional concept and the operational sovereignty a company needs.
Operational sovereignty can be measured. An organisation has greater control when it can decide where each application runs, knows who administers its data and maintains a viable alternative if conditions change.
Such a change may be triggered by an outage, a cyberattack, a price increase, a corporate acquisition, a change in licensing model, a new regulatory requirement or a geopolitical decision.
As David Aibar explained during the session, many companies calculate in detail how much it costs to move into the cloud, but few estimate how much it would cost to leave. The comparison used was that of renting an office: in addition to the rent and the initial fit-out, a company should anticipate the cost of leaving the premises and returning them in the agreed condition.
In cloud infrastructure, the exit cost may include extracting data, converting virtual machines, rebuilding networks, replacing managed services, carrying out performance tests, running two platforms in parallel and validating applications.
Not all workloads present the same level of difficulty. A virtual machine based on common formats may be moved with a reasonable amount of effort. An application built around numerous platform-specific services will require more engineering, testing and code changes.
Sovereignty does not mean avoiding every proprietary technology. It means understanding the cost of dependency and consciously deciding where it is acceptable.
A hybrid strategy, not migration for its own sake
Sovereignty does not require organisations to move every workload away from AWS, Microsoft Azure or Google Cloud. Hyperscalers offer global coverage, advanced services, on-demand capacity and rapid access to analytics and Artificial Intelligence technologies.
They may be a good option for global applications, temporary environments, projects with highly variable demand or workloads whose sensitivity and level of dependency have been assessed in advance.
Other systems require greater control: customer databases, transactional platforms, intellectual property, essential internal services, backups, systems subject to sector-specific regulation or applications with stable and predictable usage.
A hybrid model allows each workload to be placed according to its requirements:
| Workload type | Possible approach |
|---|---|
| Development, testing and temporary projects | Flexible public cloud |
| Global applications with variable demand | Hyperscaler or multicloud architecture |
| Business systems with stable usage | Private cloud with dedicated resources |
| Sensitive or regulated data | Infrastructure with clearly defined jurisdiction and operations |
| Resource-intensive databases | Bare-metal or dedicated infrastructure |
| Backups and recovery | Provider or location independent from production |
| Critical workloads | High availability, replication and tested procedures |
Using several platforms does not in itself create sovereignty. A multicloud environment without proper design may duplicate tools, increase costs and make security harder to manage. Diversification should respond to specific risks and rely on shared procedures, identities, networks, monitoring and policies.
Stackscale’s role in an operational sovereignty strategy
Stackscale can serve as dedicated European infrastructure within a hybrid or multicloud model. Its private cloud solutions combine exclusive hardware, network storage, private connectivity, specialised support and virtualisation based on Proxmox VE or VMware.
Proxmox VE makes it possible to build virtualisation platforms using open source technologies such as KVM and LXC. For many companies, it can provide an alternative that reduces dependence on certain licensing models and gives them greater control over total cost of ownership. The decision should be based on an assessment of compatibility, availability, backups, networking, storage and operational capabilities, not solely on the price of the hypervisor.
Bare-metal is suitable for workloads that require dedicated performance, low latency, isolation, direct access to hardware or more predictable behaviour. Private cloud adds a virtualisation and management layer over allocated resources, allowing applications to be consolidated without sharing physical capacity with other customers.
For mission-critical environments, Stackscale provides storage with synchronous geo-replication between two Madrid data centres located more than ten kilometres apart. According to the published service specifications, it is designed for zero RPO and zero RTO, with independent and redundant storage systems, snapshot-based backups and 24/7 technical support.
The strategy can be complemented with reserved infrastructure for Disaster Recovery. This model allows a cold spare to be maintained at a remote location, activated during periodic tests and used to restore applications after a hardware failure, cyberattack or other emergency.
These capabilities fit a range of designs: production on private cloud with backups in another location, workloads running on a hyperscaler with recovery at Stackscale, Proxmox VE clusters with network storage, VMware platforms requiring a second site, or gradual migrations from on-premise and public cloud environments.
The objective should not be to move all infrastructure to a single destination. The priority is to build an alternative that can be used when needed.
A 90-day cloud exit plan
An initial assessment does not require a full migration. It can be organised over three months:
| Phase | Required work | Outcome |
|---|---|---|
| Inventory | Identify machines, data, services, networks and dependencies | Up-to-date platform map |
| Classification | Rank workloads by criticality, sensitivity and regulation | Clear priorities |
| Jurisdiction | Review the provider, parent company, subcontractors and countries involved | Legal exposure map |
| Portability | Document formats, APIs, images and export tools | Known technical barriers |
| Costs | Calculate transfer, engineering, licensing and parallel operation | Initial exit budget |
| Destination | Select alternative infrastructure | Available recovery capacity |
| Pilot | Migrate or restore a representative workload | Tested procedure |
| Continuity | Define RTO, RPO and tolerance for disruption | Measurable targets |
| Security | Review identities, keys, encryption and logs | Control during transition |
| Testing | Repeat exports, restores and failovers | Current and verifiable plan |
During the first month, the company can complete the inventory and classify its workloads. In the second, it can select a representative system, prepare the destination and carry out an initial migration or restore. The third month should be used to measure timings, document exceptions and present the identified costs and risks to management.
The result does not have to be an immediate migration. Knowing that an alternative exists, how much it costs, how long it takes and which dependencies must be resolved already improves the organisation’s ability to make decisions.
Cloud sovereignty becomes useful when it stops being a political concept and is translated into architecture, contracts, procedures and tests. Moving into a platform is a technical and financial decision. Retaining the freedom to choose how and when to leave is a business continuity decision.
Frequently asked questions
Does hosting data in a European region prevent the CLOUD Act from applying?
Not necessarily. Physical location is relevant, but companies must also check whether the provider is subject to US jurisdiction and whether it possesses, holds or controls the information.
Does the Data Act make cloud migration free of charge?
No. From 12 January 2027, it removes the switching charges defined by the regulation, but companies will still bear the costs of engineering, adaptation, transfer, testing and operations.
Does a sovereignty strategy require companies to abandon hyperscalers?
No. It can combine public cloud, private cloud, bare-metal, European providers and an independent location for backups or recovery. Each workload should be placed according to its risk, criticality and technical dependencies.
What is the first step towards reducing dependence on a provider?
Create an inventory of workloads and dependencies, review the applicable jurisdiction and carry out a real export, migration or recovery test on an alternative infrastructure.
Sources:
- Despeja tu Cloud webinar held by Aire on 08/07/2026.
- Regulation (EU) 2023/2854, Data Act, in particular Articles 23 to 32.
- United States Code, Title 18, Section 2713, on the territorial scope of the CLOUD Act.
- European Commission proposal for the Cloud and AI Development Act, presented on 03/06/2026.
- Stackscale, private cloud solutions with Proxmox VE and VMware.
- Stackscale, storage with synchronous geo-replication.
- Stackscale, reserved infrastructure for Disaster Recovery.
