We have written before about Europe’s turning point in cloud control and what the EU Data Boundary mean for organisations on Azure. The strategy part of that conversation is largely settled. The question now is how you actually build it.
That is where the Sovereign Landing Zone comes in.
Same foundation, stricter guardrails
The Sovereign Landing Zone, or SLZ, is Microsoft’s answer to a question regulators keep asking: can you prove control over your cloud environment, not just claim it? It builds on the standard Azure Landing Zone most enterprises already know, and adds a layer of policies, encryption defaults and access controls designed for regulated workloads.
So what changed in 2026?
Two updates make this worth a fresh look:
The original Sovereignty Baseline initiatives have been replaced by built-in Azure Policy initiatives mapped to sovereign control levels 1, 2 and 3. Workloads that genuinely need the strictest controls get them. Others avoid unnecessary operational and financial overhead. That alone makes the SLZ usable across a much wider portfolio than the all-or-nothing version we had before.
Alongside that, the SLZ is now aligned with the refreshed ALZ programme, including the new Local management group and full AVM support. The platform is modular, easier to keep current, and no longer a one-way door.
The three levels for sovereign controls
In plain terms, the three levels are a maturity model for sovereign controls. You apply only what each workload needs, based on its data classification.
Level 1, data residency. Restricts where resources can be deployed and where data can be stored or processed. Keeps workloads inside legally defined boundaries, whether that is an EU region, a specific country or a sovereign partner region. This is the baseline for almost everything except purely public content.
Level 2, encryption at rest and in transit. Enforces customer managed keys, typically backed by Azure Key Vault Managed HSM (FIPS 140-2 Level 3 validated). The point is simple: no one, including Microsoft, can read your data without your keys. Applied on top of L1 for regulated business workloads.
Level 3, encryption in use. Requires confidential compute, so data stays encrypted even while being processed in memory. Reserved for your most sensitive workloads, sitting in the Confidential Online and Confidential Corp management groups. This significantly reduces the trust dependency on the cloud provider.
In practice, public data gets no sovereign controls, most regulated business apps land at L1 + L2, and the crown jewels run with all three. Clean, layered, and finally easy to audit in Defender for Cloud.
A business decision before a technical one
Questions such as which workloads should sit at control level 3 and which can run at level 1 are business decisions first. Who holds the encryption keys. What happens to operations if a vendor relationship shifts overnight. How quickly you can prove compliance to a regulator or to your own board. These are not Bicep questions. They are risk appetite questions, and the platform team cannot answer them on your behalf.
The organisations doing this well use the SLZ as a forcing function to get legal, security and engineering on the same page before anything gets deployed.
Public sector bodies with explicit operational sovereignty requirements. Financial services and insurers under DORA, where regulators are asking sharper questions about cloud concentration risk. Healthcare and life sciences. Energy, defence and other critical infrastructure. And any multinational where customer contracts have started to include sovereignty clauses (you have likely already seen this appearing in contracts).
Designing your Sovereign Landing Zone
We rarely recommend jumping straight into a full SLZ deployment. The better first step is an honest view of where you are today, mapped against the CAF design areas and the sovereignty controls that actually apply to you. Usually the gap is smaller than people fear in some areas and bigger in others. Both are useful to know before budget gets committed.
Our Azure Infrastructure Assessment is built for exactly this conversation. We review your current environment, identify the real sovereignty gaps, and give you a prioritised path forward you can take to your board without translation.
If digital sovereignty is climbing your agenda, let’s discuss what this means for your Azure platform before timelines and compliance pressures start dictating the conversation. Schedule a direct conversation with DevOps Masterminds CTO Rinie Huijgen.
