Sovereign Cloud: How EU Regulations Reshape Swiss Cloud 2026

Three major EU regulatory frameworks — DORA, NIS2, and the EU AI Act — are creating infrastructure constraints for Swiss financial, healthcare, and technology organisations that use US hyperscaler cloud services for regulated workloads. Each framework imposes requirements that the standard commercial terms of AWS, Microsoft Azure, and Google Cloud do not satisfy for regulated entities: audit rights that hyperscalers contractually limit, data processing location guarantees that US parent company access undermines, and algorithmic accountability obligations that require data governance documentation that US providers cannot produce without restriction. Swiss organisations that built cloud strategies around hyperscaler infrastructure before these frameworks applied are now discovering that their cloud architecture creates compliance gaps — and that the cost of remediation is substantially higher than the cost of getting the architecture right before migration.

What Each Framework Actually Requires from Cloud Infrastructure

DORA Articles 28 through 44 govern ICT third-party risk, with specific provisions for cloud service providers classified as Critical ICT Third-Party Providers (CTPPs). For financial entities, DORA requires contractual provisions with cloud providers that include: a right to audit the provider's ICT security measures, either directly or through accredited third parties; provisions limiting subcontracting by the cloud provider to approved subcontractors; documented exit strategies enabling the financial entity to migrate workloads within defined timelines; and provisions ensuring the cloud provider cooperates with the competent authority's supervisory investigations. Standard hyperscaler enterprise agreements do not include all of these provisions. AWS, Azure, and GCP offer audit rights in specific terms, but the scope and operationalisation of those rights differ materially from what DORA Article 30 requires. Swiss financial entities whose EU subsidiaries rely on hyperscaler infrastructure for DORA-covered ICT services need to verify, contract by contract, that the required provisions are in place — not assume that the enterprise agreement suffices.

NIS2 Article 21 requires entities to address ICT supply chain security, including the security practices of cloud providers as critical suppliers. For essential and important entities, this includes conducting security assessments of cloud infrastructure providers, verifying that providers implement security measures at least equivalent to the entity's own Article 21 obligations, and maintaining documented risk assessments for each critical supplier. The US CLOUD Act — which requires US cloud providers to comply with US law enforcement data access requests even for data stored outside the United States — creates a sovereignty risk that NIS2 supply chain security assessments must address explicitly. An EU-region Azure instance operated by a Microsoft US subsidiary entity is not legally equivalent to an EU-resident cloud service operated by an EU-registered provider from a CLOUD Act exposure perspective.

The EU AI Act introduces a third constraint dimension for Swiss organisations deploying AI systems in EU market contexts. High-risk AI systems under Annex III — which includes systems used in employment decisions, credit scoring, critical infrastructure management, and law enforcement — require conformity assessments that include documenting data governance arrangements for training and inference data. EU AI Act Article 10 requires that training data processing, data quality measures, and data governance frameworks be documented and available for supervisory review. If a Swiss financial institution's AI system processes training data in a US hyperscaler environment subject to US discovery and law enforcement access, the data governance documentation cannot provide the sovereignty guarantees that EU supervisors may require in a conformity assessment context.

The Hyperscaler Architecture Problem

The three frameworks converge on a structural problem with hyperscaler cloud architecture for regulated Swiss entities: the services are technically excellent and operationally mature, but the contractual, jurisdictional, and governance architecture is built for global commercial customers rather than regulated financial and healthcare entities with specific European sovereignty requirements. Hyperscalers have invested substantially in EU-region infrastructure, GDPR compliance tooling, and financial services addenda — and for many use cases, these provisions are sufficient. The problem is specifically in the intersection of regulated-data workloads, audit rights under DORA, CLOUD Act jurisdiction, and EU AI Act conformity assessment requirements.

Swiss FinTech companies that built their core banking or insurance platforms on AWS or Azure before DORA applied in January 2025 are facing a migration calculation that is not simply about cost. Migrating a core banking platform from AWS to an EU-sovereign provider is a multi-year programme involving re-architecture, certification under the new provider's compliance framework, data migration under Swiss and EU data protection law, and parallel operation during transition. The organisations that need to make this migration are not doing so because they prefer sovereign cloud — they are doing so because their regulatory compliance position requires it and the alternative is a documented gap in their DORA or NIS2 compliance documentation.

What Sovereign Cloud Actually Means in the Swiss Context

Sovereign cloud in the Swiss regulatory context does not necessarily mean Swiss-hosted cloud. It means cloud infrastructure that satisfies the combination of FINMA outsourcing requirements (Circular 2018/3), DORA ICT third-party provisions, NIS2 supply chain security obligations, and nDSG data processing requirements simultaneously. This can be achieved through multiple architectural approaches: Swiss-hosted sovereign cloud from providers like Swisscom or IPFone (which satisfies data residency under FINMA and nDSG but requires verification of DORA audit right provisions); EU-resident cloud from EU-based providers not subject to US CLOUD Act jurisdiction (which addresses the sovereignty risk for EU subsidiary workloads); or sovereign cloud tiers from hyperscalers that ring-fence EU data with EU-based operational staff and governance (a model Microsoft is deploying with its EU Data Boundary programme, though the contractual implementation is still evolving).

No single architecture satisfies all regulated Swiss entities across all workload types. A Swiss cantonal bank with no EU subsidiary operations and purely domestic regulatory obligations faces different constraints from a Swiss private bank with DORA-covered EU subsidiaries and EU AI Act-classified algorithmic credit scoring systems. The analysis must be done at the workload level, not the organisation level — and that analysis requires legal, compliance, and infrastructure teams working from a shared regulatory requirement mapping rather than from separate advisory engagements that produce contradictory conclusions.

A Framework for Cloud Architecture Assessment

Swiss organisations navigating the sovereign cloud question need a structured assessment methodology that maps workload classification to regulatory requirement to provider capability. The starting point is workload classification: not all cloud workloads create regulatory risk. An HR system or marketing analytics platform may operate on a US hyperscaler without generating DORA, NIS2, or EU AI Act exposure. The regulated workloads — core banking systems, patient clinical data, DORA-covered ICT services, NIS2-critical infrastructure management, high-risk AI systems — are the ones requiring architectural review.

For each regulated workload, the assessment maps three dimensions: data sovereignty (where is data stored and processed, and who has legal access to it under US, EU, and Swiss law); auditability (does the provider contract satisfy DORA Article 30, NIS2 Article 21, and FINMA Circular 2018/3 audit and supervisory cooperation requirements simultaneously); and exit viability (can the organisation migrate this workload to an alternative provider within the timeline its DORA exit strategy commits to, and has that strategy been tested).

• Classify all cloud workloads by regulatory category — identify which carry DORA, NIS2, EU AI Act, FINMA, and nDSG obligations, and which are unregulated; focus architectural remediation on regulated workloads only.
• Review existing hyperscaler contracts for DORA Article 30 provisions: audit rights, subcontracting restrictions, and supervisory cooperation clauses — absence of any of these in a contract covering a DORA-covered ICT service is a documented compliance gap.
• Assess CLOUD Act exposure for workloads subject to EU data residency obligations — data stored in an EU-region hyperscaler operated by a US parent entity does not provide US-law access immunity; document this exposure explicitly in your ICT risk assessment.
• For EU AI Act high-risk AI systems, verify that data governance documentation for training and inference data can be produced without reference to US parent company access — if it cannot, the conformity assessment documentation is incomplete.
• Build a workload migration prioritisation based on compliance urgency, not technical complexity — the workloads with the highest regulatory exposure should migrate first, regardless of how complex the migration is technically.
• Engage legal counsel with specific expertise in the intersection of DORA, NIS2, and Swiss data protection law before selecting alternative providers — the compliance requirements of the three frameworks are not identical and selecting a provider that satisfies one while creating gaps under another is a common and costly mistake.
• Test your DORA exit strategies annually against actual provider transition timelines — a documented exit strategy that assumes 90-day migration for a platform that actually requires 18 months is a governance fiction that will be exposed in a supervisory review.

The convergence of DORA, NIS2, and the EU AI Act is not creating a cloud compliance problem — it is surfacing an architecture alignment gap that has existed since Swiss regulated entities adopted hyperscaler infrastructure without systematically evaluating it against the regulatory frameworks that govern their regulated operations. The organisations that treat sovereign cloud as a strategic architecture question — mapping requirements to workloads to provider capabilities in a structured assessment — will build cloud infrastructure that is both operationally efficient and regulatorily defensible. The ones that treat it as a vendor selection question or a future compliance project will find themselves making expensive reactive migrations in an enforcement environment that moves faster than their architecture review cycles.