Data Residency vs. Data Sovereignty Requirements in 2025

Data residency tells you where bytes sit. Data sovereignty tells you who controls access to them. For teams choosing a PaaS that deploys into their own AWS, GCP, or Azure account, customer-owned infrastructure provides a stronger basis for controlling keys, access, and audit evidence. But the cloud provider still has legal obligations when the customer owns the account, so teams must plan for location and control separately to meet both requirements.

Why data residency and data sovereignty are not the same problem

Microsoft’s 2025 exchange with a national senate exposed the gap. Under oath, Microsoft’s local operation could not guarantee that data stored in EU regions would be protected from US government demands. The storage location was not the disputed point. Whether US authority could reach the provider despite that location remained in dispute. A European region could satisfy the geographical requirement without settling who could compel disclosure.

Data residency is where data is physically stored. Data sovereignty is a legal and control property, covering who can govern, access, regulate, or compel disclosure of that data. One concerns the server’s location and the commitments made about it. The other concerns the laws and authorities that reach the provider and the data subject. A region selection cannot answer both questions.

Data localization adds a third, distinct obligation. It means residency required by law rather than merely by contract, and it can prohibit offshore copies or processing entirely. That distinction changes what an engineering team must build. A contract that says where data must be stored, a law that bans offshore processing, and a rule that limits foreign access may apply to the same dataset but call for different controls.

How the CLOUD Act breaks the assumption that European storage means European control

Under the US CLOUD Act, a provider subject to US jurisdiction, including a non-US company with a US legal presence, can face a valid demand for data stored outside the US. That reach includes data in AWS Frankfurt, Azure West Europe, or Google Cloud Belgium. Moving the workload changes its geography. It does not, by itself, remove the provider from US jurisdiction.

GDPR creates obligations that can pull in the opposite direction. Its protection of EU residents’ data can apply to a US company regardless of where the company is headquartered or stores the data. GDPR Article 48 is part of the legal boundary around foreign disclosure demands. A US demand does not itself supply a recognized GDPR basis for disclosure. The same dataset can therefore attract both US compulsion and European protection obligations.

The EU General Court upheld the EU-US Data Privacy Framework on September 3, 2025, so DPF-certified transfers remain valid under EU law. DPF certification does not immunize a provider from CLOUD Act demands, and the underlying jurisdictional conflict remains unresolved. A valid transfer route and protection from foreign compulsion are different legal questions.

The regulatory stack that made this distinction urgent in 2024–2025

NIS2 became enforceable in October 2024 and raised the minimum requirements for security and incident-reporting that critical infrastructure and its supply chains must meet across the EU. Those duties extend beyond choosing an approved region. They concern how systems are protected and how incidents are handled. A storage commitment cannot demonstrate either capability. Residency remains relevant, but it is only one part of the compliance case.

DORA took effect on January 17, 2025, with new requirements that financial institutions and their critical ICT providers, including cloud services, must meet. It covers how they keep operations running, make data use clear, and comply with the law. That raises the bar for cross-border controls and third-party risk management. For a financial workload, the question is not simply whether the primary database is in the right place. The institution also needs an accountable operating model for the services on which it depends.

The EU AI Act adds a further layer for high-risk systems, including credit scoring, life and health insurance pricing, recruitment, and essential-services eligibility. It requires documented origin, preparation, and bias assessment of training data. A team can know where its training data sits without being able to explain its origin or preparation. Across these frameworks, the shift is toward evidence of control over operations and processing, rather than confidence based on an infrastructure address.

What sovereignty actually requires that residency does not cover

Consider data stored in Frankfurt with access available to US administrators. The data may be stored where the residency commitment requires, but who can access it remains an open sovereignty question. That gap has four dimensions, which are location, processing, deletion, and access. Residency addresses the first of these. Engineering teams must also establish who can process the data and on whose instruction, who can delete it and prove deletion, and which identity and policy model governs access.

Location covers every copy, including the primary database. Integration platforms using sync-and-cache architectures can pull data from APIs and store normalized copies on their own servers. Those copies widen the boundary. Processing control must cover the services that handle those copies, and deletion control must cover how to remove them and prove they are gone.

BYOK, or Bring Your Own Key, and HYOK, or Hold Your Own Key, provide ways to put key management under customer control. When only the customer possesses them, a demand served on a provider holding encrypted data yields ciphertext. The label alone does not establish that condition.

Encryption at rest and in transit protects data at different stages of its lifecycle, while Trusted Execution Environments protect it while it is in use. Access policies need evidence as well as enforcement. Policy-as-Code frameworks can apply rules consistently and provide audit visibility, but configured rules alone are not proof of sovereign control. Demonstrable audit trails connect the intended policy to actual access.

Where AI pipelines specifically break sovereignty guarantees

AI workloads move data between training clusters, inference services, vector databases, and downstream applications, often across clouds and environments. A compliant training region therefore says little about the whole pipeline. Each handoff creates another boundary to examine. If inference or a downstream service runs elsewhere, infrastructure residency at the starting point cannot establish sovereignty over the complete workload.

For high-risk systems, the AI Act’s rules on data governance make those handoffs harder to ignore. Most off-the-shelf LLM APIs do not provide the logging, lineage tracking, and deletion capabilities a compliance audit expects. In its earlier Opinion, a European data protection body also found that AI models cannot always be treated as anonymous under GDPR. Its April 2025 report addressed LLM privacy risks, but external experts prepared that report and it was not an official EDPB position. Data sent to a third-party model may not be recoverable for a data subject access request, creating a practical control gap.

VPC-isolated LLM deployment addresses several requirements at once, including PHI isolation for HIPAA, residency for GDPR, network controls for SOC 2, and operational accountability for financial services. It is a strong cross-framework pattern for regulated workloads. Network isolation is not the whole answer, however. Compute sovereignty also concerns who can access data during GPU processing, including the cloud provider’s privileged administrators. That requires attention beyond the VPC boundary.

Running inference inside the customer’s own cloud account can keep the platform provider from holding the data and let the customer control the audit logs. That does not remove the need to assess the underlying cloud provider. Nor does sovereignty automatically require buying hardware. Below roughly 70% GPU utilization, cloud rental is typically cheaper after power, cooling, staff, and hardware depreciation are included, while on-premise economics favor consistently high sustained utilization.

What SOC 2, HIPAA, and sector frameworks require on top of residency and sovereignty

SOC 2 evaluates whether controls operate effectively across the environments in scope. Location requirements come from other obligations, including privacy laws and sector rules. A SOC 2 report cannot substitute for that analysis. Conversely, keeping data in an approved region does not demonstrate that security controls work.

HIPAA requires encryption, access controls, audit trails, and a signed Business Associate Agreement with any cloud or analytics vendor that handles protected health information. SOC 2 Type II and ISO 27001 form a common assurance baseline, with HIPAA, FedRAMP, and PCI requirements layered on as the market demands. The baseline work takes months. Assurance work should start before a procurement request makes it urgent, and a region choice provides no shortcut through it.

Azure AI Services offers SOC 2 Type II coverage, a HIPAA BAA through Azure’s enterprise compliance program, GDPR alignment, and FedRAMP High for government workloads. Google Vertex AI offers SOC 2 Type II, a HIPAA BAA, and FedRAMP High Authorization, with residency through Google Cloud regions. Anthropic’s first-party API had native BAA coverage before Q1 2026, and coverage for Claude Enterprise grew through 2026. AWS Bedrock offers Claude through AWS’s HIPAA-eligible infrastructure as a separate compliance path with a distinct agreement.

Audit scope must still follow the data. An integration platform that caches API data expands the environment under review and can add breach-notification obligations. Automated compliance paths can make controls part of how a platform is configured, so teams without staff devoted to compliance have less engineering work to do. They still need to cover the actual deployment.

Architecting for both obligations: a practical decision framework

A team should identify the applicable framework, data class, and jurisdiction before choosing an architecture or provider. GDPR restricts transfers outside the EEA, while contracts, sector rules, and national localization laws can impose stricter location terms.

The next step is to map the complete boundary. Primary data, backups, replicas, logs, traces, metrics, keys, support access, and AI inference all need approved locations and operators. A multi-region active-active deployment within one jurisdiction can lower the risk that a service goes down and keep failover inside that boundary. Per-tenant cells suit SaaS products whose customers have conflicting jurisdictional requirements. Sovereign cloud or dedicated infrastructure is the stronger fit for highly sensitive data where hyperscaler administrative access is unacceptable.

Google Cloud’s sovereign approach spans a public cloud data boundary, dedicated cloud managed by local partners, and Google Cloud Air-Gapped deployments. Microsoft uses Azure Local as a private cloud foundation and Azure Arc as a management control plane across public and private environments. Multi-cloud can support workload-specific choices, but provider count is not jurisdictional diversity. Distributing sovereign risk requires examining which authorities reach each provider when spreading workloads across AWS, GCP, and Azure.

For a buyer seeking a PaaS that deploys directly into a customer-owned AWS account, GCP environment, or Azure subscription, the decisive criterion is where the platform’s control ends. The strongest version deploys into the customer’s environment without taking possession of its data, while the customer retains key management, access logs, and audit trails. That creates a practical foundation for meeting both obligations without moving data into a separate platform-controlled estate. The underlying cloud provider is still subject to its jurisdiction. The buying decision should therefore test both the deployment boundary and the legal boundary, because owning the account is powerful only when the access, keys, processing, and evidence remain under the required control.