SOC 2 on Azure: controls and evidence
On Azure the SOC 2 access story lives in Microsoft Entra ID, the configuration story lives in Azure Policy, and the logging story lives wherever your diagnostic settings send the logs. Set retention before the window opens.
A SOC 2 on Azure needs production subscriptions under their own management group, MFA for everyone through Conditional Access, Privileged Identity Management for Owner and Contributor roles, diagnostic settings sending the Activity Log and Entra ID logs to Log Analytics with at least a year of retention, and an Azure Policy initiative assigned at the management group. The retention setting is the one to fix first, because it cannot be applied backwards.
Which SOC 2 criteria does Azure configuration answer?
As on any cloud, Azure configuration carries most of CC6 (access), CC7 (operations and monitoring) and CC8 (change), and the availability criteria if you include them. Governance, risk assessment, HR and vendor management come from outside Azure.
| Criterion | What it asks | Azure services involved |
|---|---|---|
| CC6.1 | Access restricted, data encrypted | Entra ID, Azure RBAC, Key Vault, storage and SQL encryption |
| CC6.2, CC6.3 | Access provisioned, changed and removed through a process | Entra ID groups, access packages, access reviews |
| CC6.6 | Boundary protection | Network security groups, Azure Firewall, private endpoints, Front Door WAF |
| CC6.7 | Data protected in transit | Minimum TLS settings, App Service HTTPS only |
| CC6.8 | Malicious software controls | Defender for Servers, Defender for Containers |
| CC7.1 | Configuration and vulnerability monitoring | Azure Policy, Defender for Cloud recommendations |
| CC7.2, CC7.3 | Anomaly detection and evaluation | Defender for Cloud alerts, Microsoft Sentinel if used |
| CC8.1 | Changes authorized and approved | Azure DevOps or GitHub pipelines, Activity Log for out-of-band changes |
| A1.2 | Backup and recovery | Azure Backup, geo-redundant storage, restore tests |
Access on Azure: Entra ID does most of the work
The evidence an auditor wants for access comes almost entirely from Entra ID. Conditional Access policies prove MFA. Group membership proves who has which role. Access reviews, a P2 feature, produce a dated record with the reviewer's decision on each user, which is the cleanest access review evidence of any provider.
- Standing admin access. Replace permanent Owner and Contributor assignments on production with eligible assignments in PIM. The activation history becomes the evidence of who had elevated access and why.
- Guest accounts. Review them. Old contractor guests with production roles are a common finding.
- Service principals. Inventory them, prefer managed identities, and expire client secrets.
- Break-glass accounts. Keep two, exclude them from Conditional Access by design, protect them with FIDO2 keys and alert on every sign-in.
Logging and retention on Azure
This is where Azure accounts most often fall short. The defaults are 90 days for the Activity Log and 30 days for Entra ID logs with a premium licence. Neither covers a six or twelve month Type 2 window. Create diagnostic settings at subscription level, or with Azure Policy so every subscription gets one, to send logs to a Log Analytics workspace with retention of at least 365 days, or to a storage account with an immutability policy.
| Log | Default retention | What to set |
|---|---|---|
| Activity Log | 90 days | Diagnostic setting to Log Analytics, 365 days or more |
| Entra ID sign-in and audit logs | 30 days (P1/P2), 7 days (free) | Diagnostic setting to the same workspace |
| Resource logs (Key Vault, SQL, storage) | Not collected until configured | Diagnostic settings through Azure Policy |
Configuration evidence with Azure Policy
Assign one initiative at the management group, usually the Microsoft cloud security benchmark that Defender for Cloud uses by default. Add a small number of deny policies for the controls you never want broken: allowed locations limited to Canada Central and Canada East, storage accounts without public access, minimum TLS 1.2. Deny policies produce the strongest evidence, because the auditor can see the control prevented the problem rather than reported it afterwards. Azure Policy and Defender for Cloud covers the initiative choices in more detail.
Change management on Azure
Deploy infrastructure with Bicep or Terraform through Azure DevOps or GitHub Actions, using a workload identity federated to the pipeline. Give that identity write access to production and give people read access plus PIM activation for emergencies. Every sampled change then has a pull request, and the Activity Log shows any change made by a person instead of the pipeline.
The Azure evidence request list
| Request | Source |
|---|---|
| Subscriptions and purpose | Management group hierarchy export |
| Users with production access | Role assignments per subscription, PIM eligible assignments |
| MFA enforcement | Conditional Access policy export |
| Access review | Entra ID access review results |
| Logging configuration | Diagnostic settings, workspace retention |
| Configuration compliance | Defender for Cloud regulatory compliance report |
| Backups | Backup policies, job history, restore test |
| Change samples | Pull requests and pipeline runs |
Do we need Entra ID P2 for SOC 2 on Azure?
Not strictly, but it makes access evidence much easier. P2 gives you Privileged Identity Management and access reviews, which produce dated, reviewer-attributed records. Without P2 you can do the same reviews by exporting role assignments to a spreadsheet and signing them off.
Is the Defender for Cloud regulatory compliance dashboard enough evidence?
It is good evidence for configuration controls. It says nothing about onboarding, training, vendor reviews or incident response, and auditors will still sample findings to see that they were acted on.
How should Microsoft be described in our SOC 2 system description?
As a subservice organization for Azure infrastructure, usually with the carve-out method, and separately for Microsoft 365 if you use it for email and documents. Your auditor relies on Microsoft's own SOC 2 reports from the Service Trust Portal.
Get quotes for SOC 2 on Azure
Landing zone, policy baseline and readiness from firms that work on Azure.
Get matched