The three layers of digital autonomy

The discussion of digital sovereignty in Europe has long suffered from imprecision. The term has been used interchangeably for trade protectionism, regulatory ambition, data residency, and political self-confidence. By 2026, after five years of experience implementing the GDPR, NIS2, DORA, the AI Act, and the Cyber Resilience Act, there is enough empirical material to divide the term more carefully.

The working definition this site uses: digital sovereignty is the capacity of an organisation to dispose of its digital assets according to its own will — within current physical limits, and with active use of every option that the international legal and contractual framework permits. It is not "Made in EU." It is not isolationism. It is a technical and legal architecture that preserves the possibility of switching — the ability to change provider, jurisdiction, or technology without ruinous cost.

That capacity decomposes into three layers, each of which can be compromised independently of the others.

The bit layer

The data itself. Sequences of ones and zeros, at rest and in motion. The operative question: where do my data physically live, and who has access to them?

Europe addresses this layer relatively well. The GDPR, the Schrems II ruling , and the subsequent EU–US Data Privacy Framework have constructed the legal scaffolding; technically, BYOK and HYOK are now standard offerings from every hyperscaler. Where the bit layer fails is when data sits in a proprietary format that only the current vendor can read. If you cannot export your data — in days, not years, in a standard format — you are not sovereign at the bit layer. You are a tenant.

The EU Data Act , whose switching provisions came into force on 12 September 2025, addresses exactly this problem. From that date forward, cloud service providers must enable customers to migrate to alternatives within fixed timelines, in standard formats, and — by January 2027 — without exit fees. Whether the regulation is enforced as written is a separate question, addressed in the Enforcement section.

The interpretation layer

The ability to make meaning from data without the provider's cooperation. This layer is often overlooked because it is less visible than physical storage. Interpretation autonomy is not just possession of decryption keys; it is control over the algorithms, schemas, and logic that turn bits into human-comprehensible information.

An example: an organisation has migrated all its communications to a platform that stores messages in a proprietary protocol with vendor-side encryption. Even with a physical backup of the data, without the vendor you have unusable noise. The same applies to AI models: if your enterprise decisions depend on a closed third-party model whose queries and outputs cannot be audited, replicated, or migrated, your interpretation layer is with the vendor, not with you.

The instrumentation layer

The tools — hardware and software — that manage the data. In a sovereign framing, these tools are treated as replaceable: the organisation must be able to swap the "tractor" (tool) without losing the "seed" (data) or the "knowledge of cultivation" (interpretive ability). This is the difference between healthy dependency and vendor lock-in. Dependency is convenient and often economically rational. Lock-in is a trap.

The instrumentation layer is where extraterritorial legal regimes have their direct effect. The CLOUD Act permits U.S. authorities to compel data held by U.S. providers regardless of physical location; FISA Section 702 permits the surveillance of non-U.S. persons' communications. Neither requires the provider to act in bad faith. The provider is simply subject to U.S. legal process by virtue of corporate structure. From the customer's perspective, the result is what matters: an external jurisdiction can reach into the instrumentation layer of the European cloud whenever its legal threshold is met.

European jurisdiction is not symmetric protection. The September 2024 Canadian court order against OVHcloud , in which a Canadian court attempted to compel OVHcloud to produce data held in France, the UK, and Australia, illustrates the limit. OVHcloud invoked the French blocking statute (loi de blocage) and refused to comply. The case shows that even European providers can be subject to extraterritorial pressure; the difference is that they have legal instruments — national blocking statutes — that give them at least a procedural defence.

Why the layers matter strategically

Not every dependency is a problem. Some are economically rational. Others are fatal. The key to distinguishing them is exactly which layer you are talking about.

Consider three typical situations.

A medium-sized European company runs its webshop, ERP, and collaboration tools on a single hyperscale cloud. This is an instrumentation-layer dependency — on a tool. If the vendor proves unsuitable, the company has work to do, but migration is achievable: data is exported, applications reinstalled, business continues. Inconvenient, not fatal. Here, consolidation on one provider is typically rational — economies of scale outweigh the risk.

The same company decides that all internal communication, knowledge base, and decision support runs through one closed-model AI vendor — prompts, embeddings, vector databases, all inside one proprietary ecosystem. This is an interpretation-layer dependency. If the company loses the vendor, it physically holds its data, but without the tool that can read them, the data are practically unusable. Consolidation here is strategically dangerous, even if cheaper in the short term.

Finally: the company stores its production data warehouse with a single provider that reserves the right to modify contract terms unilaterally, and whose export interface is proprietary and metered. This is a bit-layer dependency. There is no rational argument for consolidation here without negotiated exit options, regardless of how convenient or cheap the current arrangement looks. If you cannot get your data out in days in a standard format, you are not the owner of the data. You are a tenant.

Rule: the deeper in the stack a dependency lies, the more expensive its materialisation in a crisis becomes, and the higher the premium that is rational to pay for preserving the option of exit.

Minimum Viable Sovereignty

This three-layer framework is the operating ground of Minimum Viable Sovereignty (MVS) — a concept articulated by Forrester analyst Dario Maisto . MVS is not a binary state; it is a spectrum, on which each organisation chooses its depth according to its own risk profile.

MVS accepts that full sovereignty across all three layers is unattainable and largely undesirable for most organisations. What it requires is a minimum set of contractual, architectural, and operational measures that allows the organisation to switch providers in a horizon of months, not years — without losing data, without losing the ability to interpret them, and without legal or commercial trap that would prevent the switch.

The DORA designations of November 2025 — classifying nineteen ICT providers as critical third-party providers subject to direct EU supervision, including AWS, Azure, and Google Cloud — operationalise this exact view. The supervisory framework does not require that European financial institutions stop using these providers. It requires that they have demonstrated, tested ability to switch away from them.

The remainder of this site develops MVS into concrete decisions: how to map dependencies (Dependencies), where European alternatives actually exist (Alternatives), with whom to partner (Partnerships), what to put into contracts and in what sequence (Operations), and what regulatory enforcement can and cannot achieve (Enforcement).