Azure in Your SOC 2 Scope

Engineering teams running workloads on Microsoft Azure face the same SOC 2 requirements as AWS teams — but with a different set of tools and configuration patterns. Whether you're fully Azure, Azure alongside AWS, or migrating between clouds, your compliance controls need to match your actual infrastructure.

This guide covers the Azure-specific controls that map to SOC 2 Trust Service Criteria, what auditors check, and how to configure them.

1. Enable Microsoft Defender for Cloud

Defender for Cloud is Azure's security posture management and threat detection service — the Azure equivalent of AWS GuardDuty and Security Hub combined. For SOC 2, it's the primary mechanism for CC7.1 (threat detection) and CC5 (control monitoring).

Enable Defender for Cloud on every subscription in scope:

Azure Portal → Microsoft Defender for Cloud → Environment Settings → [Subscription] → Enable Defender plans

Enable at minimum:

• Defender for Servers — threat detection for VMs
• Defender for Storage — detects unusual access patterns and malware in Blob Storage
• Defender for Databases — detects SQL injection, anomalous access
• Defender for Key Vault — detects unusual key vault access

Review Security Score in Defender for Cloud — it maps directly to CIS and Azure Security Benchmark controls. For SOC 2, target a Security Score above 80%.

SecureSpect check: azure.defender.plans_enabled — verifies Defender plans are active on in-scope subscriptions.

2. Azure Storage Security

Azure Blob Storage security controls map directly to SOC 2 CC6.7 (encryption) and CC6.1 (access control).

Require HTTPS (TLS) only:

az storage account update \
  --name YOUR_STORAGE_ACCOUNT \
  --resource-group YOUR_RG \
  --https-only true \
  --min-tls-version TLS1_2

Disable public blob access account-wide:

az storage account update \
  --name YOUR_STORAGE_ACCOUNT \
  --resource-group YOUR_RG \
  --allow-blob-public-access false

Enable soft delete for blob recovery:

az storage account blob-service-properties update \
  --account-name YOUR_STORAGE_ACCOUNT \
  --resource-group YOUR_RG \
  --delete-retention-days 30 \
  --enable-delete-retention true

Enable infrastructure encryption (double encryption): Enabled at storage account creation — cannot be changed afterwards. Enable for new accounts storing sensitive customer data.

3. Azure Key Vault — Secrets and Encryption

Key Vault is Azure's equivalent of AWS KMS + Secrets Manager. For SOC 2:

• All storage encryption keys should use Customer Managed Keys (CMK) stored in Key Vault
• Application secrets (database passwords, API keys) should be stored in Key Vault, not in environment variables or code
• Enable soft delete and purge protection on all Key Vaults storing critical keys or secrets

# Enable soft delete and purge protection (cannot be disabled once enabled)
az keyvault update \
  --name YOUR_KEY_VAULT \
  --resource-group YOUR_RG \
  --enable-soft-delete true \
  --enable-purge-protection true

Enable Key Vault logging (diagnostic settings → Azure Monitor) to capture all access events. This is your CC7.2 evidence for Key Vault.

4. Azure Activity Log — Equivalent of CloudTrail

Azure Activity Log records all management-plane operations (creating resources, changing settings, deleting subscriptions). For SOC 2 logging controls:

Export Activity Log to a Storage Account or Log Analytics Workspace for retention:

Azure Monitor → Activity Log → Export Activity Logs → Diagnostic Settings

Configure:

• Destination: Storage Account (for retention) + Log Analytics (for querying)
• Retention: Minimum 365 days
• Categories: Administrative, Security, Alert, Policy

Alert on high-risk operations using Azure Monitor Alerts:

• Creation or deletion of Key Vault secrets
• Role assignment changes at subscription scope
• Network Security Group rule changes

5. Network Security Groups (NSGs) — Least Privilege

NSG rules control traffic to Azure VMs, subnets, and services. For SOC 2:

• No NSG rule should allow inbound traffic from 0.0.0.0/0 (any internet) to sensitive management ports (SSH/22, RDP/3389, database ports)
• Use Azure Bastion for SSH/RDP access instead of opening ports directly
• Document exceptions with business justification

# Audit NSGs for overly permissive rules
az network nsg list --query "[].{Name:name,RG:resourceGroup}" --output table
# Check rules for a specific NSG
az network nsg rule list \
  --nsg-name YOUR_NSG \
  --resource-group YOUR_RG \
  --query "[?access=='Allow' && direction=='Inbound' && sourceAddressPrefix=='*']" \
  --output table

SecureSpect + Azure

SecureSpect connects to Azure via App Registration with client-credentials OAuth2 — a service principal with Reader and Security Reader roles on in-scope subscriptions. No persistent credentials stored. SecureSpect checks Defender for Cloud findings, storage account security settings, Key Vault configuration, and NSG rules — all mapped to SOC 2 Trust Service Criteria.