Data Residency complete

• Cloud accounts created with default region settings (commonly us-east-1 or similar).
• No distinction made between data categories (personal data, metadata, backups) in terms of storage location.
• IT and legal teams have not discussed data residency requirements.
• Vendor contracts are signed without reviewing data processing locations.

• Regulatory exposure: GDPR Chapter V prohibits transfers to third countries without an adequacy decision or appropriate safeguards. Operating without awareness means no lawful basis can be demonstrated.
• CLOUD Act reach: If the provider is a US-headquartered company, US authorities may compel disclosure under the CLOUD Act regardless of the data's physical location.
• nDSG non-compliance: The revised Swiss Federal Act on Data Protection requires assessment before cross-border disclosure; without a location inventory this assessment is impossible.

At Level 0, the organisation has no sovereignty over data location. It cannot demonstrate where data resides, cannot assess jurisdictional exposure, and has ceded all location decisions to providers. Data may cross borders without the organisation's knowledge, making it impossible to evaluate regulatory compliance or respond to jurisdictional challenges.

• Cloud provider dashboards have been reviewed to identify default regions (e.g., AWS eu-west-1, Azure West Europe).
• The provider's standard terms of service govern data location; no custom DPA or region-restriction addendum is in place.
• Backup and disaster-recovery replication targets are set by the provider and may include regions outside Europe.
• Internal stakeholders are aware of the issue but treat it as low priority.

• Silent region changes: Providers may update their infrastructure, adding new replication targets or migrating services, without explicit notification.
• Inadequate transfer basis: Awareness without SCCs or an adequacy decision does not constitute a lawful transfer mechanism under GDPR art-46.
• Schrems II implications: Following the CJEU's Schrems II ruling, reliance on Privacy Shield is invalid and SCCs require supplementary measures when transferring to jurisdictions without adequate protections.
• Metadata leakage: Even if primary data remains in the EU, metadata, logs, and analytics data may be processed in other regions by default.

The organisation is aware of where its data resides but has no mechanism to influence or control location decisions. Sovereignty exists only as knowledge - the provider retains full discretion over where data is stored, replicated, and failed over. The absence of contractual or technical controls means the organisation cannot prevent or even detect location changes.

• DPAs with all critical cloud providers include region-restriction clauses specifying EU/EEA or Swiss data centres.
• Transfer impact assessments have been conducted for each provider, evaluating the legal framework in the provider's home jurisdiction.
• SCCs follow the EU 2021/914 standard with appropriate modules and supplementary measures documented.
• The organisation is aware that ancillary data (metadata, support interactions, telemetry) may still be processed outside contracted regions.
• Compliance is verified through contract review rather than technical monitoring.

• Contractual vs. technical reality: A DPA specifying EU residency does not technically prevent a provider from processing data elsewhere. Without monitoring, breaches go undetected.
• Metadata gap: Many providers exclude metadata, CDN logs, DNS queries, and support-ticket content from region-restriction commitments. AI features add a further metadata layer: prompt preview caches, model-routing telemetry, and abuse-monitoring buffers often live with the model provider rather than the SaaS vendor, and DPAs frequently keep them outside the residency clause by default. The AI inference region itself is a separate residency question from primary data storage and needs a separate contractual line.
• CLOUD Act override: US-headquartered providers remain subject to compelled disclosure under the CLOUD Act regardless of contractual commitments. The conflict between GDPR and CLOUD Act creates legal uncertainty.
• Schrems II evolution: Regulatory guidance on supplementary measures continues to evolve; TIAs require regular updates to remain valid.
• Transfer-mechanism fragility: The DPA is only as durable as the legal instrument that authorises the transfer. SCCs can be tightened, the EU-US Data Privacy Framework is a plausible Schrems III target, and adequacy decisions can be withdrawn. Naming the mechanism per provider and rehearsing an invalidation contingency is a Level 2 expectation, not a Level 3 luxury.

Even with strong primary-provider DPAs, sub-processors may store or process data in different regions. The organisation should maintain a sub-processor register and verify that sub-processor DPAs include equivalent region restrictions.

Sovereignty at Level 2 is contractual rather than technical. The organisation has legal rights to data residency commitments and can hold providers accountable through DPAs and SCCs. However, it cannot independently verify that data remains within contracted regions. Provider changes, metadata processing outside agreed boundaries, and CLOUD Act exposure represent gaps that contracts alone cannot close.

• Cloud infrastructure is configured with explicit region constraints - resources cannot be provisioned outside approved regions.
• Infrastructure-as-code policies (e.g., Azure Policy, AWS Service Control Policies, GCP Organisation Policies) enforce region restrictions at the organisation level.
• Data replication for high availability and disaster recovery is restricted to data centres within the EU/EEA or Switzerland.
• Network monitoring and SIEM rules detect cross-border data flows and generate alerts.
• Annual audits (internal or third-party) validate data residency controls and produce formal reports.
• AI feature inference is technically confined to approved regions through vendor data-boundary participation (e.g. EU Data Boundary for Microsoft 365 and Copilot) or regional model-endpoint pinning (e.g. Azure OpenAI in an EU region with regional endpoint enforcement). The control is configured at tenant level and re-verified through tenant-scoped logs, not through a generic vendor claim that EU inference is available.

At this level, the organisation typically defines formal "data sovereignty zones" - logical groupings of approved regions where different data classifications may reside. For example:

• Zone A (Swiss): Data centres in Zurich and Geneva for the most sensitive data.
• Zone B (EU/EEA): Data centres in Frankfurt, Amsterdam, or Paris for general EU personal data.
• Zone C (Restricted): No data may be stored or processed; any flow to these regions triggers an incident.

• Provider-attested vs independently verifiable. Provider compliance reports (SOC 2 Type II, ISO 27001) confirm the provider's residency control framework. They do not independently confirm that residency held for a specific customer tenant. The organisation's own verification (region-tagged inventory, geo-IP confirmation, exercised audit rights) closes part of this gap, but cannot reach data flows outside its view. True independent verification of residency for the tenant only emerges at Level 4.
• Provider-level access. Even with geo-fencing, the cloud provider's global administrative infrastructure may allow employees in non-approved jurisdictions to access data for support or maintenance purposes.
• CLOUD Act. US-headquartered providers (AWS, Azure, GCP) remain subject to compelled disclosure regardless of where data is physically stored. Geo-fencing is a technical control, not a legal shield.
• Hardware-level trust. The organisation trusts the provider's physical security and hardware integrity without independent verification.

Level 3 is appropriate for organisations that need verifiable data residency enforcement rather than contractual assurance alone. This includes organisations processing personal data at scale under GDPR or nDSG, those whose regulators or auditors require evidence of technical controls, and those operating in sectors where contractual guarantees have proven insufficient following provider infrastructure changes.

If the organisation's risk profile allows contractual protections at Level 2 to be proportionate, the additional operational cost of geo-fencing, monitoring infrastructure, and regular audits may not be justified. Smaller organisations that can demonstrate compliance through contracts and transfer impact assessments may find Level 2 sufficient until regulatory expectations evolve.

Sovereignty at Level 3 is technically enforced and partially verifiable. The organisation can confirm, through provider attestation paired with its own monitoring and inventory evidence, that residency controls held for the tenant within the scope of those views. What it cannot independently confirm is what the provider did with data outside that view: support sessions across regions, internal data flows for resilience or capacity, or compelled access. The provider's global administrative infrastructure and CLOUD Act exposure (for US-headquartered providers) remain residual gaps that technical controls combined with provider-attested audits cannot fully close. Level 4 closes them by removing the dependency on a provider that could be subject to those pressures in the first place.

• Infrastructure is either self-hosted (on-premises data centre) or provided by a sovereign cloud operator such as a Swiss-domiciled provider with no US or other foreign parent company.
• All hardware, networking equipment, and storage media are physically located in facilities the organisation controls or has contractual audit rights over.
• No US-headquartered entity exists anywhere in the infrastructure supply chain, eliminating CLOUD Act exposure.
• Administrative and support access is restricted to personnel based in approved jurisdictions.
• Network egress is actively monitored and no data leaves approved sovereignty zones.

Self-hosted (on-premises)

• Organisation owns or leases rack space in a Swiss data centre.
• Full control over hardware procurement, configuration, and lifecycle management.
• Highest sovereignty but requires significant operational capability and capital investment.

Sovereign cloud provider

• Services provided by a Swiss or EU-domiciled cloud operator (e.g., cyon, Infomaniak, Exoscale, Open Telekom Cloud with domestic entity).
• Provider's corporate structure has no foreign-jurisdiction parent or controlling shareholder.
• Contractual audit rights allow independent verification of residency controls.

Hybrid sovereign

• Critical data on self-hosted infrastructure; less sensitive workloads on sovereign cloud.
• Clear data classification policy determines which workloads run where.
• Unified monitoring across both environments.

The CLOUD Act grants US authorities the ability to compel disclosure from US-headquartered companies regardless of where data is physically stored. At Level 4, this risk is structurally eliminated because:

1. No US-headquartered entity has access to the infrastructure.
2. No US-headquartered entity holds encryption keys or administrative credentials.
3. No service agreement exists with a US-headquartered company that would create a legal nexus for compelled disclosure.

Reaching Level 4 does not mean the work is complete. The organisation must continuously monitor:

• Corporate ownership changes: Sovereign cloud providers may be acquired by foreign entities, reintroducing jurisdiction risk.
• Hardware supply chain: Servers, networking equipment, and storage media may contain firmware from foreign-jurisdiction manufacturers.
• Regulatory evolution: New international agreements or domestic legislation may alter the residency landscape.
• Operational discipline: Personnel changes, emergency procedures, and incident response must maintain sovereignty guarantees under all conditions.

Level 4 is appropriate when the organisation's threat model includes foreign government access to data, when clients contractually require sovereign infrastructure, or when operating in sectors where data sovereignty is a regulatory requirement or procurement criterion, such as finance, healthcare, legal services, and government contracting.

For most organisations, Level 3 technical controls satisfy regulatory requirements and provide verifiable residency enforcement. Level 4 requires significant capital investment in infrastructure, ongoing operational costs for facilities and hardware lifecycle management, and a commitment to monitoring provider ownership structures and supply chain integrity. Organisations should pursue Level 4 only when the residual CLOUD Act or foreign jurisdiction exposure at Level 3 is unacceptable for their specific use case.