Solution Atlas
SpecialisedUser storyConsultative playbook

Our regulator wants to see customer-managed keys and EU data boundary

A European financial-services firm needs a defensible answer to "where does the data live, who can access it, and can you prove both?" Standard Azure is not enough — the audit requires customer-managed HSM keys, Confidential Computing for the most sensitive workloads, and a sovereign landing-zone pattern.

Trigger
DORA / NIS2 review; auditor flagged BYOK and operational sovereignty.
Good outcome
Sovereign landing zone, FIPS 140-3 Level 3 HSM keys, Confidential Computing for the regulated tier.
Diagnostic discovery

Signals this story fits

Observable cues that confirm the conversation belongs here.

  • ·DORA, NIS2, or SecNumCloud regulatory review
  • ·Auditor flagged customer-managed keys or operational sovereignty gaps
  • ·EU Data Boundary commitment required
  • ·Standard Azure assessed as insufficient for the regulated tier
  • ·Customer Lockbox controls under review

Questions to ask

Open-ended, SPIN-style — each one has a reason it matters.

  1. 1.Which regulatory regimes apply — DORA, NIS2, SecNumCloud, sector-specific?

    WhyDetermines whether Microsoft Cloud for Sovereignty alone suffices or partner-operated sovereign cloud is required.

  2. 2.What does 'operational sovereignty' mean in your audit?

    WhySurfaces whether Customer Lockbox + EU Data Boundary suffice or stricter controls (e.g. local-resident operations) are demanded.

  3. 3.Where do customer-managed keys sit today — Key Vault standard or HSM?

    WhyManaged HSM is FIPS 140-3 Level 3; standard Key Vault HSM is Level 2. The auditor often demands Level 3 for the regulated tier.

  4. 4.Have you considered partner-operated sovereign clouds — Bleu in France, Delos in Germany?

    WhyWhere local sovereignty is mandatory (rare), the partner-operated path becomes the only viable answer.

  5. 5.Which workloads need Confidential Computing and which can stay standard?

    WhyConfidential Computing carries premium cost; scope it to the most sensitive workloads.

  6. 6.Is the audit cycle annual or continuous?

    WhyDrives whether continuous compliance attestation is needed or annual sufficient.

Baseline → target architecture

TOGAF-style gap framing — what we typically see today, and what the proposed end state looks like. The gap between them is the engagement.

Baseline architecture

Standard Azure tenancy with customer-managed keys in standard Key Vault. No Confidential Computing. Partial or aspirational EU Data Boundary commitment. Customer Lockbox not enabled. Compliance attestation produced manually for annual audit.

Typical concerns

  • ·Auditor flagged key custodianship as inadequate
  • ·EU Data Boundary commitment unclear in current architecture
  • ·Microsoft engineer access not gated by Customer Lockbox
  • ·Confidential Computing not in scope but required for some workloads
  • ·Compliance attestation reactive rather than continuous

Capability gaps

  • ·Sovereign Landing Zone architecture
  • ·FIPS 140-3 Level 3 customer-managed keys
  • ·Confidential Computing for the regulated tier
  • ·Customer Lockbox enabled
  • ·Continuous compliance attestation
Target architecture

Microsoft Cloud for Sovereignty landing zone with EU Data Boundary commitment and Customer Lockbox enabled. Azure Key Vault Managed HSM for regulated-tier keys (FIPS 140-3 Level 3). Confidential Computing for the most sensitive workloads (trusted execution environments). Defender for Cloud continuous compliance attestation mapped to applicable regulatory frameworks.

Key capabilities

  • Sovereign landing zone with EU Data Boundary
  • Customer-managed keys via Managed HSM
  • Confidential Computing for the regulated tier
  • Customer Lockbox enforced
  • Continuous compliance attestation

Enabling SKUs

Resolved in the ‘Recommended cards’ section below.

Architecture decisions

Each decision is offered as explicit options with trade-offs — Hohpe's “selling options” principle. A safe default is noted where one exists.

  1. Decision 1.Sovereignty path — Microsoft Cloud for Sovereignty vs partner-operated (Bleu / Delos)

    MCfS on public Azure

    When it fitsEU Data Boundary + Customer Lockbox + Confidential Computing satisfy the regulator.

    Trade-offsMicrosoft remains the operator; some regulators still demand local-resident operations.

    Partner-operated (Bleu / Delos)

    When it fitsRegulator demands local-resident operations (e.g. SecNumCloud in France).

    Trade-offsNarrower feature parity; separate commercial relationship; slower cadence.

    Default recommendationMCfS unless local-resident operations are mandated; partner-operated by exception.

  2. Decision 2.Confidential Computing scope — full tier vs selective

    Full regulated tier

    When it fitsAll workloads handling regulated data, including general PII.

    Trade-offsPremium cost; engineering complexity (re-architecture).

    Selective (most sensitive only)

    When it fitsSpecific workloads (cryptographic operations, model training on PII).

    Trade-offsTwo operational tiers to maintain.

    Default recommendationSelective. Start with the most sensitive workloads; expand if auditor pressure grows.

  3. Decision 3.Managed HSM custodianship — dedicated vs shared

    Dedicated

    When it fitsAuditor demands single-tenant HSM hardware.

    Trade-offsSignificantly higher cost per HSM.

    Shared (multi-tenant)

    When it fitsFIPS 140-3 Level 3 sufficient; multi-tenant acceptable.

    Trade-offsSome regulators still demand dedicated.

    Default recommendationShared unless explicitly required dedicated by audit.

Low-risk trial — proof of value

90-day Sovereign Landing Zone assessment + Managed HSM POC

12 weeks

Sovereign landing zone reference architecture mapped to applicable regulatory regime (DORA / NIS2 / SecNumCloud). Managed HSM provisioned for one regulated workload. Confidential Computing pilot for one cryptographic workload. Defender for Cloud compliance attestation mapped to the regulatory framework.

Success criteria

  • Sovereign landing zone reference architecture signed off by audit
  • Managed HSM key custodianship demonstrated end-to-end for the pilot workload
  • Confidential Computing trusted execution environment validated
  • Compliance attestation report produced from Defender for Cloud baseline

InvestmentManaged HSM ~€4.50/hour shared, ~€9/hour dedicated. Confidential Computing carries ~20–40% VM premium. Scoped to pilot workloads only.

Proof metrics

  • ·Audit signed off on the sovereign landing zone architecture
  • ·Customer Lockbox events traced end-to-end
  • ·Continuous compliance attestation operational
  • ·Key custodianship audit-ready

Recommended cards

The SKUs and capabilities most likely to be part of the solution, with the editorial rationale for each in the context of this story. Add the ones that fit your situation.

Why for this story

The architectural baseline — sovereign landing zone, EU Data Boundary, Customer Lockbox. Not a separate cloud; controls layered on public Azure.

Why for this story

FIPS 140-3 Level 3 customer-managed keys — the regulated-tier custodianship the audit demands.

Why for this story

Hardware-backed isolation for the most sensitive workloads (trusted execution environments). Scope it carefully — the premium is real.

Why for this story

Continuous compliance attestation framework mapped to DORA, NIS2, FedRAMP, IRAP, C5, SecNumCloud and similar regulatory regimes.

Why for this story

Sensitivity labelling for regulated content — the classification baseline auditors expect downstream of sovereignty controls.

Back to Sovereign cloud