Sovereign Cloud on Azure: Data Residency, Encryption, and EU Compliance Patterns

Data sovereignty is no longer a compliance checkbox — it is a board-level concern that shapes cloud strategy for every European enterprise. The combination of GDPR enforcement actions, Schrems II implications, and emerging regulations like the EU Data Act has created a landscape where "we use Azure in West Europe" is not a sufficient answer to the question of data sovereignty.

This guide provides a practical architecture for building sovereign cloud solutions on Azure. We cover the full spectrum: data residency controls, encryption with customer-managed keys, confidential computing for processing sovereignty, and the compliance framework that ties it all together.

The Sovereignty Spectrum

Sovereignty is not binary. It exists on a spectrum, and understanding where your organisation needs to be is the first architectural decision.

Level 1 — Data Residency: Customer data at rest and in transit stays within a defined geography. This is the minimum for GDPR compliance.

Level 2 — Operational Sovereignty: In addition to data residency, operational access by the cloud provider is controlled, logged, and can be denied. Microsoft's Customer Lockbox and Lockbox for Azure fall here.

Level 3 — Cryptographic Sovereignty: You control encryption keys, and without your explicit grant, data is inaccessible — even to the cloud provider. Azure Key Vault Managed HSM enables this.

Level 4 — Processing Sovereignty: Even during computation, data is protected from the cloud operator using hardware-based trusted execution environments. Azure Confidential Computing delivers this.

Level 5 — Full Sovereignty: Infrastructure is operated by a sovereign entity, not the hyperscaler directly. Azure offerings through local operators or Azure Stack HCI on-premises reach this level.

Most European enterprises need Level 2-3. Regulated industries (healthcare, finance, public sector) increasingly require Level 4.

Azure EU Data Boundary: What It Covers and What It Does Not

Microsoft's EU Data Boundary is the foundation layer. Announced in 2022 and progressively expanded, it commits to keeping EU customer data within the EU.

What is covered

• Core platform services: Compute, storage, databases, networking for resources deployed in EU regions
• Professional services data: Support ticket data stays in the EU
• Entra ID authentication logs: Processed within the EU boundary
• Microsoft 365 content data: Emails, documents, Teams messages for EU-tenanted customers

What is not fully covered

• Global network telemetry: Some operational data about network routing and performance may leave the EU
• Abuse detection and security signals: Threat intelligence correlation may involve global processing
• Third-party marketplace apps: Sovereignty depends on the ISV, not Microsoft
• Azure DevOps: Verify region settings explicitly; default behaviour varies

Critical verification steps

# Verify resource location programmatically
az resource list --query "[].{Name:name, Location:location, Type:type}" \
  --output table | grep -v "westeurope\|northeurope\|germanywestcentral\|francecentral\|swedencentral"

# Check Azure Policy for allowed locations
az policy assignment list --query "[?contains(policyDefinitionId, 'allowedLocations')]" \
  --output table

Data Classification and Sovereignty Zones

Before selecting technical controls, classify your data. Not all data requires the same sovereignty level, and over-protecting everything is expensive.

Classification framework

Implementing sovereignty zones in Azure

Map sovereignty levels to Azure constructs:

// Sovereignty zone implementation via Management Groups
targetScope = 'managementGroup'

// Zone 1: Standard EU workloads (Level 1-2)
resource mgStandardEU 'Microsoft.Management/managementGroups@2021-04-01' = {
  name: 'mg-sovereign-standard-eu'
  properties: {
    displayName: 'Standard EU Workloads'
  }
}

// Zone 2: Confidential workloads (Level 3-4)
resource mgConfidentialEU 'Microsoft.Management/managementGroups@2021-04-01' = {
  name: 'mg-sovereign-confidential-eu'
  properties: {
    displayName: 'Confidential EU Workloads'
  }
}

// Policy: Restrict regions to EU only
resource policyAllowedLocations 'Microsoft.Authorization/policyAssignments@2022-06-01' = {
  name: 'restrict-to-eu-regions'
  properties: {
    policyDefinitionId: '/providers/Microsoft.Authorization/policyDefinitions/e56962a6-4747-49cd-b67b-bf8b01975c4c'
    parameters: {
      listOfAllowedLocations: {
        value: [
          'westeurope'
          'northeurope'
          'germanywestcentral'
          'francecentral'
          'francesouth'
          'swedencentral'
          'swedensouth'
          'norwayeast'
          'norwaywest'
          'switzerlandnorth'
          'switzerlandwest'
          'polandcentral'
          'italynorth'
          'spaincentral'
        ]
      }
    }
  }
}

Encryption Architecture: Customer-Managed Keys

Default Azure encryption uses Microsoft-managed keys. This satisfies basic compliance but does not provide cryptographic sovereignty — Microsoft controls the keys and, under a US court order, could theoretically be compelled to provide access.

Key Vault hierarchy for sovereignty

Implementation with Managed HSM

// Managed HSM deployment - requires 3 RSA key holders for activation
resource managedHsm 'Microsoft.KeyVault/managedHSMs@2023-07-01' = {
  name: 'hsm-sovereign-${environment}'
  location: 'germanywestcentral'
  properties: {
    tenantId: subscription().tenantId
    initialAdminObjectIds: [securityTeamObjectId]
    enableSoftDelete: true
    softDeleteRetentionInDays: 90
    enablePurgeProtection: true
    networkAcls: {
      bypass: 'None'
      defaultAction: 'Deny'
      ipRules: [
        { value: corporateEgressIp }
      ]
      virtualNetworkRules: [
        { id: managementSubnetId }
      ]
    }
  }
  sku: {
    family: 'B'
    name: 'Standard_B1'
  }
}

Services that support customer-managed keys

Not every Azure service supports CMK. Plan your architecture around this reality:

Confidential Computing: Processing Sovereignty

Encryption at rest and in transit is standard. Confidential computing adds encryption during processing — data is protected even from the cloud operator, hypervisor, and other tenants.

Azure Confidential Computing options

DCasv5 / ECasv5 VMs (AMD SEV-SNP): Hardware-based memory encryption. The entire VM memory is encrypted with a key managed by the AMD Secure Processor, inaccessible to the hypervisor. Best for lift-and-shift scenarios where you want full VM sovereignty without code changes.

DCsv3 / DCdsv3 VMs (Intel SGX): Application-level enclaves. More granular than full-VM encryption but requires code modification using the Open Enclave SDK or Intel SGX SDK. Best for targeted protection of specific data processing steps.

Confidential Containers on AKS: Run containers in hardware-based trusted execution environments. The Kubernetes control plane cannot inspect container memory.

When confidential computing is justified

Confidential computing adds cost (10-30 % premium on compute) and complexity. Use it when:

• You process health data (Art. 9 GDPR special categories)
• Multi-party computation scenarios where parties do not trust each other
• You need to demonstrate to regulators that not even your cloud provider can access data during processing
• Financial services processing under BaFin or ECB oversight

Deployment pattern for confidential AKS

# Confidential node pool for AKS
apiVersion: v1
kind: NodePool
metadata:
  name: confidential-pool
spec:
  vmSize: Standard_DC4as_v5
  enableEncryptionAtHost: true
  osSKU: AzureLinux
  securityProfile:
    enableSecureBoot: true
    enableVTPM: true
  count: 3
  mode: User
  labels:
    sovereignty: confidential
  taints:
    - key: sovereignty
      value: confidential
      effect: NoSchedule

GDPR and Schrems II: Practical Compliance Architecture

Schrems II implications for Azure

The Schrems II ruling (2020) invalidated the EU-US Privacy Shield and raised the bar for data transfers to countries without adequate data protection. For Azure customers, the practical implications are:

1. Standard Contractual Clauses (SCCs) are necessary but not sufficient. Microsoft offers SCCs, but you must conduct a Transfer Impact Assessment (TIA) for any data that could theoretically be accessed from outside the EU.

2. US CLOUD Act risk. As a US-headquartered company, Microsoft is subject to the CLOUD Act, which allows US authorities to compel disclosure of data stored abroad. Customer-managed keys with Managed HSM mitigate this — Microsoft cannot decrypt data without your keys.

3. EU-US Data Privacy Framework. The adequacy decision from 2023 provides a legal basis for transfers, but its durability is uncertain (a "Schrems III" challenge is expected). Do not architect your sovereignty strategy solely on the DPF.

Defence-in-depth compliance architecture

Sovereignty audit workbook queries

// Detect any resource deployment outside EU regions
AzureActivity
| where OperationNameValue has "Microsoft.Resources/deployments/write"
| where ActivityStatusValue == "Success"
| extend resourceLocation = tostring(parse_json(Properties).targetResource.resourceLocation)
| where resourceLocation !in (
    "westeurope", "northeurope", "germanywestcentral",
    "francecentral", "swedencentral", "norwayeast",
    "switzerlandnorth", "polandcentral", "italynorth", "spaincentral"
  )
| project TimeGenerated, Caller, resourceLocation, ResourceGroup

// Monitor Customer Lockbox requests
AzureActivity
| where OperationNameValue has "Microsoft.CustomerLockbox"
| project TimeGenerated, Caller, OperationNameValue, ActivityStatusValue

Comparing Azure Sovereign Offerings

Implementation Roadmap

Weeks 1-2: Assessment. Classify all data. Map regulatory requirements to sovereignty levels. Identify gaps between current state and target.

Weeks 3-4: Foundation. Deploy Managed HSM. Implement Azure Policy for region restrictions. Enable Customer Lockbox tenant-wide.

Weeks 5-8: Migration. Rotate encryption to customer-managed keys service by service. Enable private endpoints. Deploy sovereignty audit workbook.

Weeks 9-12: Confidential workloads. Migrate restricted-classification workloads to confidential computing. Validate with penetration testing and compliance audit.

Ongoing: Monthly sovereignty posture reviews. Quarterly TIA updates. Annual third-party compliance audit.

Trade-offs and Honest Assessment

Sovereign cloud on Azure is achievable, but it comes with trade-offs:

• Cost: Managed HSM starts at approximately EUR 3,500/month. Confidential VMs are 10-30 % more expensive. Total sovereignty premium is typically 15-25 % on compute and storage costs.
• Feature limitations: Not every Azure service supports CMK or confidential computing. You may need to avoid certain PaaS services or accept Microsoft-managed encryption for non-sensitive workloads.
• Operational complexity: Key management, rotation policies, and break-glass procedures add operational burden. Budget for at least one additional security engineer.
• Performance: Confidential computing may add 5-15 % latency for memory-intensive workloads.

These trade-offs are worthwhile for organisations that face genuine regulatory requirements. They are overkill for organisations that do not process sensitive European personal data.

Next Steps

Sovereignty architecture requires balancing regulatory compliance with operational pragmatism. Over-engineering sovereignty wastes budget. Under-engineering it risks regulatory penalties and customer trust.

If you need help assessing your sovereignty requirements, designing your encryption architecture, or implementing confidential computing workloads on Azure, get in touch at mbrahim@conceptualise.de. We help European enterprises build cloud architectures that satisfy regulators without sacrificing agility.