The Shift That Took Longer Than It Should Have
Data sovereignty has been discussed in European enterprise technology circles since Schrems II invalidated the Privacy Shield framework in 2020. The conversation it produced was primarily a legal and compliance conversation: what does this mean for our EU-US data transfers, how do we manage Standard Contractual Clauses, what is the regulatory risk from continued operation of systems that may not meet updated transfer requirements?
That was the right conversation to have then. It is not sufficient now.
The data sovereignty question has expanded from a legal risk management question to a strategic architecture question, driven by a confluence of regulatory developments, geopolitical signals, and technology capability changes that together have made where data lives and who controls it a board-level strategic matter rather than a legal department concern.
The unfiltered perspective this article offers is based on direct engagement with European enterprise boards, technology leadership teams, and architecture decisions across multiple sectors and multiple jurisdictions. It is not the perspective of a sovereignty product vendor with a solution to sell. It is the perspective of someone who has watched the conversation evolve and has formed clear views about what European enterprises should be doing about it.
The Three Realities That Have Changed the Conversation
The first reality is that European regulators have become more specific about what sovereignty means in practice, and the specificity has revealed that most existing hyperscaler sovereignty programmes do not fully address what the regulations now require.
The EU AI Act’s requirements for transparency, audit access, and human oversight of high-risk AI systems imply that the enterprise deploying those systems must have visibility into and control over the AI processing in a way that hyperscaler-hosted AI services do not straightforwardly provide. The technical isolation that a hyperscaler’s EU data boundary product provides at the infrastructure level is not the same as the operational transparency and control that the AI Act requires at the application level.
The NIS2 supply chain security provisions require covered entities to assess the security practices of their ICT supply chain, including their cloud providers. The assessment right and the audit right that this requires are not universally present in hyperscaler contracts, and the hyperscaler’s response to supply chain security assessment requests varies significantly.
DORA for financial services requires ICT third-party risk management that includes the right to audit critical ICT third-party providers. The critical ICT third-party framework under DORA creates supervisory oversight of the largest hyperscalers as Critical ICT Third-Party Providers, which changes the nature of the relationship but does not eliminate the enterprise’s own risk management obligations.
The second reality is that geopolitical risk in technology supply chains has moved from a theoretical concern to a board-level risk assessment consideration. The dependence of European critical infrastructure on US-headquartered technology supply chains has been identified in government risk assessments as a concentration risk that deserves strategic attention. The boards of European enterprises are asking the question their governments are raising: what is our continuity position if this supply chain is disrupted?
The honest answer, for most enterprises, is that the continuity position for hyperscaler-hosted infrastructure is not well-defined. The cloud-native applications built to run on a specific hyperscaler’s services cannot be rapidly migrated in a disruption scenario. The operational dependency is real and the mitigation plan is, in most cases, not credible.
The third reality is that European cloud alternatives have reached a capability threshold that changes the architecture options available for sovereign deployments. OVHcloud, Deutsche Telekom’s Open Telekom Cloud, Hetzner, and a range of national and sector-specific cloud providers are providing infrastructure capabilities that were not available three to five years ago. The assessment of European alternatives that was done in 2020 or 2022 needs to be repeated against 2026 capability, and the conclusion will be different in meaningful ways.
The Architecture Decisions That Follow from These Realities
The architecture decision that data sovereignty as a cloud strategy determinant requires is a workload classification by sovereignty requirement, followed by infrastructure assignment that matches each workload to the infrastructure model that meets its sovereignty requirements.
The sovereignty requirements vary by data type, by regulatory obligation, by sector, and by the enterprise’s own risk tolerance for supply chain concentration. A healthcare enterprise processing patient data under eHealth data space requirements has different sovereignty requirements than a retail enterprise processing customer transaction data under GDPR. A financial services enterprise under DORA has different sovereignty requirements than a logistics company under NIS2’s supply chain requirements.
The classification work that produces the sovereignty architecture starts from the data, not from the infrastructure. What data does this system process, and what sovereignty requirements apply to that data? The answer to that question determines the infrastructure requirement. The infrastructure decision follows the data classification, not the other way around.
The practical consequence for most European enterprises is a tiered architecture: the most sovereignty-sensitive systems on European cloud or on-premises infrastructure with genuine operational control, the less sovereignty-sensitive systems on hyperscaler infrastructure with appropriate contractual protections, and the non-sensitive systems wherever the economics are best.
This is not a novel architecture principle. The challenge is executing the classification with sufficient rigour and updating the infrastructure assignments to match the classification outcomes. Most European enterprises have done the classification imprecisely and have not updated their infrastructure assignments to reflect the sovereignty requirements their own classification would reveal.
The Vendor Landscape That European Enterprises Should Be Evaluating
The European cloud vendor landscape in 2026 is materially different from the landscape that most enterprise cloud strategies were written against. The honest assessment of European alternatives has three findings.
European cloud providers are credible for the majority of enterprise workloads at the compute and storage level. The capability gap that existed in 2020, where European providers could not provide the managed service breadth or the global reach that hyperscalers provided, has narrowed significantly for European workloads that do not require hyperscaler-specific global distribution.
The managed services gap remains the most significant gap. The deep ecosystem of AI services, analytics services, and developer tools that hyperscalers have built around their infrastructure has no European equivalent at equivalent breadth. European enterprises that are heavily dependent on hyperscaler-specific managed services face a larger migration challenge than those using IaaS or standard PaaS services.
The hybrid model that keeps sovereignty-sensitive workloads on European infrastructure while using hyperscaler managed services for the less sovereignty-sensitive AI and analytics workloads is the architecture that is emerging as the practical response. This model requires careful data flow design to ensure that the sovereignty-sensitive data does not flow into hyperscaler managed services.
The Board Conversation This Requires
The data sovereignty conversation that belongs at board level is not a technical briefing about cloud architecture. It is a strategic risk assessment: what is the organisation’s current dependency on non-European technology supply chains, what is the regulatory and geopolitical risk of that dependency, and is the board comfortable with those risks?
The board that has not had this conversation has not made a strategic decision to accept the current risk profile. It has simply not assessed it. In 2026, the regulatory environment and the board governance standards for technology risk are making that passivity harder to defend.
The CTO or CIO who brings this conversation to the board with a clear risk assessment, a recommended architecture direction, and a realistic migration pathway is providing the strategic advisory input that the board relationship requires. The one who waits for a regulatory inquiry or a geopolitical event to force the conversation will be having it in a much more difficult context.
The sovereignty architecture that is built before the external event requires it is better architecture than the one built in response to it. That has always been the case. It is more urgently true now than it has ever been.