Azure Compliance, Sovereignty & Regulated Cloud: Compliance Manager, Frameworks & Data Residency

Every architecture decision you have made so far in this course has had a technical owner you could argue with — a latency budget, a cost ceiling, an SLA. Compliance is different. When a bank’s regulator, a hospital’s auditor, or a government accreditor asks “prove that cardholder data never left the country, that only named administrators can decrypt it, and that you can show me the control evidence on demand,” there is no clever workaround. You either have the controls, the residency, and the evidence — or you fail the audit, and the workload does not ship. Regulated cloud is the discipline of turning legal and contractual obligations into Azure configuration you can demonstrate, repeatedly, to someone whose job is to disbelieve you.

This lesson is the senior architect’s map of that territory. We will separate three ideas that beginners constantly merge: compliance (am I meeting a named control framework?), residency (where does my data physically sit and get processed?), and sovereignty (who — under whose laws and whose keys — can actually compel access to it?). You will learn to drive Microsoft Purview Compliance Manager to turn a framework into a scored, tracked work plan; to apply the Azure Policy regulatory-compliance initiatives so the estate audits itself continuously; to choose between regions, sovereign clouds, and confidential computing for residency and key sovereignty; and to produce the audit evidence packs that close the loop. This is exam-relevant ground for both AZ-305 (designing governance) and SC-100 (designing for regulatory compliance), and it is the difference between a cloud that is compliant and one that can merely claim to be.

Learning objectives

By the end of this lesson you can:

• Distinguish compliance, data residency, and sovereignty, and explain the Microsoft shared-responsibility model as it applies to each.
• Drive Microsoft Purview Compliance Manager — assessments, templates, controls (Microsoft-managed vs your-managed), improvement actions, and the compliance score — to run a regulated estate as a tracked work plan.
• Apply and read the Azure Policy regulatory-compliance built-in initiatives, and state in one line what ISO 27001, PCI-DSS, HIPAA/HITRUST, NIST 800-53, CMMC, and FedRAMP each are.
• Choose correctly between regions, region pairs, sovereign/government clouds (Azure Government, Azure operated by 21Vianet) and EU Data Boundary for data-residency requirements.
• Design key sovereignty using customer-managed keys (CMK), Azure Key Vault Managed HSM, confidential computing, and Azure confidential ledger, and reason about lockbox and operational access.
• Assemble an audit evidence pack from the Service Trust Portal, Compliance Manager, the Defender for Cloud regulatory compliance dashboard, and Azure Policy compliance exports.

Prerequisites

You should be comfortable with the Azure resource hierarchy (management group → subscription → resource group → resource) and with Azure Policy at the level of definitions, initiatives, effects and remediation — if that is fuzzy, read Azure Policy as Code and Entra RBAC & Governance Deep Dive first. Helpful but not required: the Zero-Trust multi-layer model and Key Vault & Workload Identity, both of which supply controls this lesson will audit. This is the Governance specialisation in the Azure Zero-to-Hero course; it assumes you can already build securely and now need to prove it to a regulator. For the lab you need a subscription where you hold Owner (to assign a policy initiative) and a Microsoft 365 / Purview tenant where you can open Compliance Manager (a trial tenant is sufficient — Compliance Manager’s premium templates need a qualifying licence, but the included Microsoft Data Protection Baseline is enough for the walkthrough).

Core concepts: compliance vs residency vs sovereignty

These three words are used interchangeably in casual conversation and they must never be in an architecture review. They answer different questions, are satisfied by different mechanisms, and fail audits for different reasons.

The relationship is a hierarchy of strictness. Residency is a subset concern of sovereignty: keeping data in-country (residency) does not by itself stop a cloud operator subject to foreign law from being compelled to hand it over — sovereignty additionally controls who can access and decrypt it. And compliance is the umbrella discipline that requires specific residency and sovereignty postures for specific data classes. A PCI assessment cares about cardholder-data segmentation and encryption; a German public-sector mandate may additionally require the keys to be outside Microsoft’s unilateral control. Architect for the strictest applicable requirement, not the loosest.

The shared-responsibility line, restated for compliance

Compliance inherits Azure’s shared-responsibility model. Microsoft is responsible for, and independently audited on, the security and compliance of the cloud — physical datacentres, the host hypervisor, the global network. You are responsible for security and compliance in the cloud — your data classification, identities, network controls, encryption choices, and crucially the evidence that you configured them. This split is why Compliance Manager distinguishes Microsoft-managed controls (inherited — Microsoft has already done and evidenced them) from your-managed controls (your work). Buying Azure inherits a large slice of any framework for free; it never inherits all of it, and an auditor will only credit you for the inherited part once you point to Microsoft’s attestation.

Microsoft Purview Compliance Manager

Compliance Manager (in the Microsoft Purview / Microsoft 365 compliance portal) is the tool that turns a control framework from a 300-page PDF into a scored, assignable, evidenced work plan. It is the single most useful instrument for managing — as opposed to merely achieving — compliance, and it is where a regulated programme should live day-to-day.

The object model

The flow is: pick a template → it creates an assessment containing controls → each control maps to one or more improvement actions → you work the actions (assign an owner, implement, attach evidence, mark tested) → the score rises. Microsoft-managed actions are already complete and contribute their points automatically with Microsoft’s audit evidence behind them; your-managed actions are your backlog.

The compliance score, and how to read it honestly

The score is risk-weighted, not a simple task count. Each improvement action carries points scaled by whether the control is preventative / detective / corrective and mandatory / discretionary — a preventative, mandatory control (e.g. enforce MFA) is worth far more than a discretionary detective one. This is deliberate: it pushes you toward the controls that actually reduce risk.

The senior caveat, stated plainly: a high Compliance Manager score is a management aid, not a certification. It tells you how much of the control set you have implemented and evidenced in Microsoft’s model; it does not mean an external auditor has signed off, and it does not by itself make you “ISO 27001 certified.” Certification still requires an accredited third-party auditor. Treat the score as your internal readiness gauge and the thing that makes the auditor’s visit short — never as the certificate itself. Stating this distinction correctly is a common interview discriminator.

Improvement actions in practice

Each improvement action is a small workflow: owner, status (not started / in progress / implemented / tested), implementation notes, a test plan, and evidence attachments (screenshots, exported policy reports, config snapshots). The discipline that separates a passing programme from a failing one is attaching evidence at the moment of implementation, not scrambling for it the week before the audit. Compliance Manager becomes the durable record: when the auditor asks “show me control AC-2,” you open the action, and the evidence, owner, date, and test result are all there.

Azure Policy regulatory-compliance initiatives

Compliance Manager tracks the programme; Azure Policy regulatory-compliance initiatives make the Azure estate itself report continuously against a framework. Microsoft ships large built-in initiative definitions — one per major standard — where each initiative bundles dozens to hundreds of policy definitions, each mapped to a specific control in that standard. Assign the initiative at a management group or subscription, and Azure evaluates every in-scope resource and produces a per-control compliance percentage that flows straight into the Defender for Cloud regulatory compliance dashboard.

A crucial nuance: most controls in these built-in initiatives use the AuditIfNotExists effect, meaning they report non-compliance rather than block it. That is the right default for a regulatory overlay — you want visibility across the whole estate first, then you selectively tighten specific controls to Deny or add DeployIfNotExists remediation once you understand the blast radius. (Some controls are “Manual” — they cannot be machine-evaluated and require an attestation that you have done them out-of-band.)

Here is what each headline framework is, in one line — the kind of crisp definition an interviewer or exam expects:

Also commonly assigned: SOC 2 (a Microsoft attestation you inherit rather than a policy you run), CIS Microsoft Azure Foundations Benchmark (a hardening baseline that doubles as a great starting initiative), the Microsoft Cloud Security Benchmark (MCSB) — assigned by default to every subscription via Defender for Cloud — and regional standards (UK OFFICIAL, Australia ISM/IRAP, Germany C5, India MeitY). You do not implement these from scratch; you assign the built-in initiative, read the dashboard, and remediate the gaps.

Sovereign clouds & data residency

Now the where. Azure’s default footprint is the public cloud — 60-plus regions worldwide. For most workloads, choosing a region inside the required jurisdiction (plus a same-geography region pair for DR) satisfies residency, because Microsoft commits that customer data for most services stays within the selected geography. But several requirements push beyond region choice into isolated sovereign clouds or data-boundary commitments.

The architecture consequences of an isolated cloud are real and easy to under-estimate: separate ARM endpoints and portals, a separate Entra tenant boundary, feature and region lag (not every service or SKU lands in a sovereign cloud day-one), and no implicit connectivity to the public cloud. The classic residency mistake is not the primary region at all — it is a dependency that quietly crosses the boundary: a geo-redundant backup replicating to a paired region in another country, GRS storage, a global service with a non-regional control plane, diagnostic logs shipped to a workspace in the wrong region, or a CDN/Front Door edge caching content outside the jurisdiction. Audit the data-flow graph, not just the compute.

Residency design rule: pin residency at every layer — choose in-jurisdiction regions, prefer LRS/ZRS over GRS (or pick a paired region inside the boundary), keep Log Analytics, Backup vaults, and Recovery Services vaults in-region, and verify that each PaaS service you use stores customer data regionally. Use Azure Policy “allowed locations” and “allowed locations for resource groups” to enforce it, so a future engineer cannot deploy into the wrong geography by accident.

Key sovereignty: who can decrypt

Residency answers where the bytes sit; key sovereignty answers the harder question — who can turn the ciphertext back into plaintext, and can anyone compel them? This is the deepest layer of sovereignty and the one regulators in the most sensitive sectors care about most.

By default, Azure encrypts data at rest with Microsoft-managed keys — strong, free, zero-effort, but Microsoft holds the keys. The sovereignty ladder climbs from there:

The decisive architectural lever for sovereignty is CMK + Managed HSM: when you hold the key in a single-tenant HSM, Microsoft cannot decrypt your data on its own, and you can prove cryptographic control to a regulator. Layer Customer Lockbox to gate the human path (no Microsoft engineer touches your data during support without your click), and reach for confidential computing when “encrypted at rest and in transit” is not enough and the regulator demands “encrypted in use” so the operator cannot read memory even while processing. Together these close the three windows — at rest (CMK/HSM), in transit (TLS), and in use (TEE) — and convert “trust us” into “you hold the keys.”

A non-negotiable companion control: with CMK you now own key lifecycle. Enable soft-delete and purge protection on the key vault, automate rotation, replicate/back up the key material appropriately, and tightly RBAC key-management roles — because if you lose the key, the data is gone, permanently and by design. Sovereignty and self-inflicted data loss share the same switch.

The diagram ties the layers together: the framework-and-evidence plane (Compliance Manager assessments, score, audit evidence) sitting above the Azure control plane (Policy regulatory initiatives feeding the Defender for Cloud regulatory dashboard), with residency (region/region-pair/sovereign cloud, EU Data Boundary) and key sovereignty (CMK → Managed HSM → confidential computing, gated by Customer Lockbox) as the two pillars holding it up.

Audit evidence & the Defender for Cloud regulatory dashboard

Compliance is a verb only when you can prove it. The final discipline is assembling, on demand, an evidence pack that an external auditor will accept. Azure gives you four sources, and a mature programme draws from all four:

The Defender for Cloud regulatory compliance dashboard is the centrepiece for the Azure technical estate. Defender for Cloud always assigns the Microsoft Cloud Security Benchmark by default; you then add standards (the same regulatory initiatives — PCI-DSS, ISO 27001, NIST 800-53, CIS, sovereign baselines, etc.) and the dashboard renders each standard as a tree of controls, each showing the passing/failing resource counts drawn from the underlying Azure Policy assessments. From there you can drill into a failing control, see the exact resources and the remediation, and — critically for audits — download a compliance report (PDF / CSV) per standard as a point-in-time attestation. Note that the regulatory compliance dashboard’s depth is a Defender CSPM (paid plan) capability; the free tier shows the MCSB but not the full multi-standard experience.

The evidence pack an auditor actually wants is the join of these: Microsoft’s attestations from the Service Trust Portal for the inherited controls, your Compliance Manager evidence for the controls you own, the Defender for Cloud regulatory report showing the live technical state, and a Policy compliance export showing it resource-by-resource — all dated, all owned, all reproducible. Build the pipeline that produces this on a schedule, and the audit becomes a review of artefacts you already have rather than a fire drill.

Hands-on lab

We will (1) open Compliance Manager and read an assessment, (2) assign a regulatory-compliance initiative to a subscription via the az CLI, (3) view it in the Defender for Cloud regulatory dashboard, and (4) export evidence — then clean up. Everything here is free-tier-friendly; the only paid surface (full Defender CSPM dashboard depth) is optional and called out.

Prerequisites: az logged in (az login), Owner on a test subscription, and access to the Microsoft Purview / Microsoft 365 compliance portal.

Step 1 — Read an assessment in Compliance Manager

1. Go to the Microsoft Purview compliance portal → Compliance Manager.
2. Open the default Microsoft Data Protection Baseline assessment (included with any tenant).
3. Note the compliance score, then open Improvement actions. Pick one your-managed action (e.g. “Enable multi-factor authentication”) and read its points, test plan, and status. This is the unit of work you would assign, implement, and attach evidence to.

Step 2 — Find and assign a regulatory-compliance initiative

List the built-in regulatory initiatives, then assign one (we use the CIS Microsoft Azure Foundations Benchmark — broad, audit-only, safe):

# Discover built-in regulatory-compliance initiatives
az policy set-definition list --query "[?policyType=='BuiltIn'].{name:displayName, id:name}" -o table \
  | grep -iE "CIS|ISO|PCI|NIST|HIPAA|FedRAMP|HITRUST|CMMC"

SUB=$(az account show --query id -o tsv)

# Grab the CIS Azure Foundations Benchmark initiative definition id
INIT=$(az policy set-definition list \
  --query "[?contains(displayName,'CIS Microsoft Azure Foundations Benchmark')].id | [0]" -o tsv)

# Assign it at the subscription scope (audit-only by default)
az policy assignment create \
  --name "cis-regulatory" \
  --display-name "CIS Azure Foundations (regulatory)" \
  --policy-set-definition "$INIT" \
  --scope "/subscriptions/$SUB"

Expected: the assign command returns the assignment JSON with "scope": "/subscriptions/<id>". Azure now evaluates your resources against the CIS control set (evaluation can take up to ~30 minutes for the first full pass).

Step 3 — Validate compliance state

# Trigger an on-demand compliance scan (optional; speeds up the first pass)
az policy state trigger-scan --subscription "$SUB"

# Summarise compliance once evaluation completes
az policy state summarize --subscription "$SUB" \
  --query "results.{nonCompliant:nonCompliantResources, policies:nonCompliantPolicies}"

Then open Microsoft Defender for Cloud → Regulatory compliance. The Microsoft Cloud Security Benchmark is already there; use Manage compliance policies / Add standard to confirm CIS now appears, and expand a control to see passing/failing resource counts. (Full multi-standard drill-down requires Defender CSPM; the assignment and Policy data exist regardless of plan.)

Step 4 — Export evidence

• In Defender for Cloud → Regulatory compliance, use Download report to export a point-in-time PDF/CSV for a standard — this is an audit artefact.
• From the CLI, export per-resource Policy compliance:

az policy state list --subscription "$SUB" \
  --query "[?complianceState=='NonCompliant'].{resource:resourceId, policy:policyDefinitionName}" \
  -o tsv > policy-evidence.csv

Cleanup

az policy assignment delete --name "cis-regulatory" --scope "/subscriptions/$SUB"
rm -f policy-evidence.csv

The Compliance Manager assessment is read-only here — nothing to delete. No resources were created.

Cost note (INR): the entire lab is free. Azure Policy assignments, evaluation, and the Policy compliance API cost nothing. The Defender for Cloud regulatory compliance dashboard’s MCSB view is free; the full multi-standard dashboard needs Defender CSPM (paid). If you opt to trial paid Defender CSPM, pricing is roughly ₹1.25–1.7 per billed resource per hour-equivalent (a few hundred resources runs into low single-digit thousands of rupees per month) — enable it on one test subscription, screenshot the dashboard, and disable it the same day to keep spend near zero. Compliance Manager’s premium templates require a qualifying Microsoft 365/Purview licence; the included baseline used above does not.

Common mistakes & troubleshooting

Best practices

• Architect for the strictest applicable requirement. Classify data first, then map each class to its residency, sovereignty, and framework obligations — and build to the toughest one, not the average.
• Run compliance as code where you can. Assign regulatory initiatives at the management group so new subscriptions inherit them; pair with allowed-locations and required-tag policies so the estate is born compliant.
• Inherit deliberately. Pull Microsoft’s attestations from the Service Trust Portal for every Microsoft-managed control and reference them — do not re-evidence what you inherit, but do claim it.
• Attach evidence at implementation time in Compliance Manager, with an owner and a date. The programme’s durability lives here, not in a pre-audit scramble.
• Pin residency at every layer (region, backup, logs, CDN, paired region) and enforce it with Policy, not convention.
• Separate duties: the people who implement controls should not be the only people who attest to them; give auditors read access to Defender for Cloud and Compliance Manager directly.
• Schedule the evidence pipeline. Export Policy/Defender reports on a cadence into immutable storage so a point-in-time attestation always exists.

Security notes

Compliance and security are not the same thing — you can be compliant and insecure, or secure and unable to prove it — but the controls overlap heavily and the strongest are sovereignty-grade. Treat key sovereignty as the crown jewels: when a framework or jurisdiction demands cryptographic control, CMK in Managed HSM plus Customer Lockbox plus, where mandated, confidential computing is the posture that lets you say truthfully that Microsoft cannot unilaterally decrypt your data. Guard the key lifecycle as fiercely as the keys themselves — soft-delete, purge protection, rotation, least-privilege RBAC on key operators, and tested key backup — because in this model losing the key is losing the data. Finally, remember that the regulatory compliance dashboard and Compliance Manager are sources of sensitive findings: scope access to them tightly, because a list of your failing controls is a roadmap for an attacker. Compliance evidence is itself an asset to be protected. (For the strategy-level treatment of designing this across an estate, see the SC-100 lesson linked in Next steps.)

Interview & exam questions

1. Define compliance, data residency, and data sovereignty, and explain how they relate. Compliance = meeting a named framework’s controls (and evidencing them); residency = where data is stored/processed; sovereignty = under whose laws/keys it can be compelled/accessed. Residency is a subset of sovereignty; compliance requires specific residency/sovereignty postures per data class. Architect to the strictest applicable.
2. What is the difference between a Microsoft-managed and a customer-managed control in Compliance Manager? Microsoft-managed controls are satisfied and evidenced by Microsoft under the shared-responsibility model (the security of the cloud) and contribute their points automatically; customer-managed controls are your responsibility (security in the cloud) and form your improvement-action backlog.
3. Does a high Compliance Manager score mean you are certified? No. The score is an internal, risk-weighted readiness gauge; formal certification (e.g. ISO 27001) requires an accredited third-party auditor. The score makes the audit shorter; it is not the certificate.
4. What does an Azure Policy regulatory-compliance initiative do, and why are most controls AuditIfNotExists? It bundles dozens/hundreds of policies mapped to a framework’s controls and reports a per-control compliance percentage to the Defender for Cloud dashboard. Audit-only is the safe default for an estate-wide overlay — you gain visibility first, then selectively tighten specific controls to Deny/DeployIfNotExists.
5. One line each: PCI-DSS, HIPAA, NIST 800-53, FedRAMP, CMMC. PCI-DSS protects cardholder data; HIPAA is US health-data law protecting PHI (HITRUST operationalises it); NIST 800-53 is the US federal control catalogue; FedRAMP is the US government cloud-authorisation programme (Moderate/High) built on 800-53; CMMC is tiered cyber-maturity certification for the US defence supply chain.
6. A workload must keep all data in Germany. You deploy to a German region — what could still violate residency? Geo-redundant backups or GRS storage replicating to a paired region in another country, a global service with a non-regional control plane, diagnostic logs shipped to a workspace elsewhere, or CDN/Front Door caching outside the boundary. Audit the data-flow graph; prefer LRS/ZRS or an in-boundary pair; enforce allowed-locations Policy.
7. When do you need Azure Government or Azure operated by 21Vianet rather than just a region? When isolation/operations sovereignty is required: Azure Government (isolated US cloud, screened US-person operations) for US federal/DoD/FedRAMP-High; 21Vianet (locally operated under Chinese law) for mainland China. Both bring separate endpoints/tenancy and feature/region lag.
8. How do you achieve key sovereignty so Microsoft cannot unilaterally decrypt your data? Use customer-managed keys in Key Vault Managed HSM (single-tenant, FIPS 140 L3) so you hold the keys; add Customer Lockbox to gate human operator access; use confidential computing (TEE) when “encrypted in use” is required. Manage key lifecycle (soft-delete, purge protection, rotation) rigorously.
9. What is Customer Lockbox and what does it not cover? It lets you approve or deny a Microsoft engineer’s access to your data during a support event. It covers the human operator access path, not cryptographic control — it is complementary to, not a substitute for, CMK/HSM.
10. Where do you assemble audit evidence on Azure? Service Trust Portal (Microsoft’s attestations for inherited controls), Compliance Manager (your improvement-action evidence), Defender for Cloud regulatory compliance dashboard (live per-control technical state, exportable reports), and Azure Policy compliance exports (resource-level state and history).
11. What is the Microsoft Cloud Security Benchmark’s role here? It is the baseline standard Defender for Cloud assigns to every subscription by default; it is both the secure baseline and a sensible first standard before layering specific regulatory initiatives.
12. Why might a control in a regulatory initiative never report compliant? It may be a “Manual” control Azure cannot machine-evaluate; it requires an out-of-band attestation with evidence rather than automated assessment.

Quick check

1. Which of compliance, residency, and sovereignty is concerned with who can be compelled to decrypt the data?
2. In Compliance Manager, which control type forms your backlog: Microsoft-managed or customer-managed?
3. What effect do most controls in a built-in regulatory initiative use, and why?
4. Name the mechanism that lets you hold encryption keys in a single-tenant FIPS 140 Level 3 device.
5. Which Defender for Cloud feature is assigned to every subscription by default and acts as the baseline standard?

Answers

1. Sovereignty — residency is only where the data sits; sovereignty governs who, under whose laws and keys, can access/decrypt it.
2. Customer-managed (your-managed) controls — Microsoft-managed controls are already satisfied and evidenced by Microsoft.
3. AuditIfNotExists — it reports rather than blocks, giving estate-wide visibility first before you selectively tighten controls to Deny/DeployIfNotExists.
4. Customer-managed keys in Azure Key Vault Managed HSM.
5. The Microsoft Cloud Security Benchmark (MCSB).

Exercise

Take one realistic regulated scenario — a fintech storing cardholder data for Indian and EU customers — and produce a one-page compliance design:

1. Classify the data and list the frameworks that apply (at minimum PCI-DSS; consider ISO 27001 and EU obligations).
2. Residency: choose regions and region pairs for India and the EU, decide on EU Data Boundary, and list every place a dependency could leak data out of jurisdiction (backups, logs, CDN, global services) with the mitigation for each.
3. Sovereignty/keys: specify the encryption posture — MMK vs CMK vs Managed HSM — and whether confidential computing or Customer Lockbox is warranted, with justification.
4. Continuous compliance: name the Azure Policy regulatory initiatives you would assign and at what scope, plus the allowed-locations enforcement.
5. Evidence: describe the evidence pack you would produce for a PCI assessor and where each artefact comes from (Service Trust Portal / Compliance Manager / Defender for Cloud / Policy export).

Compare your residency mitigations against the “Common mistakes” table — if you did not catch the GRS-backup and logs-location leaks, revisit the residency section.

Certification mapping

This lesson is the operational and design foundation those exams assume: AZ-305 and SC-100 ask you to choose the residency, sovereignty, and compliance posture and justify it; the mechanics here are what your answer is built from.

Glossary

• Compliance — the state of meeting, and being able to evidence, the controls of a named framework.
• Data residency — the requirement that data be stored and/or processed within a defined geography.
• Data sovereignty — control over whose laws and whose keys govern access to data; stricter than residency.
• Compliance Manager — Microsoft Purview tool that turns a framework into scored, assignable, evidenced improvement actions.
• Improvement action — the unit of compliance work (owner, status, test plan, evidence, points) in Compliance Manager.
• Compliance score — a risk-weighted percentage of controls implemented/evidenced; a readiness gauge, not a certification.
• Regulatory-compliance initiative — a built-in Azure Policy initiative bundling policies mapped to a framework’s controls.
• Microsoft Cloud Security Benchmark (MCSB) — Microsoft’s baseline security standard, assigned to every subscription by default.
• Sovereign cloud — an isolated cloud (e.g. Azure Government, Azure operated by 21Vianet) with separate endpoints, tenancy, and operations.
• EU Data Boundary — Microsoft’s commitment to store and process EU/EFTA customer data within the EU.
• Customer-managed key (CMK) — an encryption key you supply and control in Key Vault, which you can rotate and revoke.
• Managed HSM — a single-tenant, FIPS 140 Level 3 hardware security module pool for CMK with stronger custody.
• Customer Lockbox — a feature letting you approve/deny Microsoft-engineer access to your data during support events.
• Confidential computing — encryption of data in use inside a hardware trusted execution environment (TEE).
• Service Trust Portal — Microsoft’s repository of independent audit reports and certifications (evidence for inherited controls).
• Defender for Cloud — Regulatory compliance — a dashboard mapping live Azure Policy assessments to framework controls, with exportable reports.

Next steps

Continue the Governance & specialist track with Azure Specialized Compute: Dedicated Hosts, Spot, Confidential VMs, HPC & Batch — where the confidential VM and isolation mechanics referenced here are covered in depth at the compute layer. Then connect this to:

• SC-100: Cybersecurity Architect — Zero-Trust Strategy & Reference Designs — designing the regulatory-compliance and security strategy at architect altitude.
• Azure Policy as Code — shipping the regulatory initiatives and guardrails through a pipeline so compliance is enforced at deploy time.
• Azure Landing Zone & CAF — where management-group baselines and organisation-wide policy assignment make a whole estate compliant by construction.
• Eliminating Secrets: Key Vault & Workload Identity — the practical home of the CMK and key-lifecycle controls that underpin key sovereignty.