SOC 2 on Microsoft Azure: shared responsibility and mapping native services to controls
Azure holds its own SOC 2 as your platform provider, but the controls an auditor tests are the ones you configure in your tenant. Here is how Azure's native services map to the Trust Services Criteria.
Azure's SOC 2 covers the platform, not your tenant
Microsoft publishes SOC 1, SOC 2 Type 2, and SOC 3 reports for Azure, covering the physical infrastructure, hardware lifecycle, and the platform fabric Microsoft operates. In your own SOC 2, Azure is a subservice organization: its report demonstrates the security of the platform, while your controls govern what you build inside your subscriptions and tenant. Deploying on Azure does not make you compliant, and an auditor will not credit Microsoft's report against your own criteria. They will test how you configured identity, networking, encryption, and monitoring in your environment, which is the layer that fails audits when neglected.
The Azure shared responsibility split
Microsoft groups responsibilities into provider-managed, shared, and customer-managed categories that shift with the service tier. Physical security and hardware are always Microsoft's; network configuration and encryption implementation are shared, meaning Microsoft supplies the capability but you must turn it on and configure it correctly; and access management, data classification, and application security are always yours. With IaaS like virtual machines you also own guest OS patching and endpoint hardening, while PaaS offerings such as App Service or Azure SQL shift more to Microsoft. Writing down which side each Common Criteria control lands on, before fieldwork, helps you explain the boundary to an auditor instead of assuming the Azure report covers it.
Mapping native services to Trust Services Criteria
Azure's security stack maps tightly to the Common Criteria. Microsoft Entra ID, the identity service formerly called Azure Active Directory, anchors logical access under CC6 through RBAC, Conditional Access policies that evaluate device, location, and risk, and Privileged Identity Management for just-in-time, approval-gated admin role activation. Azure Monitor with Log Analytics and the Entra and activity logs covers the logging and detection expectations of CC7. Azure Key Vault, with managed identities so applications avoid stored credentials, underpins secrets and encryption-key management. Microsoft Defender for Cloud delivers continuous posture assessment and threat detection, and its regulatory-compliance dashboard maps findings against a SOC 2 initiative built on Azure Policy. Azure Policy enforces configuration guardrails, and Azure Backup with tested restores supports availability if scoped in.
Carving out Azure in your report
Azure-native companies almost always use the carve-out method: your system description names Microsoft Azure as a subservice organization and excludes Microsoft's controls from your auditor's testing, because Microsoft will not be examined by your auditor. Carve-out requires you to document the controls you rely on Azure to perform, the complementary subservice organization controls relevant to your system, and your own monitoring of Microsoft as a vendor. In practice, download Azure's SOC 2 report from the Service Trust Portal at least annually, review it for exceptions and confirm the period aligns with your audit window, and retain evidence of the review. Where Microsoft's report period does not fully overlap yours, a bridge letter covers the gap, and auditors routinely check that this oversight step was actually performed.
Practical guidance for Azure-native teams
Start with identity, since it is where Azure audits most often stumble: enforce MFA through Conditional Access, restrict standing admin access via PIM, and review Entra role assignments and access packages on a regular cadence. Assign the SOC 2 standard in Defender for Cloud's regulatory-compliance dashboard so posture is continuously scored against the criteria, and use Azure Policy initiatives to enforce encryption, diagnostic logging, and network restrictions across subscriptions. Microsoft Purview Compliance Manager offers a prebuilt SOC 2 assessment that pulls evidence from Defender for Cloud, Azure Policy, and Entra ID, which reduces manual collection. Because a Type 2 examination tests operating effectiveness over a window of months, aim for stable, drift-free configuration sustained across the period rather than a last-minute cleanup before fieldwork.