menu

Auditing Cloud Sovereignty (English)

20 juli, 2026

Framing Risks and Decoding Vendor Claims

Authors: S.J. (Jalal) Bani Hashemi MSc RE CISSP CCSP CISA and A.J. (Ayhan) Yavuz RE

1. Introduction: geopolitical awakening

Cloud computing has matured from an efficiency-driven technology choice to being the backbone of modern digital infrastructure. For over a decade, the narrative has been dominated by agility, cost and scale. But as geopolitical tensions rise and extraterritorial regulations tighten, a critical question has surfaced: Who actually controls your data, your operations, and your AI pipelines?

This question has forced governments to reconsider the boundaries of national security and digital resilience. Demonstrating this shift, the Dutch government recently tightened its cloud policy to ensure its digital sovereignty. Governmental agencies are now required to establish a cloud strategy before they start using public cloud services. This strategy must include the rationale behind the choice of that specific cloud service, what the associated risks are, and how these will be controlled. For important cloud services, governmental agencies also must establish exit plans that outline which measures have been implemented to ensure service delivery if the cloud service becomes unavailable.

Meanwhile, the market has been flooded with "sovereign" labels. However, much of this is merely “sovereignty-washing”: superficial marketing that masks deep-seated systemic dependencies. From US extraterritorial laws like the CLOUD Act to a global hardware supply chain rooted in Asia, the reality is that "full" sovereignty is an illusion. For IT audit, risk, and security professionals, treating sovereignty as a paper-based compliance exercise only provides their principals with a false sense of security.

Building upon our previous publication, “Cloud Sovereignty: a Board Priority” (ISACA, May 2026), with this article we aim to create awareness across a broader professional audience. In this article we will expand upon our high-level framework and define concrete attention points for the IT auditor. By mapping the external risk vectors to our five-pillar framework, we provide a clear perspective for action, demonstrating exactly where to enforce controls and how to cut through superficial sovereignty-washing. We show how organizations can operate within a deeply globalized infrastructure on terms that safeguard long-term operational autonomy. Using this framework organizations can stop chasing unreachable perfection and start building verifiable operational autonomy.

Our forthcoming article will transition from the idealism of absolute isolation to deliver a more pragmatic, proactive blueprint for securing operational cloud sovereignty.

2. The landscape of systemic risk

The risks associated with cloud sovereignty extend far beyond traditional cybersecurity, centering instead on systemic dependencies and the creeping danger of losing internal knowledge and control. While many macro-level sovereignty risks have not yet fully materialized, the subjective nature of risk likelihood can shift from 0% to 100% rapidly due to fast-moving geopolitical confrontations or sudden shifts in media focus. This reality necessitates urgent board-level attention.

For the IT auditor, key risk vectors provide the foundational threat-modeling framework required to evaluate an auditee's actual exposure. Instead of accepting vendor marketing claims at face value, the IT auditor uses these vectors to stress-test whether management's risk appetite truly aligns with reality.

Key risk vectors

Key risk vectors represent the primary operational and legal domains from which digital vulnerabilities originate. Based on the principles of the EU Economic Security Strategy, but expanded to include technical auditability, the core risk vectors to manage are:

Legal weaponization: Major powers enforce extraterritorial laws (such as the US CLOUD Act or China’s National Intelligence Law) that can compel foreign-headquartered cloud providers to hand over data stored abroad, potentially overriding local privacy protections like the GDPR.
Geopolitical chokeholds and economic coercion: Cloud services can be abruptly withdrawn under sanctions or manipulated through export controls and changes in licensing terms.
Critical infrastructure concentration: Cloud platforms now underpin essential services like healthcare, finance, energy, and national security. When entire sectors depend on a handful of hyperscalers, local failures or strategic policy changes create systemic fragility and single points of failure.
Lack of AI and standards sovereignty: The rapid rise of AI introduces a new layer of dependency. This vector is explicitly prioritized in this article and treated as a distinct standalone domain, rather than being buried as a sub-component of data or technology, because AI fundamentally shifts the threat landscape from passive infrastructure risks to active decision-making risks. While data sovereignty deals with information at rest, and technology sovereignty deals with the hardware layer, AI sovereignty addresses the "algorithmic brain" of the enterprise. If core corporate AI systems rely on opaque training pipelines, un-auditable model weights, and proprietary APIs that can be unilaterally modified, drifted, or disabled by a foreign vendor, true autonomy over strategic decision-making, operational logic, and long-term automation is lost. Separating this domain allows organizations and auditors to specifically evaluate who dictates the intelligence, ethical alignment, and long-term evolutionary paths of their business processes.
Limited auditability: Hyperscalers typically provide independent assurance reports. While useful, these often lack depth regarding data replication, routing, and access, leaving regulators and internal auditors unable to verify data location guarantees.

Analysis of these key risk vectors enables the IT auditor to shift from a passive reviewer of historical data to an active validator of forward-looking digital resilience.

3. An Integrated Cloud Sovereignty framework

While the key risk vectors represent the external threats and threat origins acting upon the organization from the outside world (the "why" we must act), we cannot audit or build control frameworks on risk vectors alone, as they do not tell the internal technical and operational control domains that the organization can actually architect, govern, and audit (the "how" we defend ourselves). To assess an organization's systemic vulnerability and exposure to risk vectors detailed in previous section holistically, organizations must look past traditional, narrow technical definitions and evaluate sovereignty systematically.

When designing this internal defense, we cannot solely rely on the traditional model, which has historically been framed around three domains: data, technology, and operations. These remain essential foundations, 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.

Therefore, the integrated sovereignty framework outlined below expands the traditional model into five interdependent sovereignty pillars. The basis of this proposed model maps cleanly to the comprehensive guidelines established within the European Commission Cloud Sovereignty Framework. However, what is new about this model is its purposeful distillation and consolidation: it translates complex EU guidelines into a simplified, actionable operational model tailored specifically for technical verification and auditability. By assessing against these five pillars, organizations gain the practical implementation layers needed to build and verify real-world resilience against external risk vectors.

Note that these five pillars are not independent checkboxes but an interdependent stack:

Operational (III) + Data (I): You cannot have Data Sovereignty if foreign engineers manage the system. They have the "keys to the house".
Technology (II) + AI (V): You cannot have AI independence if you don't have transparent access to the "silicon" (GPUs) it runs on.
The Outcome: Geopolitical Sovereignty (IV) is the ultimate goal, but it is only as strong as the "floor" provided by the Supply Chain (II) and Operations (III).

The IT auditor may leverage this five-pillar framework as an empirical audit matrix to systematically evaluate the auditee’s perspective for action. By auditing each control domain methodically, the IT auditor can verify whether the internal governance and technical architectures claimed by the organization truly mitigate the external risk vectors. This prevents the audit from stalling at abstract geopolitical discussions, providing instead a structured checklist to identify exactly where technical and operational control ends and vendor dependency begins.

4. The pitfalls of “Sovereignty-washing”

Sovereignty-washing occurs when cloud providers or their clients/consumers present a deployment as sovereign when meaningful legal, operational, or control-plane independence is absent.

In the practical auditing process, the IT auditor typically encounters these pitfalls when reviewing standard, paper-based compliance packages, third-party attestations (such as generic SOC 2 or ISO reports), and procurement contracts. These documents frequently treat sovereignty as a legal checkbox rather than an engineering reality.

To bridge this gap, the IT auditor must put the previously discussed risk vectors and five pillars directly to work. By mapping the external threats (vectors) against the internal control domains (pillars), the auditor can systematically unmask sovereignty-washing, exposing the critical disconnect between a provider’s high-level marketing claims and the hidden operational dependencies that remain subject to foreign reach.

The table below maps the five sovereignty pillars to common marketing claims and the sovereignty-washing risks.

To understand why "sovereignty-washing" is so prevalent, we must look past the marketing language and examine the underlying economic and operational drivers. There are five core reasons why organizations fail to face the facts:

Complexity Ignorance: Cloud sovereignty is incredibly complex, spanning legal jurisdictions, data flows, and hardware origins. Many simply do not fully understand the depth required.
Execution Incapability: Solving it is hard. It requires re-architecting systems, which many organizations lack the will, resources or technical capability to do.
Absence of a Business Case: Sovereignty does not generate revenue. Dedicating capital and human resources to it offers no immediate commercial payback.
The EU Innovation Gap: Historically, there has been a severe lack of investment in native, cost-effective European cloud alternatives.
C-Suite Short-Termism: Corporate executives typically rotate every 4 to 5 years. They are naturally incentivized to chase quick wins rather than shoulder the heavy, long-term costs of infrastructure independence.

Consequently, many organizations ignore the problem unless a regulator or auditor forces their hand, at which point they resort to "sovereignty-washing" as a quick fix to keep overseers satisfied. And even if organizations decide to address the issue, progress is usually very slow because of the deep entanglement of their IT and business processes with cloud services.

5. The Illusion of Full Sovereignty

To break this reactive cycle, where organizations ignore structural infrastructure risks until forced by a regulator or auditor, only to deploy superficial "sovereignty-washing" as a quick fix that leaves core vulnerabilities unaddressed, management must enforce stricter, verifiable sovereignty requirements before migrating to the public cloud. However, organizations must also look past the superficial safety of paper-based agreements and be realistic about the traditional "Comply or Explain" trap:

The Compliance Trap: Attempting to fully comply with sovereignty requirements requires massive investments without yielding direct business value. Furthermore, true compliance is virtually impossible. If we peel back the layers of the modern IT stack, the hardware is overwhelmingly manufactured in Asia, the software is predominantly American, and the EU faces a chronic shortage of specialized talent to maintain it all. You can place the physical servers on EU soil, but the rest of the stack remains global.
The Explanation Trap: Choosing to "explain" non-compliance incurs both one-time and recurring costs to justify your posture, without that money actually helping you become any more independent.

As absolute compliance across the globalized IT stack is not technically feasible, the traditional approach of checking off standardized vendor compliance certificates (like generic SOC 2 or ISO reports) becomes obsolete. For the IT auditor, this means moving away from reviewing high-level legal disclaimers and instead forcing a shift toward active technical validation.

Conclusion

Transitioning to cloud sovereignty is not about absolute isolation or rejecting global cloud services. It is about using them on terms that preserve control, choice, and strategic autonomy. However, as we have explored, achieving this is fraught with deep-rooted challenges. From the globalized nature of the tech supply chain to short-term corporate incentives, these realities frequently lead organizations down the path of superficial "sovereignty-washing".

Because full sovereignty across the entire IT stack is largely an illusion in today's interconnected world, the path forward requires a shift in mindset. Instead of getting trapped in the resource-draining loop of trying to fully comply or endlessly explain non-compliance, organizations must focus on building verifiable, operational resilience where it matters most.

For the IT auditor, this means moving far beyond reviewing standard SOC2 reports and generic legal clauses. Sovereignty is an integrated challenge spanning multiple pillars, and it requires a shift from paper compliance to actual technical verification. It is necessary to ensure that an organization's digital sovereignty is not just a marketing claim, but a verifiable, functional reality. The question is no longer if sovereignty affects you, but when you need to act.

To explore how these strategic principles translate into concrete engineering and audit practices, see the companion article: "The Blueprint for Cloud Sovereignty: Implementing and Auditing the Minimum Viable Sovereign Environment (MVSE)".

Acknowledgment

The authors would like to thank Drs. Nard Janssens & Imran Nashir MSc RE CISSP for feedback and insightful suggestions, which improved the clarity and quality of this publication.

Disclaimer

An AI tool (Google's Gemini) was used in the writing of this article to assist with language and structural improvements. The content was manually reviewed and finalized by the authors.