1. Introduction
Over the past two decades, many organizations pursued global outsourcing to capture scale, lower costs, and reduce time‑to‑market. Cloud providers and offshore partners became the default path to rapid digitalization. Recently, organizations have increasingly begun asking which cloud ensures that their data, operations, and AI capabilities remain sovereign, compliant with regulations, and resilient. This is a response to several realizations:
First, major powers have expanded the use of extraterritorial laws, sanctions, export controls, and regulatory pressure to influence the behavior of companies and governments. Second, providers may suspend operations, restrict services, or alter support models in response to sanctions, diplomatic disputes, or national‑security directives. Third, dependence on a small number of global providers creates economic vulnerabilities. Export controls on advanced cloud services, restrictions on AI compute, or changes in licensing terms can have immediate and far‑reaching consequences. In addition, AI systems rely on proprietary models, opaque training pipelines, and cloud‑native APIs that providers can change unilaterally. Control over AI models increasingly determines control over decision‑making, automation, and innovation. A broader societal concern is that cloud platforms now underpin essential services: healthcare, finance, energy, transportation, public administration, and national security. Reliance on a small number of hyperscalers creates systemic single points of failure, and attacks on cloud‑managed Operational Technology (OT) can cause real‑world disruption without direct military confrontation.
Migration away from a hyperscaler, however, can be prohibitively expensive, technically complex, or politically sensitive. Over time, this dependency can erode national autonomy, limit policy flexibility, and reduce the ability to adopt alternative technologies.
In response, Europe has taken significant steps to stimulate and enforce the strengthening of digital autonomy and digital operational resilience, but sovereignty remains insufficiently covered by the available frameworks and regulations. Multiple initiatives (e.g., EU Cloud Sovereignty Framework, Digital Operational Resilience Act, NIS2, EUCS, Gaia-X) address different aspects of sovereignty (security, certification, governance, interoperability), but none provides a complete, integrated approach to managing sovereignty risks. As a result, organizations must navigate overlapping frameworks that vary in scope, intent, and enforcement. This creates uncertainty, complicates procurement, and leaves critical sovereignty risks unaddressed.
2. An integrated cloud sovereignty framework
Cloud sovereignty has traditionally been framed around three domains: data, technology, and operations. These remain essential, but they no longer capture the full spectrum of risks posed by geopolitical tensions, hyperscaler concentration, AI dependency, and extraterritorial legal reach. A modern sovereignty strategy requires a broader, more integrated model that reflects the realities of today’s digital infrastructure and the strategic pressures acting on it.
The integrated sovereignty framework outlined below expands the traditional model into five interdependent sovereignty pillars.
- Data sovereignty determines where data is stored, processed, and replicated, and which jurisdiction ultimately governs access. It ensures that sensitive information remains under the legal authority of the appropriate state and is protected from foreign interference.
- Technology sovereignty and supply-chain sovereignty focus on the trustworthiness of the hardware, software, and supply chain that underpin cloud services. Even the strongest data protections are ineffective if the systems processing that data cannot be trusted.
- Operational sovereignty ensures that organizations can operate and recover independently. This requires human-layer controls, with privileged access performed exclusively by personnel under EU jurisdiction. Furthermore, services must be designed for ‘reversibility,’ ensuring that a third party can redeploy the service without dependence on the original provider’s proprietary control plane.
- Geopolitical and economic sovereignty captures exposure to foreign political leverage, sanctions, export controls, and economic coercion. It addresses the reality that cloud providers are subject to the laws and strategic interests of their home states, regardless of where their infrastructure is located. Transparency across three specific layers is required: Jurisdiction (legal seat), Ownership (voting rights and control), and Applicable Law (susceptibility to foreign warrants like the U.S. CLOUD Act).
- AI and standards sovereignty addresses dependency on foreign AI models, proprietary APIs, and cloud‑native standards that shape long‑term digital autonomy. As AI becomes central to decision‑making and automation, control over AI systems becomes a strategic necessity.
3. A roadmap to cloud sovereignty
The sovereignty roadmap below provides a structured, phased approach that connects executive‑level intent with concrete actions across all five sovereignty pillars.
Phase 1: Sovereignty Exposure Assessment & Strategic Positioning
In this phase, a complete picture of the current position across all five sovereignty pillars is built, and the long-term sovereignty baseline is defined. These first two steps form the basis of the strategic remediation plan to close the gaps between the current position and the long-term sovereignty baseline. Each gap should be clearly classified as Remediate, Mitigate, or Accept & Monitor. Remediation plans should be prioritized by impact, exploitability, and strategic criticality, assigned to clear owners, and time‑boxed with measurable verification.
Phase 2: Governance, Policy, and Sovereignty Control Framework
In this phase, governance, policies, and decision structures are established to ensure sovereignty is consistently embedded across all five pillars. This could entail establishing a sovereignty board, setting policies and standards regarding sovereignty, defining decision-making and exception processes, and defining the control framework that should ensure compliance with the established policies and standards.
Phase 3: Sovereign Architecture, Platform Integration & Technical Enforcement
In this phase, the technical platforms are built to enforce sovereignty across all five pillars: data, technology, operations, geopolitical and economic independence, and AI and standards control. This could include deploying sovereign or EU‑compliant cloud platforms, integrating regional providers, implementing reproducible builds and verifiable provenance, designing identity, networking, and logging patterns that respect jurisdictional boundaries, implementing sovereign AI inference paths, establishing workload portability, and automating compliance monitoring.
Phase 4: Operationalization, Local Capability Building & Sovereignty Assurance
In this phase, sovereignty is embedded in daily operations. This includes operationalizing local capabilities and ensuring the organization can operate independently, even during geopolitical disruption or provider withdrawal. It also involves training local teams and establishing sovereign/local support and incident‑response models. Furthermore, it includes conducting sovereignty drills and geopolitical stress tests, validating provider claims about data location, access, routing, and AI model behavior, maintaining audit evidence, implementing sovereign DR/BCP processes, and generally ensuring operational independence from foreign jurisdictions.
Phase 5: Optimization, Continuous Adaptation
In this phase, sovereignty capabilities are continuously matured to adapt to evolving geopolitical and regulatory landscapes and to strengthen long‑term autonomy across data, technology, operations, AI, and provider ecosystems. This involves automating sovereignty‑control enforcement, validating supply‑chain integrity, and updating the sovereignty control framework in response to new regulations or geopolitical shifts. Annual maturity assessments are conducted, lifecycle transitions and cost models are managed, and long‑term autonomy is maintained through open standards and sovereign AI capabilities.
4. Role of Internal Audit
Internal Audit provides independent, risk-based assurance across the sovereignty lifecycle. Its remit spans verification of board-level decisions, validation of assessment methodologies, testing of technical and contractual controls, and reporting residual risk to board-level executives. The following matrix outlines the internal auditor’s involvement.
| Level & Time Order | Who to Engage With | Audit activities |
| Strategic – 1: Board decision and risk appetite setting | Board; CEO; CRO; CIO | Verify the reliability of the sovereignty exposure assessment, the documented end‑state and risk appetite; assess workload classification and prioritization; assess quality of the (strategic) remediation plan. |
| Tactical – 2: Policy and program design | Senior management; Legal; Procurement; Architecture leads | Validate the quality of the changes to policies/standards. Validate assessment framework (scope, methodology, evidence requirements); review procurement processes and contract templates for sovereignty clauses |
| Operational – 3: Implementation | IT operations; Security; Risk; Legal; Cloud providers | Confirm implementation of operational organization and processes; test design and operating effectiveness of technical, contractual, and operational controls; validate evidence trails and remediation plans regarding identified exceptions/deviations |
| Assurance Reporting – 4: Governance reporting and closure tracking | Board; Audit Committee; Senior management | Aggregate findings; quantify residual risk; track remediation closure and timelines. Note: Reporting can also be done separately for all individual phases. |
| Continuous Monitoring – 5: Ongoing oversight | IT / Risk / Compliance teams; External auditors | Periodic re‑assessment after geopolitical/tech shifts; verify measurement instruments map to sovereignty pillars |
It is important to note that there is a “Sovereignty Washing” Risk. This describes the tendency of stakeholders to present a cloud deployment as “sovereign” even when meaningful legal, operational, or control‑plane independence is absent. This dynamic is driven by strong incentives to preserve the status quo: switching away from dominant hyperscalers or re‑architecting workloads requires significant time, cost, and specialist skills, and the immediate financial upside is often unclear. As a result, organizations may accept surface‑level assurances, while remaining exposed to extraterritorial laws, hidden subprocessors, or control‑plane dependencies that undermine true autonomy. Internal auditors should treat sovereignty claims as assertions to be tested, not facts to be accepted.
Acknowledgment
The authors would like to thank Imran Nashir MSc RE CISSP for feedback and insightful suggestions, which improved the clarity and quality of this publication.
Disclaimer
The authors alone are responsible for the views expressed in this article and they do not necessarily represent the views, decisions or policies of the ISACA NL Chapter. The views expressed herein can in no way be taken to reflect the official opinion of the board of ISACA NL Chapter. All reasonable precautions have been taken by the authors to verify the information contained in this publication. However, the published material is being distributed without warranty of any kind, either expressed or implied. The responsibility for the interpretation and use of the material lies with the reader. In no event shall the authors or the board of ISACA NL Chapter be liable for damages arising from its use.
