What is European Sovereign Infrastructure? A working definition.

That is the short answer. The rest of this article explains why the definition is needed, unpacks its three layers, tests it against the frameworks Europe is now using to score sovereignty claims, and gives buyers the questions that separate sovereign infrastructure from sovereign marketing.

Why does Europe need a definition of sovereign infrastructure?

Because the word sovereign has become the most overworked adjective in European technology. Hyperscalers attach it to regional cloud offerings. National champions attach it to ownership structures. Colocation providers attach it to the location of their buildings. Each usage means something different, and some mean very little.

Until recently there was no way to arbitrate between these claims. That changed on 20 October 2025, when the European Commission published its Cloud Sovereignty Framework, a scoring methodology that turns sovereignty from a slogan into a set of measurable objectives. In April 2026 the Commission used it to award its first cloud contracts under the Cloud III procurement, worth up to €180 million. Sovereignty claims now have money and rejection thresholds attached to them.

Yet the framework is a scoring instrument, not a definition. It tells procurement teams how to grade a provider. It does not give the market a shared answer to the prior question: what is this thing we are grading? This article proposes that answer.

What are the three layers of sovereign infrastructure?

Any sovereignty claim can be tested against three layers. Infrastructure is sovereign to the extent that it passes all three, and most claims fail on the layer their marketing does not mention.

The jurisdictional layer: which laws can reach the data?

Infrastructure is jurisdictionally sovereign when no authority outside Europe can lawfully compel access to the data it hosts or the systems it runs.

This is a question about legal exposure, not geography. A data centre in Frankfurt does not place its contents under exclusively European law if the entity operating it, or a parent of that entity, answers to courts elsewhere. The United States CLOUD Act (18 U.S.C. § 2713) requires providers subject to US jurisdiction to disclose data in their possession, custody, or control regardless of where that data is stored. Section 702 of the Foreign Intelligence Surveillance Act authorises the collection of communications of non-US persons held by US electronic communication service providers. Other jurisdictions maintain equivalent instruments, including China's national security and cybersecurity legislation.

None of this makes any particular provider unusable. It makes jurisdictional exposure a fact to be established, not assumed. The test is simple to state and surprisingly hard to answer from most providers' public materials: trace every entity in the chain of control, from the operating company to its ultimate parent, and ask which disclosure laws each one is subject to.

The operational layer: who actually runs it?

Infrastructure is operationally sovereign when the people, processes, and decisions that control it day to day sit within European entities and European legal obligations.

Jurisdiction describes what can be compelled in theory. Operation describes what can be done in practice. The questions that matter here are concrete. Who holds administrative access to the systems? Where are the staff who can enter the facility, image a server, or reset a credential? Who holds the encryption keys, and under which legal entity is the key management function housed? When an incident occurs at three in the morning, whose chain of command does the response run through?

Operational sovereignty is where abstractions become auditable. A provider can have a complex international ownership structure and still demonstrate that no person outside its European operating entity can access customer data, because access control, key custody, and personnel security are engineered that way. Equally, a provider can be wholly European-owned and fail this layer, because it has outsourced platform operations, key management, or support to entities under foreign jurisdiction.

The technical layer: can control be proven?

Infrastructure is technically sovereign when its jurisdictional and operational claims can be verified by cryptographic and architectural means rather than taken on trust.

Contracts and org charts assert control. Technology can demonstrate it. The mechanisms are maturing quickly: encryption where the customer or a European trustee holds the keys, so that compelled disclosure yields ciphertext; confidential computing, which keeps data encrypted even during processing inside hardware-isolated enclaves; and remote attestation, which lets a customer cryptographically verify what software is running on the infrastructure before trusting it with a workload.

The technical layer matters because it changes the nature of the promise. Without it, sovereignty is a legal opinion about what a provider would be forced to do. With it, sovereignty becomes a property of the system: even a lawfully compelled provider cannot hand over what it cannot decrypt. European procurement is beginning to recognise this distinction, and later articles in this edition examine a working implementation of it.

How do existing frameworks define sovereignty?

A definition is only useful if it is compatible with the instruments buyers must actually use. The three-layer model maps cleanly onto them.

The EU Cloud Sovereignty Framework (European Commission, version 1.2.1, October 2025) assesses providers against eight Sovereignty Objectives: strategic, legal and jurisdictional, data and AI, operational, supply chain, technology, security and compliance, and environmental sustainability. Each objective is scored on a five-level scale called SEAL, the Sovereignty Effectiveness Assurance Level, running from SEAL-0 (no sovereignty) to SEAL-4 (full digital sovereignty). Two features deserve attention. Tenders set a minimum SEAL level per objective, and an offer that misses the minimum on any single objective can be rejected outright, however strong it is elsewhere. And the weighting is a policy statement in itself: supply chain carries the heaviest weight at 20 percent, while legal jurisdiction carries 10 percent, signalling that the Commission sees hardware and software provenance as the harder problem. A companion article in this edition decodes the framework objective by objective.

EUCS, the draft European cybersecurity certification scheme for cloud services developed under ENISA, has spent years at the centre of a dispute over precisely the question this article addresses: whether the highest assurance levels should carry sovereignty requirements such as European ownership and immunity from foreign law. The unresolved argument is itself evidence that Europe lacks a settled definition.

National schemes preceded both. France's SecNumCloud qualification, maintained by ANSSI, imposes strict requirements on ownership, legal exposure, and operations, and is the closest thing Europe has to a purist standard. Germany's C5 catalogue, maintained by the BSI, takes a transparency-first approach, requiring providers to disclose rather than eliminate foreign exposure. Gaia-X attempts federation across these traditions through common policy rules and self-descriptions.

The three-layer model is not a rival to any of these. It is the conceptual structure they all score against: the jurisdictional layer corresponds to legal and strategic objectives, the operational layer to operational and data-control objectives, and the technical layer to the technology and security objectives. A buyer who understands the three layers can read any of these frameworks fluently.

Does ownership matter, or operation?

This is the hardest question in the field, and any honest definition has to hold it open rather than resolve it by assertion.

The case for ownership is serious. Ownership determines strategic direction, and strategy outlasts any current operating model. A parent entity under foreign jurisdiction can be compelled, acquired, sanctioned, or simply redirected, and the operational safeguards that exist today exist at its discretion. Change-of-control risk is real: an operationally impeccable provider can be sold. This is why SecNumCloud constrains ownership, why the EUCS dispute persists, and why the Commission's framework includes strategic sovereignty as a scored objective on which providers with non-European ownership score poorly regardless of operational quality. Buyers with long horizons and existential stakes, defence and intelligence workloads above all, are rational to price this risk.

The case for operation is equally serious. In practice, what an authority can compel depends on what the entities under its jurisdiction can actually do. If the European operating company holds the keys, employs the staff, and controls the facilities, and the foreign parent holds shares but no access, then the compellable surface is small, and the technical layer can shrink it further. Operational control is also auditable in a way ownership purity is not: you can test key custody and access paths; you cannot test the future intentions of a shareholder. And a Europe that defines sovereignty purely by ownership excludes most of its existing infrastructure capacity at the exact moment demand, driven by AI workloads, is outrunning supply.

These are two different risk profiles, not a right and a wrong answer. Ownership addresses strategic, long-horizon risk. Operation addresses present, compellable-access risk. The April 2026 Cloud III awards suggest the Commission itself takes the pragmatic view, having qualified at least one provider that runs non-European technology under exclusively European operation. Whether that position survives contact with the harder cases is one of the questions this publication exists to track. What buyers should do is not pick a side but identify which risk their regulator, tender, or threat model actually addresses, and test for that.

What questions should buyers ask?

Sovereignty diligence collapses into a short list of questions, mapped to the three layers. A provider that answers all of them in writing is making a claim you can hold them to. A provider that answers with a brochure is not.

1. Under which jurisdiction is the operating entity incorporated, and does any entity in its ownership chain fall under non-EU disclosure laws such as the CLOUD Act or equivalent instruments?

2. If a foreign authority served a lawful disclosure order on your parent or affiliate, what data could that entity actually produce, and what would it be technically unable to produce?

3. Who holds the encryption keys for data at rest and in transit, under which legal entity, and can we hold our own keys?

4. Which roles have administrative or physical access to the systems hosting our workloads, where are those people employed, and under which entity's security clearance regime?

5. Where does your incident response and support chain run, and can any step be escalated outside European entities?

6. Which sovereignty assessments have you completed, and will you share your per-objective SEAL self-assessment, not just a composite score?

7. What happens to control, keys, and operations if your ownership changes? Is there a contractual change-of-control protection?

8. Which of your sovereignty claims are verifiable by us, through attestation, audit rights, or key custody, rather than asserted by you?

Where is this going?

Three developments will shape the next two years. SEAL scoring is moving from a single Commission procurement toward a common language for tenders, and the forthcoming Cloud and AI Development Act is expected to build on its methodology, which means per-objective sovereignty evidence will become a standing procurement requirement rather than a differentiator. The EUCS dispute will resolve, one way or the other, and either outcome redraws the competitive map. And AI infrastructure is raising the stakes on every layer at once, because training data, model weights, and inference workloads concentrate more value behind the same sovereignty questions.

This publication will track all three, vertical by vertical, edition by edition. The definition offered here is a working one in both senses: it is built to be used, and it will be revised as the ground moves.