A European Data Centre Does Not Make Your Cloud Sovereign

A company moves sensitive workloads from a US data centre to Frankfurt and tells the board that the data now sits in Europe. The servers do. The provider may still answer to a US parent company, run support from several countries, control the encryption keys and use software that European customers cannot operate independently.

Brussels is starting to put those questions into procurement rules. Its proposed framework for sovereign cloud services looks at who controls the service and supply chain, where infrastructure sits, how providers process data and who controls cybersecurity. Defence and healthcare data would face stricter requirements than routine administrative workloads.

AWS, Microsoft Azure and Google Cloud together hold about 70 percent of the European cloud infrastructure market. European providers account for roughly 15 percent, down from 29 percent in 2017. European organisations therefore enter the sovereignty debate with much of their technology already tied to US platforms.

The supplier matters as much as the server

Companies rarely chose that dependence in one decision. One team adopted Azure because it already used Microsoft products. Developers put new services on AWS because the tools were available. AI projects later added model APIs, databases and security services from the same platform.

Changing supplier means replacing more than compute capacity. An Azure customer using OpenAI services through the platform may also rely on Microsoft identity management, logging and databases. Moving the application elsewhere means rebuilding those connections and running them afterwards.

European alternatives do not always match the largest US platforms on features, integration or price. A procurement team therefore needs to decide where independence is worth paying for rather than applying the same requirement to every workload.

The EU’s planned model reflects that. Brussels is considering four levels of cloud sovereignty and expects member states to match them to particular public-sector uses. A defence system and a public information website would not face the same requirements.

Who can actually reach the data?

Data residency is easy to specify in a contract. Administrative access is harder. A provider may keep customer data in Frankfurt while engineers elsewhere retain privileged access. Support systems may copy logs or telemetry outside the region. The provider may hold the encryption keys and control the identity service administrators use to enter the environment.

IT buyers need to know where those privileges sit. They need the names of the organisations that administer the service, the countries from which support teams operate and the circumstances under which the provider accesses customer data.

Encryption changes little if the same supplier stores the data and controls the keys. Several US cloud companies have responded with European offerings that restrict access and give customers more control over encryption and administration. Buyers still need to examine what changes technically. A European product name or data-centre address does not answer who ultimately has the ability to read, alter or suspend the service.

What happens if the provider cuts access?

US sanctions against the International Criminal Court have already turned the sovereignty debate into an operational issue. European judges affected by the sanctions lost access to web services supplied by American companies.

Most businesses are unlikely to face sanctions. They still depend on providers for much more than hardware, and a vendor does not need to suffer an outage for a customer to lose access.

A company may have backups yet still depend on the original provider’s identity service, database technology, security tools or proprietary APIs. Exporting the data does not recreate the application somewhere else.

Disaster-recovery plans should therefore include loss of the provider itself. Teams need to know which systems stop first, where they keep an independent copy of critical data and which credentials, certificates and encryption keys they need to restart elsewhere.

They also need a realistic migration time. A contract promising data portability is of limited help if engineers need six months to replace the services around the data.

European providers also have dependencies

Buying from a European company does not remove every foreign dependency. A local provider may use US processors, security software or networking equipment. Requiring every component to come from Europe would leave few practical cloud environments.

Procurement teams need to separate dependencies that could stop a service from components that are merely foreign-made.

A US processor inside a European data centre creates a different exposure from a remotely administered platform whose operator can suspend a customer account. An American security tool embedded in the stack does not carry the same risk as handing the provider control of every encryption key.

The planned EU framework looks at control of the service and supply chain rather than treating geography as the only measure. Companies can do the same analysis now.

AI is pulling companies further into the hyperscalers

Generative AI adds another reason to stay with the largest cloud providers. They package models, computing capacity, databases, identity tools and security into environments companies already use.

A development team on Azure can add OpenAI services without setting up another supplier. AWS and Google offer similar paths into their own AI stacks. Moving the AI workload later means moving the surrounding data and application services as well.

European providers face a commercial problem as a result. They need enough customers to fund comparable infrastructure, while buyers choose the hyperscalers partly because they already have more infrastructure.

Public procurement may give European suppliers more demand. Private companies have more room to split workloads. A manufacturer might keep collaboration software with a global provider but place sensitive engineering data elsewhere. A bank could separate AI experimentation from systems holding regulated customer information. Running several environments costs more, so companies need to decide which data and applications justify it.

Sovereignty has an operating cost

Multi-cloud architecture requires engineers who understand several platforms. Independent recovery environments consume storage and compute. Smaller European providers sometimes lack managed services that large platforms include as standard.

Paying those costs for every application makes little sense. A marketing system with replaceable data does not require the same controls as medical records, defence information or the intellectual property behind a company’s main product.

The procurement work starts with identifying the systems that the business cannot afford to lose or expose. For each one, teams need to know which provider controls access, which jurisdiction applies, where the encryption keys sit, how much of the application uses proprietary services and how long a move would take.

A Frankfurt server answers only where the machine is. Sovereignty depends on who still controls what happens to it.