SOC 2 Type II on Azure: Enforcing the Infrastructure Controls Auditors Test

Why the compliance dashboard turns red

Enterprise buyers often hold a contract until the vendor can show a SOC 2 Type II report. Compliance platforms like Vanta, Drata, and Secureframe are good at collecting evidence, but they do not fix the underlying infrastructure. When one is granted read access to an Azure tenant that grew without guardrails, the failing tests usually cluster around a few Trust Services Criteria:

• CC6.1, logical access. Developers hold permanent Owner rights on workload resource groups.
• CC6.6, boundary protection. Database endpoints and staging VMs have public IP addresses and no Network Security Group isolation.
• CC6.7, data transmission. Storage accounts accept HTTP traffic and legacy TLS 1.0 or 1.1 connections.
• CC7.2, security monitoring. Diagnostic logs are exported inconsistently across subscriptions, with no central routing for security alerts.

Policy documents and spreadsheets do not close these findings on their own. A Type II audit tests whether a control operated throughout the review period, and that is far easier to show when the platform itself prevents the misconfiguration.

Why enforced policies beat manual checklists

Auditors look for continuous, automated enforcement rather than a written promise. Instead of configuring resources by hand in the Azure portal, map the infrastructure-related Trust Services Criteria to a custom Azure Policy initiative. Here is one rule from such an initiative, which enforces TLS 1.2 and secure transfer on storage accounts:

{
  "policyRule": {
    "if": {
      "allOf": [
        { "field": "type", "equals": "Microsoft.Storage/storageAccounts" },
        { "anyOf": [
          { "field": "Microsoft.Storage/storageAccounts/supportsHttpsTrafficOnly", "notEquals": "true" },
          { "field": "Microsoft.Storage/storageAccounts/minimumTlsVersion", "notEquals": "TLS1_2" }
        ]}
      ]
    },
    "then": { "effect": "deny" }
  }
}

With this policy assigned at the root management group, a request to create a storage account that allows plain HTTP or TLS below 1.2 is rejected at deployment, whether it comes from the portal, a script, or a CI/CD pipeline.

The staged rollout: Audit, then Deny

The common worry is that compliance guardrails will break production. A staged rollout keeps that risk low:

1. Start in Audit mode. Assign the policies with "effect": "audit" across all management scopes. This shows which existing resources are non-compliant without touching live application traffic.
2. Remediate existing resources. Use Azure Policy remediation tasks, or planned changes, to bring existing resources into line. Test changes such as minimum TLS versions against client applications first, because older clients may fail to connect.
3. Switch production to Deny mode. Once the audit results are clean, set production subscriptions to "effect": "deny" so new non-compliant resources are blocked at deployment.

What the auditor receives

Azure Policy is a control-plane service, and Microsoft does not charge for evaluating policies against Azure resources. Supporting services such as log retention and Defender for Cloud plans are billed separately, so budget for those.

The evidence your auditor works from is a control traceability matrix that maps each policy assignment to the SOC 2 criteria it supports, plus Azure Resource Graph queries your team can run to export current compliance state.