Most sovereign cloud guidance is written for enterprises with dedicated legal teams and seven-figure cloud budgets. Here’s the problem: a 100-person SaaS company faces exactly the same CLOUD Act exposure and GDPR obligations as a Fortune 500. You just can’t afford to over-invest in controls you don’t need — or get the evaluation wrong.
This playbook gives you five concrete steps: classify workloads by sovereignty risk tier, evaluate providers against three layers (residency, jurisdiction, cryptographic control), implement BYOK or HYOK encryption, design for exit, and build a government-request SOP. The goal is a differentiated approach — sovereign-grade protection where it matters, standard hyperscaler where it doesn’t.
For foundational context, start with our sovereign cloud hub.
What Are the Five Steps in a Sovereign Cloud Due Diligence Framework?
Five steps, each producing a concrete deliverable:
- Classify workloads by sovereignty risk tier → tiered workload register
- Evaluate providers against the three-layer sovereignty model → provider scorecard
- Implement cryptographic controls (BYOK or HYOK) → encryption configuration per tier
- Design for exit → exit runbook with quantified egress costs
- Build a government-request SOP → documented triage procedure for CLOUD Act warrants
The whole framework is anchored to three sovereignty layers. A provider can pass one while failing the others:
- Data Residency: where data physically lives
- Legal Jurisdiction: which government can compel access
- Cryptographic Control: who holds the encryption keys
The CLOUD Act follows a simple principle: jurisdiction follows the provider. Frankfurt servers, Seattle headquarters — that satisfies residency. It does not satisfy jurisdiction or cryptographic control without specific configurations.
How Do You Classify Workloads by Sovereignty Risk Tier?
Workload classification assigns every cloud-hosted workload to one of three tiers based on data sensitivity, regulatory exposure, and the consequences of jurisdictional access. Get this right and every downstream decision follows naturally.
Tier 1 — High Sovereignty Risk: production databases with PII, financial records, healthcare data, AI training datasets with personal data. Requires HYOK with EU-based HSM; EU-native or sovereign cloud only.
Tier 2 — Medium Sovereignty Risk: business analytics, internal tool logs, configuration state, non-personal operational data. Requires BYOK with EU-located HSM; standard EU regions with guardrails; metadata sovereignty must be assessed.
Tier 3 — Low Sovereignty Risk: public-facing CDN content, open-source assets, CI/CD pipelines, dev/staging. Provider-managed keys acceptable; standard hyperscaler regions are fine.
The 100-Person SaaS Company
Here’s what that looks like in practice:
- Production database (customer PII, transaction records) → Tier 1: sovereign infrastructure with HYOK
- Application logs and monitoring → Tier 2: BYOK with EU HSM; check metadata flows
- Business analytics (aggregated, non-personal) → Tier 2: standard EU region with BYOK
- CI/CD and dev environments → Tier 3: standard hyperscaler is fine
- CDN and static assets → Tier 3: standard hyperscaler is fine
The Metadata Sovereignty Gap
Here’s something that catches people out. A Tier 1 workload’s content may be correctly classified, but its telemetry and logs can leak to non-sovereign infrastructure — a compliance gap even when data residency is satisfied. Classification is also not permanent; regulatory changes or entering a new market trigger reclassification. Build that review into your annual compliance cycle.
For which regulations apply to each tier, see which regulations apply to your workload tiers.
How Do You Evaluate a Cloud Provider Against the Three-Layer Sovereignty Framework?
Remember: a provider can satisfy one layer while failing the others. Data residency alone is not sovereignty. Tier 1 workloads require all three layers to pass. Tier 3 may accept a residency-only pass.
Layer 1 — Data Residency
- [ ] Is all customer data stored exclusively within EU borders?
- [ ] Is metadata (logs, telemetry, API call records) also retained within EU borders?
- [ ] Does the provider publish clear data residency commitments in their service agreement?
Layer 2 — Legal Jurisdiction
- [ ] Is the provider headquartered within the EU (not a subsidiary of a US parent)?
- [ ] Is the provider free from extraterritorial laws (U.S. CLOUD Act, FISA 702)?
- [ ] Has the provider documented how they handle government data requests?
Layer 3 — Cryptographic Control
- [ ] Does the provider offer HYOK (keys held entirely outside provider infrastructure)?
- [ ] If BYOK: are keys stored in an EU-based HSM under your control?
- [ ] Can the provider technically comply with a CLOUD Act decryption order in your current configuration?
Exit and Portability
- [ ] What are egress fees per GB, and what are the exit terms?
- [ ] Does the provider support open standards (S3-compatible storage, Kubernetes, OpenAPI)?
AWS European Sovereign Cloud (Brandenburg): Operated exclusively by EU residents under German law legal entities. Passes Layer 1. Layer 2 is qualified — AWS remains a US-headquartered company subject to the CLOUD Act. Layer 3 depends on your encryption configuration.
EU-native providers (Hetzner, OVHcloud, Scaleway, T-Systems): EU-headquartered, no CLOUD Act exposure. Passes all three layers. Trade-off: smaller managed service portfolios.
For a detailed scoring, see how hyperscaler sovereign offerings score against these criteria and EU-native providers to consider for your regulated workloads.
How Do You Implement BYOK or HYOK to Reduce CLOUD Act Exposure?
Once you know a provider’s jurisdictional status, the right encryption tier follows directly.
BYOK (Bring Your Own Key): You generate keys and import them into the provider’s Key Management Service (e.g., AWS KMS). The provider stores and manages them — you have more control than with provider-managed keys, but the provider still has operational access after import. Under a CLOUD Act warrant, the provider controls both data and keys. BYOK reduces practical risk but does not remove the provider’s technical ability to comply.
HYOK (Hold Your Own Key): Keys never leave your environment — stored in your own EU-based Hardware Security Module (HSM). The provider requests temporary access for encryption operations; keys are then purged and never persisted. The provider cannot technically comply with a decryption order because it does not possess the keys. As Brian Robertson of Thales Group puts it: “Encrypting data without managing the keys is like locking the door and leaving the key under the mat.”
Which Tier Gets Which Approach
Tier 1 — High Risk: HYOK. EU-based HSM; external key store never hosted on provider infrastructure.
Tier 2 — Medium Risk: BYOK with EU HSM. Customer-managed key in AWS KMS / Azure Key Vault; HSM must be EU-located.
Tier 3 — Low Risk: Provider-managed keys acceptable.
For full detail on what BYOK mitigates and what it does not, see the specific CLOUD Act exposure that BYOK mitigates.
How Do You Design an Exit Architecture to Avoid Sovereign Cloud Vendor Lock-in?
Exit architecture is the operational layer of sovereignty — the deliberate design that ensures workloads can migrate without prohibitive cost. The core principle is simple: adopt open standards from the start so switching providers is a configuration change, not a rewrite.
Every proprietary dependency is an exit cost multiplier. Map these during workload classification. Kubernetes (portable) vs AWS ECS. Terraform vs CloudFormation. S3-compatible storage vs AWS S3 with proprietary features. PostgreSQL-compatible vs Aurora Serverless or DynamoDB.
Egress fees run $0.05–$0.09 per GB. For 50TB, that’s $2,500–$4,500 — before labour, refactoring, and downtime. DORA Article 28 requires financial entities to maintain documented, tested exit plans for critical ICT service providers. Even outside financial services, this is sound practice.
Exit Architecture Checklist
- [ ] Are compute workloads orchestrated using Kubernetes?
- [ ] Is infrastructure defined in Terraform?
- [ ] Does object storage use an S3-compatible API portable to EU-native providers?
- [ ] Have you mapped all proprietary service dependencies and quantified exit cost?
- [ ] Is there a documented and tested migration runbook for each Tier 1 and Tier 2 workload?
For DORA exit planning context, see which regulations apply to your workload tiers.
How Do You Build a Government-Request SOP Without a Legal Team?
The legal layer of sovereignty is a government-request SOP — a pre-built procedure for when your cloud provider receives a CLOUD Act warrant. Have it documented before it happens. The CLOUD Act has no company-size threshold, so there’s no getting out of this one.
Step 1 — Validate the legal basis: Which jurisdiction? Which instrument? Specific in scope? If not, the provider can challenge it.
Step 2 — Assess GDPR transfer basis: GDPR Article 48 prevents transfer to non-EU authorities based solely on a foreign court order. Does a lawful transfer basis exist? Document it.
Step 3 — Determine MLAT routing: Mutual Legal Assistance Treaties provide a bilateral process satisfying both US and EU requirements. If appropriate, advocate for it.
Step 4 — Consider a comity challenge: If US and EU obligations conflict, providers can contest orders using comity principles.
Step 5 — Escalate to external legal counsel: Engage counsel with steps 1–4 complete. It saves fees and response time.
For HYOK-protected workloads, the provider cannot technically comply — the request is redirected to you as data controller. Designate a named role for receiving requests, not a general inbox, and review the SOP annually.
For detailed coverage of the legal exposure behind this SOP, see the specific CLOUD Act exposure that BYOK mitigates.
What Does a Multi-Cloud Hybrid Sovereignty Strategy Look Like in Practice?
Here’s the pragmatic answer for a 100-person SaaS company: EU-native or sovereign cloud for Tier 1 and Tier 2 regulated workloads, standard hyperscaler for Tier 3. This avoids both extremes — full hyperscaler exit (expensive and unnecessary for non-sensitive workloads) and full hyperscaler reliance (Tier 1 data exposed to CLOUD Act risk).
Concrete pattern: Hetzner Cloud or OVHcloud for Tier 1 (German/French jurisdiction, no CLOUD Act exposure, HYOK). EU-native provider with BYOK for Tier 2, monitoring and logging in the EU. AWS Frankfurt for Tier 3.
AWS European Sovereign Cloud carries a 10–15% premium over standard Frankfurt regions. Hetzner offers significantly lower compute and storage costs — one case study saw a platform cut infrastructure costs by 60% after migrating from AWS to Hetzner using Kubernetes. The trade-off: fewer managed services, more operational responsibility.
The hybrid strategy needs a unified management layer — Kubernetes and Terraform spanning both environments, EU-based monitoring for Tier 1 and Tier 2 workloads. A Tier 1 workload on Hetzner can be undermined by a monitoring agent that phones home to a US-headquartered analytics service.
For EU-native provider options, see EU-native providers to consider for your regulated workloads. For the sovereign cloud overview, see our sovereign cloud hub.
Sovereign Cloud Due Diligence Checklist
Copy this into your internal documentation or use it as a quarterly review.
Step 1 — Workload Classification
- [ ] Have you inventoried all cloud-hosted workloads?
- [ ] Have you assigned each to a sovereignty risk tier (Tier 1 / Tier 2 / Tier 3)?
- [ ] Have you identified metadata flows (where do logs, telemetry, API call records go)?
- [ ] Is there a scheduled review trigger for reclassification?
Step 2 — Provider Evaluation
- [ ] For each provider, have you assessed data residency, legal jurisdiction, and cryptographic control?
- [ ] Have you confirmed metadata handling (are logs and telemetry retained within EU borders)?
- [ ] Is the provider EU-headquartered or subject to non-EU extraterritorial laws?
- [ ] Have you reviewed exit terms and quantified egress fees?
Step 3 — Encryption Configuration
- [ ] Have you implemented HYOK for all Tier 1 workloads?
- [ ] Have you implemented BYOK with an EU-located HSM for Tier 2 workloads?
- [ ] Have you verified the provider cannot access plaintext for Tier 1 data?
Step 4 — Exit Architecture
- [ ] Are compute workloads orchestrated using Kubernetes?
- [ ] Is infrastructure defined in Terraform?
- [ ] Does object storage use an S3-compatible API?
- [ ] Have you mapped proprietary dependencies and quantified exit cost?
- [ ] Is there a documented and tested migration runbook for Tier 1 and Tier 2 workloads?
Step 5 — Government-Request SOP
- [ ] Have you documented the five-step triage procedure?
- [ ] Have you designated a named role for receiving government requests?
- [ ] Have you identified external legal counsel to engage at Step 5?
- [ ] Is the SOP reviewed annually?
Red Flags — Act Now
- Tier 1 data on a US-headquartered provider without HYOK — provider can technically comply with a CLOUD Act decryption order
- Tier 1 workload metadata processed outside the EU — compliance gap even if content data residency is satisfied
- No documented exit plan — forced migration at undetermined cost
- No government-request SOP — any request triggers improvised response under time pressure
- All workloads on a single provider with proprietary dependencies — sovereignty and exit risks compound
FAQ
Does BYOK actually protect my data from a CLOUD Act warrant?
BYOK reduces practical risk but does not eliminate it. With BYOK, the provider stores your key material in their KMS — they control both data and keys, and can produce decrypted data if compelled. HYOK removes the provider’s technical ability to comply entirely.
What is the difference between data residency and data sovereignty?
Data residency means data is physically stored within a specific geographic boundary. Data sovereignty means it is also subject only to the laws of that jurisdiction. A US-headquartered provider with EU data centres satisfies residency but not sovereignty — the CLOUD Act gives US authorities legal access regardless of server location.
How much does it cost to migrate off a hyperscaler?
Egress fees run $0.05–$0.09 per GB. For 50TB, that’s $2,500–$4,500 in egress alone — before labour, refactoring, and downtime. Open standards adoption (Kubernetes, Terraform) reduces refactoring costs significantly.
Do I need a sovereign cloud for all my workloads?
No. Tier 3 workloads (dev/staging, CDN, open-source assets) are fine on standard hyperscaler regions. The hybrid approach — sovereign-grade for sensitive workloads, hyperscaler for non-critical — is the cost-effective strategy.
What metadata leaves the EU in a standard AWS deployment?
CloudWatch logs, CloudTrail audit records, AWS Config snapshots, and API call metadata may be processed outside the EU even when content data stays in an EU region. This telemetry reveals access patterns, user behaviour, and system architecture — a compliance gap even when data residency is satisfied.
Is AWS European Sovereign Cloud sufficient for GDPR compliance?
It addresses data residency and operational control — EU-resident staff, German law legal entities. But AWS remains a US-headquartered company subject to the CLOUD Act. For Tier 1 workloads, assess whether HYOK is needed to close the jurisdictional gap. For Tier 2 and Tier 3, it may be sufficient depending on your risk assessment.
What should I do if my cloud provider receives a government data request?
Follow the five-step SOP: validate the legal basis, assess GDPR transfer basis, determine if MLAT routing is appropriate, consider a comity challenge, then escalate to external legal counsel with your triage complete. For HYOK-protected data, the request is redirected to you as data controller.
How does DORA Article 28 affect my cloud exit planning?
It requires financial entities to maintain documented, tested exit plans for critical ICT service providers — regularly updated, tested at intervals, approved by senior management. Even outside financial services, this is sound practice.
Is Hetzner a viable alternative to AWS for production workloads?
Hetzner offers lower compute and storage costs and operates under German legal jurisdiction with no CLOUD Act exposure. For Tier 1 and Tier 2 workloads that don’t need AWS’s managed service breadth, it’s a solid sovereign option. Trade-off: smaller managed service portfolio, more operational responsibility.
How do I handle sovereignty for AI training data?
AI training datasets with personal data are Tier 1. The EU AI Act requires full traceability, secure storage, risk classification, and auditability of AI pipelines. Apply HYOK encryption and ensure the training infrastructure itself — not just data storage — operates within EU jurisdiction.
What is the minimum viable sovereignty posture for an SMB?
Classify workloads into three tiers, implement BYOK for Tier 2, use EU regions for all production data, document a government-request SOP, and maintain an exit runbook. For companies handling regulated PII, add HYOK for Tier 1 and evaluate EU-native providers. Achievable without a dedicated compliance team.
