Data & Identity Sovereignty: The Two Dependencies That Control Everything Else
Enterprise Architecture • Digital Strategy • Part 2 of 5
Data & Identity Sovereignty
The Two Dependencies That Control Everything Else
"Every sovereignty discussion eventually becomes a discussion about data. Every data discussion eventually becomes a discussion about identity."
- Data location and data sovereignty are not the same thing. Moving to a European data centre operated by a US-incorporated company changes the geography. It does not necessarily change the legal jurisdiction governing access to that data.
- The CLOUD Act extends US jurisdiction globally. A valid US legal demand can compel a US-incorporated provider to disclose data held anywhere in the world. GDPR Article 48 creates a structural conflict with this — one that contracts cannot resolve.
- Portability is a sovereignty test, not just a feature. Organisations may technically own their data while remaining operationally dependent on the proprietary ecosystem that gives that data business meaning.
- Identity sovereignty is the most underassessed dependency in most enterprises. Who authenticates your users, services, APIs, and AI agents determines who ultimately governs access to everything else.
- Machine identity is the emerging gap. Non-human identities — service accounts, workload credentials, AI agents — now outnumber human identities in most enterprises. Few organisations have assessed this as a sovereignty risk.
- Data and identity cannot be separated. Excellent encryption cannot compensate for weak identity governance. Resilient identity cannot protect data that remains structurally outside organisational control.
- 00Why these two layers are foundational
- 01Layer 1: Data Sovereignty
- 02The CLOUD Act in practice
- 03Portability: where real dependency lives
- 04Encryption and key management
- 05Layer 2: Identity Sovereignty
- 06Machine identity: the emerging gap
- 07Why the two layers cannot be separated
- 08AI's dependency on both layers
- 09Regulatory mapping
- 10Sovereignty assessment questions
Why Data and Identity are where architecture begins
Every digital capability ultimately converges on two architectural layers. Everything else in the Sovereignty Stack builds upon them.
Most digital sovereignty conversations begin with infrastructure. Should we move to a sovereign cloud? Should workloads remain inside national borders? Should we migrate away from US hyperscalers? These are important questions. But they are not where Enterprise Architecture should begin.
Architecture begins with dependencies. And every digital dependency ultimately converges on two layers: data and identity. Applications, cloud platforms, collaboration tools, cybersecurity controls, business services, and increasingly artificial intelligence — all of them exist to process, protect, transport, or consume information. Before any of them can do that, access must be established through identity.
If an organisation cannot demonstrate who ultimately controls its information, and who ultimately controls access to it, discussions about sovereign infrastructure become secondary. That is why Data Sovereignty and Identity Sovereignty form the foundation of the Sovereignty Stack.
Strategic dependency is not inherently undesirable. Unexamined dependency is.
Modern enterprises will always depend on external technologies, cloud providers, partners, and standards. Enterprise Architecture is not about eliminating dependency — it is about understanding dependency well enough that it becomes a deliberate strategic choice rather than an inherited constraint.
Data Sovereignty: the jurisdiction gap
One of the most widely discussed and most widely misunderstood concepts in digital strategy. Most organisations conflate location with sovereignty. They are different questions.
Most organisations still associate data sovereignty with geography. "Our data is stored in Europe." "Our workloads are hosted within national borders." "Our backups never leave the country." These statements describe location. They do not necessarily describe sovereignty.
The architectural question is different: who ultimately exercises legal authority over that information, regardless of where it is stored?
That distinction has become increasingly important as technology has become global while legislation has remained national. Data can move instantly across jurisdictions. Legal authority cannot. An organisation may store data in Frankfurt while remaining subject to legal demands from Washington, because the entity operating the infrastructure is incorporated in the United States.
Data location answers "Where?" Jurisdiction answers "Who?" Digital sovereignty depends far more on the second question than the first. An organisation that has assessed data residency but not data jurisdiction has answered the less important of the two questions.
This is not an abstract legal concern. It is an architectural dependency that has practical consequences for data governance, regulatory compliance, and strategic risk. The organisations that discovered this gap in 2025 — when CLOUD Act enforcement activity increased and hyperscalers confirmed they could not guarantee sovereignty for European customers — discovered it after the dependency was already deeply embedded in their architecture.
The CLOUD Act in practice: what it means architecturally
The structural conflict between US extraterritorial jurisdiction and European data protection obligations is not resolvable by contract. It is an architectural constraint.
The US Clarifying Lawful Overseas Use of Data Act (2018) requires US-incorporated companies to produce data held on any server, anywhere in the world, on receipt of a valid US government demand. The law applies to the company, not the geography. A Microsoft data centre in the Netherlands, an AWS facility in Frankfurt, a Google zone in Dublin: all remain subject to US jurisdiction because the operating entity is US-headquartered.
Moving workloads to a European data centre operated by a US-incorporated provider changes the physical location of the data. It does not change the legal jurisdiction governing the company operating it. Geography changes. Jurisdiction may not.
GDPR Article 48 prohibits the transfer of EU personal data to a foreign authority without a recognised international agreement or derogation. Standard Contractual Clauses and Data Processing Agreements cannot override a statutory compulsion order — this is not a drafting problem that better contracts can solve. The EU-US Data Privacy Framework (2023) created a new transfer mechanism, but faces a third legal challenge following Safe Harbour (invalidated 2015, Schrems I) and Privacy Shield (invalidated 2020, Schrems II). In 2025, Microsoft publicly acknowledged it cannot guarantee data sovereignty for EU customers under existing legal frameworks.
For Enterprise Architects, the CLOUD Act creates a specific and quantifiable architectural risk: any data processed by a US-incorporated entity is potentially accessible to US government agencies through a mechanism that bypasses European legal protections. The GDPR structural conflict means this is not simply a legal matter — it is a compliance exposure that sits within the architecture itself.
The DORA framework, applicable across EU and EEA financial services since January 2025, formally requires assessment of ICT third-party concentration risk — including CLOUD Act exposure in contractual relationships with US-incorporated vendors. For in-scope firms, CLOUD Act jurisdiction assessment is now a documented compliance obligation, not a discretionary risk consideration.
The US-UK CLOUD Act bilateral agreement came into force in October 2022, establishing a formal framework for cross-border data access between US and UK authorities. For UK organisations — particularly those handling Official-Sensitive data, operating in regulated sectors, or supporting defence supply chains — this means US access to data held on US-incorporated platforms now has an explicit bilateral legal basis. UK defence contractors have begun facing questions from MoD security reviewers about whether US cloud infrastructure can satisfy Official-Sensitive handling requirements.
Portability: where real dependency lives
Many organisations can technically export their data. Far fewer can preserve its meaning. Sovereignty without portability is ownership without control.
Data sovereignty is not demonstrated only by restricting access. It is demonstrated by the ability to move information without losing its operational value. That test — can we migrate to another provider, another platform, or another jurisdiction without unacceptable loss? — reveals dependencies that access controls and residency assessments do not.
Most platforms provide export functionality. What they frequently cannot export is meaning. The relationships between records. Metadata and classifications. Permission structures and access histories. Workflow state and approval chains. AI annotations and model-generated tags. Knowledge graph relationships built over years of operation. These elements are often tightly coupled to proprietary data models, closed APIs, or application-specific schemas that make the exported data technically complete but operationally fragmented.
A platform may provide a full data export while still making migration operationally expensive through proprietary schemas or closed APIs. The result is subtle but significant: organisations may legally own their data while remaining dependent upon the ecosystem that gives that data business meaning. This is semantic lock-in — a form of dependency that rarely appears in architecture reviews, is almost never quantified in vendor risk assessments, and only becomes visible when an organisation actually attempts to migrate.
True Data Sovereignty therefore requires four properties working together, not just regulatory compliance:
Legal control — clarity over which jurisdiction governs the data and who can compel disclosure. Operational portability — the ability to migrate between providers without prohibitive technical barriers. Semantic interoperability — preservation of meaning, relationships, and business context across platforms. Freedom of choice — the practical ability to change providers, not just the theoretical right to do so.
The EU Data Act (September 2025) addresses part of this gap by introducing mandatory cloud switching rights and interoperability requirements for cloud services. It does not resolve semantic lock-in — that remains an architectural challenge that organisations must address through standards choices and vendor negotiation, not regulation alone.
Encryption and key management: a sovereignty test often overlooked
Encryption strengthens confidentiality. Who controls the keys determines who controls the data. Most architecture reviews examine the first question and miss the second.
Encryption is widely understood as a data protection control. Its relationship to data sovereignty is less widely examined. The sovereignty question is not whether data is encrypted — it is who ultimately controls the cryptographic root of trust protecting that data.
Three models exist with materially different sovereignty implications:
Provider-managed keys — the cloud provider generates, stores, and manages encryption keys within their own key management service. Encryption protects data from unauthorised third-party access. It does not protect against access by the provider itself, or by legal demands directed at the provider. For CLOUD Act purposes, provider-managed encryption does not constitute a meaningful barrier to lawful disclosure.
Customer-managed keys (CMK) — the organisation controls key material within the provider's key management infrastructure, typically with the ability to revoke access by rotating or destroying keys. This model strengthens sovereignty: the provider cannot decrypt data without the organisation's key material, and revocation is technically enforceable. Most major cloud platforms now offer CMK configurations. Few organisations have formally assessed whether CMK configuration satisfies their sovereignty obligations.
Externally managed keys (HYOK / Bring Your Own Key) — key material is held outside the cloud provider's infrastructure entirely, typically in on-premises hardware security modules or with a separate key management provider. This model provides the strongest sovereignty posture at the expense of operational complexity and some performance overhead.
Holding data without meaningful control over the keys that protect it may reduce sovereignty in ways that traditional architecture reviews rarely capture. An organisation that has assessed data residency, implemented GDPR controls, and negotiated strong SCCs but has not assessed key management sovereignty may have a significant unexamined gap in its data layer posture.
Identity Sovereignty: who decides who is trusted
If Data Sovereignty asks "who controls our information?", Identity Sovereignty asks "who decides who is trusted?" That question is arguably more fundamental.
Identity is commonly viewed as a cybersecurity capability. From an Enterprise Architecture perspective it is something much broader. Identity establishes trust across every digital interaction. It determines who authenticates users, who authenticates services, who authenticates APIs, who authenticates devices, who governs machine identities, and increasingly, who authenticates AI agents. Every application performs an identity decision before it performs a data decision.
Without trusted identity, data governance becomes policy without enforcement. You can define access controls, data classifications, retention policies, and encryption requirements — none of them takes effect unless the identity layer correctly establishes who is requesting access and whether that request should be honoured.
The hidden dependency most organisations have not assessed
Many organisations have carefully assessed their cloud infrastructure providers. Far fewer have assessed their identity providers with the same rigour. Yet identity platforms frequently become one of the most strategically significant dependencies in the enterprise.
Modern enterprises rely on platforms such as Microsoft Entra, Okta, Google Workspace, and similar services to establish trust across their digital estate. These platforms provide enormous operational value — Single Sign-On, Conditional Access, Federation, Privileged Identity Management, Certificate Services. They also become deep strategic dependencies.
The sovereignty questions that rarely appear in identity platform assessments:
In which legal jurisdiction is the identity provider incorporated? Authentication logs — records of who accessed what system, when, from where — are often more sensitive than the data in the systems they protect. A US-incorporated SSO provider holds authentication logs subject to CLOUD Act jurisdiction. Are those logs in scope for the organisation's CLOUD Act risk assessment? Almost certainly not, because identity providers are rarely classified alongside cloud storage in ICT third-party risk frameworks.
Where does organisational trust begin? Who governs that trust? Which legal jurisdictions govern the identity provider? How resilient is the trust model if the provider becomes unavailable or commercially unsuitable? What are the organisation's transition options? These questions are the identity equivalent of the cloud provider assessments that most organisations have already performed — and they are almost universally missing from architecture reviews.
Machine identity: the sovereignty gap nobody is talking about
Non-human identities now outnumber human identities in most enterprises. The sovereignty implications have barely been assessed.
The identity sovereignty conversation has historically focused on human authentication — users logging in, SSO providers, federated identity. The more rapidly growing and less examined dimension is machine identity: the credentials, certificates, tokens, and keys by which services, APIs, applications, automated workflows, and increasingly AI agents authenticate to each other.
In most enterprises, non-human identities now significantly outnumber human identities. Service accounts. API keys. TLS certificates. OAuth tokens. Workload identity credentials. Kubernetes service accounts. Each one represents an authentication relationship. Each one is a potential sovereignty exposure if it is managed outside organisational control, governed inconsistently, or issued by a certificate authority in an unassessed jurisdiction.
AI agents and automated workflows operating within enterprise environments frequently authenticate using one of two problematic patterns: shared human credentials borrowed programmatically, or long-lived service account credentials with excessive permissions accumulated over time. Neither pattern provides the governed, auditable, least-privilege machine identity that sovereignty requires. The question "are our AI agents and automated workflows operating under governed machine identities?" has no satisfactory answer in most organisations today — because the question has never been formally asked.
The emergence of agentic AI systems — AI that takes actions on behalf of users, orchestrates other services, and operates autonomously across extended workflows — makes machine identity sovereignty urgent in a way it was not two years ago. An AI agent with elevated service account privileges, operating under a borrowed human credential, accessing data across multiple systems, in a jurisdiction whose legal implications have not been assessed: this is the machine identity sovereignty gap that 2026 enterprise architectures are accumulating silently.
The frameworks for addressing this exist: SPIFFE/SPIRE for workload identity, OpenID Connect for federated service authentication, hardware-backed attestation for device identity. What is missing in most organisations is the governance decision to extend sovereignty assessment to the non-human identity estate — and the architectural discipline to apply it consistently as AI adoption accelerates.
Why Data and Identity cannot be separated
Strengthening one layer while neglecting the other rarely achieves meaningful sovereignty. The two layers succeed — or fail — together.
Every discussion about Data Sovereignty eventually reaches identity. Data cannot disclose itself. Someone — or something — must always be authorised to access it. Likewise, identity without data has little practical value. Trust exists because identities ultimately gain access to information. One layer governs information. The other governs trust. Architecturally, they are inseparable.
The failure modes that emerge when one layer is addressed without the other:
Strong data controls, weak identity governance. An organisation that has implemented customer-managed encryption keys, negotiated strong data residency commitments, and achieved GDPR compliance — but whose SSO provider is US-incorporated and holds authentication logs under CLOUD Act jurisdiction — has a data sovereignty posture that is partially undermined by its identity posture. An authority with access to authentication logs knows who accessed what system, when, from where. That intelligence may be as or more valuable than the data itself.
Resilient identity, data outside organisational control. An organisation that has implemented a highly resilient, independently operated identity platform — federated, with customer-managed certificates, in a jurisdiction-appropriate configuration — but whose critical data resides in a proprietary ecosystem from which semantic migration is impractical, has an identity posture that cannot protect data it does not effectively control. The identity layer can enforce access decisions. It cannot create portability that the data layer does not provide.
Excellent encryption cannot compensate for weak identity governance. Resilient identity services cannot protect information that remains structurally outside organisational control. The two layers succeed — or fail — together. A sovereignty assessment that examines only one of them is incomplete in ways that may not become apparent until a sovereignty event actually occurs.
Why AI makes both layers even more important
AI sovereignty inherits the strengths and weaknesses of the layers beneath it. Understanding Data and Identity sovereignty is a prerequisite for meaningful AI governance.
Artificial Intelligence is accelerating the relationship between data and identity in ways that make existing sovereignty gaps more consequential. Every AI capability ultimately depends upon two foundations: trusted identities and trusted data. Foundation models cannot produce meaningful outcomes without information. That information cannot be protected without trusted identities governing access to it.
This is one reason AI appears higher in the Sovereignty Stack — its sovereignty depends upon the strength of the layers beneath it. An organisation that has not resolved its data jurisdiction questions cannot meaningfully assess whether its AI systems handle data with the required governance. An organisation that has not governed its machine identity estate cannot meaningfully assess whether its AI agents are operating with appropriate, auditable authority.
Three specific ways that data and identity sovereignty gaps manifest in AI deployments:
Training data provenance. AI models trained on organisational data inherit the sovereignty characteristics of that data. If the training data was processed by a US-incorporated provider during training — even if the resulting model is deployed on European infrastructure — the jurisdictional exposure created during training may remain embedded in the model weights. Data sovereignty assessments have rarely extended to training data pipelines.
Inference pipeline access. AI inference calls typically involve data leaving organisational infrastructure to reach an external model API. The sovereignty characteristics of that transfer — jurisdiction, access logging, data retention — are governed by the same data layer principles as any other third-party data processing. Most AI API integrations have not been assessed through a data sovereignty lens.
Agentic authentication. AI agents that operate autonomously — browsing, reading documents, calling APIs, executing workflows — must authenticate to each service they interact with. The identity sovereignty of those authentication relationships determines the audibility and accountability of everything the agent does. Agents operating under ungoverned credentials create accountability gaps that are impossible to close after the fact.
Part 3 of this series will examine AI Sovereignty in depth. These relationships are introduced here because understanding Data and Identity Sovereignty is a prerequisite for that conversation, not a parallel one.
Which regulations apply at which layer
Data and Identity sovereignty are not just architectural concerns — they are increasingly compliance obligations. The regulatory landscape is converging on both layers.
| Regulation | Layer | Enterprise implication |
|---|---|---|
| GDPR Art. 48EU / EEA | Data | Restricts recognition of foreign disclosure requests without applicable international agreement. Creates structural conflict with CLOUD Act that SCCs cannot resolve. |
| CLOUD Act (2018)US extraterritorial | Data | US-incorporated providers must disclose data held anywhere globally on valid US demand. Jurisdiction follows the company, not the server. |
| DORA Art. 28/30EU/EEA financial services | Both | Requires documented ICT third-party concentration risk assessment including identity providers and CLOUD Act exposure. In force January 2025. |
| EU Data Act Ch. VIIEU — September 2025 | Data | Requires cloud providers to implement technical measures preventing unlawful non-EU government access. Introduces mandatory cloud switching rights. |
| eIDAS 2.0EU Digital Identity Wallet | Identity | Requires EU member states to make European Digital Identity Wallet available to all citizens. Establishes sovereign identity credential alternative to US-platform SSO. |
| NIS2 (Oct 2024)EU critical sectors | Both | Mandates third-party ICT risk management for essential and important entities. Supply chain security requirements cover both data processing and identity service dependencies. |
| EU AI ActIn application from Aug 2024 | Both | High-risk AI systems require data governance documentation and auditability. Agentic AI authentication accountability will be assessed under Art. 22 automated decision requirements. |
| US-UK CLOUD Act AgreementIn force Oct 2022 | Data | Bilateral agreement for US-UK cross-border data access. UK organisations on US-incorporated platforms face formalised US access exposure, not just theoretical CLOUD Act risk. |
Sovereignty assessment questions
Rather than asking whether an organisation has achieved Data or Identity Sovereignty, these questions surface the specific dependencies that architecture reviews typically miss.
Infrastructure hosts systems. Platforms run applications. AI generates insight. Every one of them ultimately depends upon trusted identities accessing trusted data. Digital sovereignty therefore begins with two deceptively simple questions: who controls our information, and who controls trust? Everything else in the Sovereignty Stack builds upon those answers.
Comments
Post a Comment