Selecting UK South as your deployment region closes roughly 60% of the residency problem. Most platform architects do not find out about the other 40% until an FCA operational resilience review or an NHS DSPT mandatory audit uncovers it. Identity metadata for every UK Entra ID tenant lives in Amsterdam and Dublin, not in London, regardless of where your virtual machines sit. Azure OpenAI and Foundry model deployments can use Global deployment types that route inference requests to available Azure capacity outside the UK unless a regional deployment is selected. Log Analytics workspaces created by auto-provisioning features during Sentinel onboarding land wherever the platform default points, which is rarely UK South unless someone has already set it. Front Door edge nodes can cache response bodies outside the UK, depending on where users connect from and where edge capacity serves the request. The default replication setting on a new Recovery Services vault is geo-redundant storage, which will surprise you the day you read your DPIA and realise you never explicitly chose it.
The standard approach to this problem is to set a location policy, tick the Customer Lockbox box, and move on. For OFFICIAL-tier workloads with a simple risk profile, that approach mostly holds. It breaks under FCA PS21/3 impact-tolerance scrutiny, NHS DSPT mandatory independent audit requirements, and any supply-chain accreditation that imposes a literal “all data in the UK” clause. The difference between a design that passes those reviews and one that fails is not the region selector. It is a layered set of controls: policy that covers the right scope, key management at the right tier, diagnostic settings on every service, and an audit chain that connects every operator-access event to an approval record.
This post is a technical reference for platform architects building those controls in production, not a strategic overview of why UK data residency matters. The comparison between Azure, AWS, and GCP sovereign approaches, and the regulatory context that drives the decision, is in our UK Cloud Sovereignty Architecture guide. This post starts where that one ends.
What Azure Policy Actually Controls
The two built-in definitions that form the foundation of a UK Azure deployment are e56962a6-4747-49cd-b67b-bf8b01975c4c (“Allowed locations”) and e765b5de-1225-4ba3-bd56-1ac6695af988 (“Allowed locations for resource groups”). The first denies resource creation outside permitted regions at the ARM management plane, before the resource exists. The second applies the same constraint to resource groups. A UK lockdown built on these two alone has gaps that will surface in any serious compliance review, and the most consequential one is also the least obvious.
The “Allowed locations” policy runs in Indexed mode, which explicitly excludes resources that carry a location value of global. Azure Front Door profiles, Traffic Manager endpoints, DNS zones, Entra ID, Defender for Cloud configuration objects, classic CDN profiles, and Azure Arc registrations all use the global location field and pass the policy regardless of where their data plane operates. You must include global in your permitted values list, otherwise every deployment of a non-regional resource fails. Once you include it, you have allowed a class of resource whose data flows you cannot constrain through location policy. This is a design boundary, not a policy flaw, and the correct response is to document it explicitly and control those resource types through service-specific configuration rather than expecting policy to do work it was not designed to do.
The second gap is more operationally dangerous. Azure Policy evaluates ARM API calls. Configuration changes made through service-internal control planes bypass policy evaluation entirely. Microsoft’s own SQL documentation states plainly that Azure policies are not enforced when a database is created or modified via T-SQL. An Azure SQL geo-replica added through a database connection, a Log Analytics continuous export configured through the diagnostic blade without touching ARM, a Cosmos DB region added through the SDK: none of these trigger the deny effect. You need audit policies running alongside your deny policies, and diagnostic settings that surface control-plane gaps. Prevention alone is not sufficient.
Assignment scope is where estates most commonly drift. Policy assigned at subscription level is bypassed the moment a new subscription is created outside that scope. Assign at the Tenant Root Management Group or the top-level management group directly below it, with enforcementMode: Default and effect: Deny. Run a monthly audit on Microsoft.Authorization/policyExemptions. Exemptions granted for short-term purposes and then forgotten are the most reliable mechanism through which compliant estates become non-compliant ones.
The Sovereign Landing Zone: What It Gives You, and What It Leaves Out
The Azure Sovereign Landing Zone is an opinionated overlay on the standard Azure Landing Zone, delivered as Bicep from the Azure/sovereign-landing-zone GitHub repository. The first thing to know about it is that the repository is scheduled for archival in the first half of 2026. Microsoft is consolidating sovereign guidance into the Cloud Adoption Framework’s Sovereign Cloud documentation. Architects deploying today should extract the policy initiatives into their own ALZ rather than taking a long-term dependency on the orchestration scripts.
What the SLZ actually contributes is the Sovereignty Baseline policy initiative, grouping controls into five objectives covering data residency, customer-managed keys, confidential computing, and trusted launch. The architectural decision that most architects initially misread is the two-tier management group structure. The SLZ inserts “Confidential corp” and “Confidential online” management groups below the standard landing zones tier and applies separate location and confidential computing policies to them. The reason is practical: confidential computing VM SKUs have more limited regional availability than general-purpose compute, so you cannot apply the same allowed-locations policy across the whole estate without blocking legitimate workloads. The split lets architects require hardware-encrypted execution for sensitive workloads without constraining everything else.
The gaps are where the real design work sits. Customer Lockbox cannot be enforced through policy and must be enabled manually at tenant level by a Global Administrator. PIM configuration for the confidential-scope management groups is not deployed. Diagnostic settings are not universally enforced. Entra ID data location is entirely outside the SLZ’s control plane. Network egress to non-UK PaaS endpoints must be controlled separately through Private Endpoint policy and Azure Firewall FQDN rules. Deploying the SLZ and considering residency complete is like laying the foundations and calling the building finished.
The Services That Quietly Break Your Residency Assumption
This is where most post-deployment residency reviews spend their time, and the list is longer than most DPIAs account for.
Entra ID is the largest single gap, and the one that generates the most difficult conversation with information governance teams. The tenant directory and Core Store data for EMEA tenants reside in Amsterdam and Dublin, and related identity telemetry should be treated as outside a UK-only boundary unless Microsoft’s current Entra data-location documentation confirms otherwise for the specific log category. This is not configurable. It was set at tenant provisioning and cannot be changed. Setting the tenant country to “United Kingdom” in the admin portal does not move the data. The EU Data Boundary covers EMEA tenants, meaning the Netherlands and Ireland are within the boundary, which satisfies UK GDPR transfer requirements because both are EEA adequacy destinations. It does not satisfy a literal “all data in the UK” clause, which is a standard requirement in FCA-supervised outsourcing agreements and defence supply-chain accreditations. The correct action is to document this in the DPIA and disclose it to the DPO at design stage. Discovering it during an audit is a significantly worse outcome. The only route to UK-resident Entra ID Core Store data is through a Microsoft Cloud for Sovereignty engagement, which is not a standard Azure product.
Azure Monitor and Log Analytics are regional, and data ingested into a UK South workspace stays there contractually. The risks are operational. Auto-provisioned workspaces created during Sentinel onboarding or Defender for Cloud activation will not default to UK South unless the architect has pre-created the workspace and pointed the service at it. Log Analytics workspace replication, which reached general availability in 2024, must be configured to replicate to UK West rather than whatever secondary the platform suggests. Azure Monitor Agent ingestion follows the region of the Data Collection Rule, not the region of the monitored virtual machine, so a DCR deployed in the wrong region silently exports VM telemetry outside the UK. Enforce workspace location through policy and audit all Data Collection Rules quarterly.
Recovery Services vaults have a configuration decision that cannot be corrected after the first backup runs. New vaults default to geo-redundant storage, replicating asynchronously to the paired region. For UK South vaults, the paired region is UK West, which is acceptable for UK residency and should be the standard configuration. For workloads where any cross-region replication is prohibited, zone-redundant storage keeps three copies across UK South availability zones with no cross-region movement. The replication type is locked after the first backup job completes, making this a day-zero decision. Build the correct replication type into your landing zone template and it will never be an issue. Skip it and you will find it during an audit.
Azure Front Door is the most commonly misunderstood service in UK residency designs. Front Door operates 192 edge PoPs across 109 metros globally, including London. Content cached at the edge is served from the PoP nearest the requesting user, which means a German user receives cached content from Frankfurt and a South-East Asian user from Singapore. For most web workloads this is the intended behaviour. For regulated workloads where cached response bodies contain personal data, this constitutes a transfer. For OFFICIAL-SENSITIVE workloads, disable Front Door caching or use global routing without caching and a private origin. Architects who add Front Door to improve performance on a regulated application without considering the caching implications have introduced a residency gap that is particularly awkward to explain to a regulator.
Azure OpenAI is where AI-enabled UK workloads most frequently run into trouble. Azure OpenAI is available in UK South, but the critical distinction is between deployment types. Regional or Standard deployments keep inference requests within the specified region. DataZone deployments process within Microsoft’s defined data zone, currently US or EU, which means DataZone does not provide a UK-only boundary. Global deployments route to whichever available datacentre has capacity, which may be anywhere. For any workload covered by a DPIA requiring UK-only processing, the only safe option is a Regional or Standard deployment in UK South, subject to the required model being available there. Verify specific model availability in UK South before committing to the architecture, because availability by region changes as models are updated and older versions retired.
Encryption and Key Management: Choosing the Right Tier
Most Azure data services support customer-managed key encryption at rest across Storage, Azure SQL TDE, Cosmos DB, Service Bus, Event Hubs, Azure AI Search, and VM disks. The exception worth designing around is Log Analytics: CMK is supported only when the workspace is in a dedicated cluster, which requires a 500 GB per day minimum commitment tier. For estates below that threshold, Log Analytics CMK is not available.
Key Vault tier selection is where architects most frequently make decisions that are either over-engineered or under-specified. Standard tier uses software-protected keys with no HSM backing, appropriate for secret and certificate management in non-regulated workloads. Premium tier provides FIPS 140-2 Level 2 HSM-backed keys in a shared-tenant HSM infrastructure, costing roughly £0.755 per HSM-protected RSA key per month in UK South, plus operations charges. Managed HSM provides a single-tenant dedicated HSM cluster at FIPS 140-3 Level 3, billed continuously at approximately £2,700 per month per cluster, with no way to pause or suspend it.
The most common mistake is treating Managed HSM as the more-secure version of Premium Key Vault and deploying it uniformly because the compliance team asked for the strongest encryption. For almost all UK GDPR scenarios and FCA PS21/3 requirements outside specific PCI-PIN payment processing, FIPS 140-2 Level 2 is sufficient and Premium Key Vault delivers it at a fraction of the cost. Reserve Managed HSM for PCI-DSS environments requiring FIPS 140-3 Level 3 for key-encrypting keys, regulated payment processing with PCI-PIN scope, and NHS workloads at the SECRET classification boundary, which is rare in public Azure. Deploying Managed HSM across a 20-subscription estate without those requirements adds approximately £30,000 per year in platform cost with no corresponding compliance benefit.
Customer Lockbox is the access control that FCA, NHS, and NCSC assessors look for when they review operator-access governance, and it has an operational trap that is easy to miss. Lockbox must be enabled at tenant level by a Global Administrator and cannot be enforced through policy. Once enabled, approval requests route to Subscription Owners, Entra Global Administrators, or the dedicated Lockbox Approver role. The trap is this: if Subscription Owner is held as a PIM-eligible role (which it should be in any well-governed estate), the role must be activated before a Lockbox request arrives. For Customer Lockbox for Microsoft Azure, approval requests remain in the customer queue for four days before expiring. An approver whose role is not active when the request arrives cannot respond in time, the request expires, and the support engineer must re-request. Configure Lockbox Approver as a PIM-eligible assignment with an 8-hour activation window, route notifications to a monitored ITSM queue rather than an individual inbox, and create a Sentinel alert on Activity Log events for Set-AccessToCustomerDataRequest. That combination produces the audit trail that assessors want to see.
Confidential computing in UK South uses AMD SEV-SNP, providing hardware-based memory encryption that prevents hypervisor and host operators from reading VM memory. The DCasv6 and ECasv6 families (4th-generation AMD EPYC with SEV-SNP) are part of Azure’s current confidential VM portfolio; verify current UK South SKU availability against the live Azure region matrix before using them as a policy baseline, as regional rollouts change. Confidential VM pricing carries approximately a 10 to 15% premium over equivalent non-confidential Dv5 and Ev5 sizes. Apply confidential computing to workloads in the confidential-scope management groups rather than across the full estate. The SLZ’s dual-MG structure exists precisely to enable this distinction, and applying confidential VM requirements universally is how compute costs escalate without a corresponding compliance benefit.
For OFFICIAL-SENSITIVE workloads requiring the strongest available protection in standard public cloud, the layering is: platform-managed infrastructure encryption by default, customer-managed key at the service layer for encryption at rest, confidential disk encryption with CMK on a confidential VM for IaaS workloads covering encryption in use, and application-layer field encryption for the most sensitive data fields using SQL Always Encrypted or client-side blob encryption. All four layers on every resource is architectural overkill. Apply the full stack to workloads explicitly scoped as confidential, and use CMK at the service layer for the broader OFFICIAL estate.
The EU Data Boundary and the Brexit Gap
Microsoft completed the EU Data Boundary in February 2025, covering customer data, pseudonymised personal data, and professional services data across Microsoft 365, Dynamics 365, Power Platform, and most Azure services. The boundary commits to processing and storing that data within EU and EFTA member states.
The UK is neither an EU nor an EFTA member state. UK South and UK West are not formally inside the EU Data Boundary. In practice, Microsoft treats UK tenants as in-scope for the boundary’s residency benefits: Entra ID data for UK EMEA tenants lands in Netherlands and Ireland, Microsoft 365 customer data with UK tenancy is stored in UK datacentres, and support data follows the boundary framework. The formal contractual scope stops at EU and EFTA, and a regulator applying a literal reading can argue UK data is not covered by the boundary’s explicit commitments.
For most UK GDPR purposes this is workable because Netherlands and Ireland are EEA adequacy destinations. For FCA PS21/3 outsourcing obligations, the Netherlands and Ireland location of Entra ID Core Store data must appear explicitly in the firm’s operational resilience documentation and its cloud subprocessor register. For NHS DSPT requirements and any supply-chain contract imposing a “UK data only” clause, the EU Data Boundary framework does not close the gap. The right time to have that conversation with the information governance team is during the design phase, not during an audit.
Proving Operational Sovereignty to Auditors
The evidence chain that satisfies FCA PS21/3, NHS DSPT independent audit, and NCSC Cloud Security Principles 4 and 9 works as a sequence, and each control must produce evidence automatically rather than being assembled manually when an assessor requests it.
Azure Policy at management group scope provides the deny-time control, and saved Resource Graph queries produce the point-in-time compliance evidence: a query showing all resources with location outside permitted values, run at the point of audit, is the artefact that demonstrates the control is working. PIM-eligible role assignments with approval workflows and justification requirements provide the privileged access governance, with activation logs flowing to Sentinel. Customer Lockbox provides the operator-access gate, with approval and denial events in the Activity Log surfaced through a dedicated Sentinel analytic rule. Diagnostic settings on every subscription, Key Vault, Storage account, and Azure SQL instance export to the UK South Log Analytics workspace with the retention period your sector mandates. Sentinel correlates across all of these and alerts on policy-bypass attempts, Lockbox expiries, and privileged role activations outside approved patterns.
Just-In-Time VM access through Defender for Servers Plan 2 closes the RDP and SSH management surface without requiring a bastion host for every machine. JIT closes management ports by default and opens them for the requested duration to the requesting IP, with the request logged to the Activity Log. This satisfies the least-privilege, time-bounded, logged access requirement in NCSC Cloud Security Principle 9. Pair it with Conditional Access requiring a compliant device, MFA, and, where contractually required, a UK IP for privileged role activations.
The control matrix, mapping each control to its evidence source and the regulatory obligation it satisfies, is what turns an auditable Azure estate into a demonstrably auditable one. Platform architects who build the controls but do not document the evidence chain leave their compliance teams to reconstruct it under audit pressure. Build the register during the platform build, before the first regulated workload lands.
What the Sovereign Configuration Actually Costs
A well-scoped sovereign configuration adds approximately 15 to 25% to the platform cost of a comparable standard Azure Landing Zone deployment. The primary cost drivers are Key Vault Premium for CMK across production workloads, Defender for Cloud Plan 2 for JIT access and vulnerability assessment at roughly £11 per server per month, Log Analytics retention beyond the 31-day included tier at approximately £2.20 per GB ingested, and Azure Firewall Premium if the SLZ networking pattern is followed at around £1,000 per month. For a representative environment running 100 virtual machines across 10 to 20 subscriptions with 50 GB per day of Sentinel ingest, the sovereign control layer adds roughly £8,000 to £15,000 per month over baseline.
Adding Managed HSM pushes that premium to 30 to 40% of baseline, driven almost entirely by the £2,700 per month per cluster cost. Adding Confidential VMs across the full estate rather than the confidential-scope management groups adds 10 to 15% to the compute line. The SLZ’s dual-MG architecture exists to prevent this: apply the higher-cost controls where classification and regulatory obligation require them, and use the standard CMK-at-service-layer pattern for the rest.
The framing that generates the most productive conversation with finance and risk stakeholders is straightforward. The cost of sovereign controls is predictable, bounded, and architecturally controllable. The cost of an ICO enforcement notice, an FCA supervisory letter, or a failed supply-chain accreditation is none of those things. For the annual cost of Managed HSM across a 20-subscription estate, you can run the architecture review that determines you do not need it. That review is worth running before the infrastructure is deployed, not after the budget has been committed.
Implementation Roadmap
The first three months are about establishing the policy and governance foundation before any regulated workload lands. Deploy the management group hierarchy at tenant root scope, assign the allowed locations initiative with UK South, UK West, and global as permitted values, enable Customer Lockbox at tenant level, and create the UK South Log Analytics workspace. Before switching location policy to Deny effect, run it in Audit mode and remediate non-compliant resources. Enable PIM-eligible assignments for Subscription Owner, Contributor, and Key Vault Administrator roles across all production scopes.
From month four through nine, the focus is encryption and access control. Deploy Key Vault Premium across production subscriptions with CMK enabled for Storage, Azure SQL TDE, and Cosmos DB. Configure Customer Lockbox approval routing to ITSM. Enable JIT VM access through Defender for Servers Plan 2 and deploy Sentinel with analytic rules covering policy bypass, Lockbox events, and PIM activations. Review Azure OpenAI deployment types on any AI workloads and migrate from Global to Regional where the DPIA requires UK-only processing.
The third phase, from month ten through eighteen, covers confidential computing and audit maturity. Deploy the confidential-scope management groups, apply the confidential computing policy baseline to them, and migrate high-sensitivity workloads to Confidential VMs with CMK disk encryption. Establish scheduled Resource Graph compliance exports as audit evidence artefacts. Conduct the first internal operational resilience test against the FCA PS21/3 impact-tolerance scope, documenting the cloud platform dependency chain. If NHS DSPT mandatory independent audit applies, commission it in this phase. Review the Entra ID data location gap against any contractual “UK only” clauses and engage Microsoft on Cloud for Sovereignty options if the gap cannot be accepted as a documented residency exception.
The Architecture Is Buildable. The Risks Are in the Defaults.
For most UK regulated environments, the right answer is not a dedicated sovereign cloud product. It is a standard Azure deployment in UK South and UK West with a Sovereign Landing Zone policy baseline, Premium Key Vault CMK encryption, Customer Lockbox, PIM-gated privileged access, and a diagnostic-to-Sentinel pipeline covering every service. That combination satisfies UK GDPR, FCA PS21/3, NHS DSPT Version 8, and NCSC Cloud Security Principles across the full OFFICIAL classification tier.
Three decisions account for the majority of residency failures in production Azure deployments. The first is assuming location policy covers everything when it explicitly does not cover global-scoped resources or services configured through internal control planes. The second is choosing Managed HSM because it sounds more secure without verifying that FIPS 140-3 Level 3 is actually required by the workload’s regulatory obligation. The third is failing to document the Entra ID Core Store gap before a contract review or audit surfaces it as a finding. Address all three at design stage. The gaps are documented, the controls are available, and the audit chain is buildable. The only thing that makes this difficult is discovering it after deployment rather than before.
Useful Links
- Azure Sovereign Landing Zone GitHub repository – Reference Bicep implementation (archiving H1 2026)
- Microsoft Cloud Adoption Framework: Sovereign Cloud – Forward guidance post-SLZ archival
- Azure Policy built-in definitions reference – Official policy definition catalogue
- Customer Lockbox for Microsoft Azure – Configuration, approval workflow, and audit guidance
- EU Data Boundary documentation – Scope, commitments, and completion status
- Azure confidential VMs FAQ – SEV-SNP and TDX regional availability
- Azure Backup reliability and geo-redundancy – Vault replication configuration and paired-region behaviour
- Entra ID data storage by tenant country – Core Store geography mapping for UK tenants
- Microsoft Sentinel data residency – Regional availability and data boundary behaviour
- Azure Key Vault pricing – Standard, Premium, and Managed HSM tiers in GBP
