SOC 2 Compliance on Azure: Complete Implementation Guide

SOC 2 compliance has become a de facto requirement for SaaS companies selling to enterprises. If your application runs on Azure, you're starting from a strong foundation, but there's still significant work to do. This guide walks through everything you need to know about achieving and maintaining SOC 2 compliance on Azure.

Understanding SOC 2

SOC 2 (Service Organization Control 2) is an auditing framework developed by the AICPA that evaluates an organisation's controls related to security, availability, processing integrity, confidentiality, and privacy, the five Trust Service Criteria.

Type I vs Type II

Type I: Point-in-time assessment of whether controls are designed appropriately.
Type II: Assessment of whether controls operated effectively over a period (typically 6-12 months).

Most enterprise customers require Type II reports. Start with Type I if you need to demonstrate compliance quickly, then progress to Type II.

Trust Service Criteria

The Trust Service Criteria cover five areas. Security (the only required criterion) focuses on protection against unauthorised access. Availability addresses system availability for operation and use. Processing Integrity ensures system processing is complete, valid, accurate, and timely. Confidentiality protects information designated as confidential. Privacy ensures personal information is handled appropriately. Most SaaS companies include Security and Availability at minimum.

Azure's Role in Your Compliance

Azure maintains its own SOC 2 Type II report covering the physical infrastructure, network, and platform services. You can leverage Azure's compliance to satisfy controls related to the underlying infrastructure.

Shared Responsibility

Azure's Responsibility (Covered by Azure SOC 2):
├── Physical security of datacenters
├── Network infrastructure security
├── Hypervisor and host OS security
├── Platform service security (Azure SQL, Storage, etc.)
└── Identity platform (Microsoft Entra ID)

Your Responsibility:
├── Application security
├── Data classification and protection
├── Access management for your resources
├── Network configuration (NSGs, firewalls)
├── Encryption configuration
├── Monitoring and logging
├── Incident response
└── Change management

Common Controls and Azure Implementation

CC1: Control Environment

These controls relate to organisational commitment to integrity and ethics. Azure doesn't directly help here, you need documented policies, code of conduct, and security awareness training.

CC2: Communication and Information

Document your security policies and communicate them to employees. Key artifacts include your Information Security Policy, Acceptable Use Policy, Incident Response Plan, Business Continuity Plan, and Vendor Management Policy.

CC3: Risk Assessment

Conduct regular risk assessments. Azure provides tools to support this: Microsoft Defender for Cloud for continuous security assessment, Azure Advisor for best practice recommendations, and Compliance Manager for regulatory compliance tracking.

CC4: Monitoring Activities

Implement comprehensive monitoring:

// Azure Monitor configuration for SOC 2
resource "azurerm_monitor_diagnostic_setting" "audit" {
  name                       = "audit-logs"
  target_resource_id         = azurerm_key_vault.main.id
  log_analytics_workspace_id = azurerm_log_analytics_workspace.main.id

  enabled_log {
    category = "AuditEvent"
  }

  metric {
    category = "AllMetrics"
  }
}

CC5: Control Activities

Technical controls implemented through Azure:

Logical Access Controls

Implement identity management through Microsoft Entra ID, access control through Conditional Access policies, admin access through Privileged Identity Management, and RBAC with the least privilege principle.

// Require MFA and compliant device for Azure portal
resource "azurerm_conditional_access_policy" "require_mfa_portal" {
  display_name = "Require MFA for Azure Management"
  state        = "enabled"

  conditions {
    applications {
      included_applications = ["797f4846-ba00-4fd7-ba43-dac1f8f63013"]
    }
    users {
      included_users = ["All"]
    }
  }

  grant_controls {
    operator = "AND"
    built_in_controls = ["mfa", "compliantDevice"]
  }
}

Encryption

Enable encryption at rest for all services, use customer-managed keys for sensitive data, and enforce TLS 1.2 or higher for data in transit.

Network Security

// Network segmentation
resource "azurerm_network_security_group" "app_tier" {
  name                = "app-tier-nsg"
  location            = azurerm_resource_group.main.location
  resource_group_name = azurerm_resource_group.main.name

  security_rule {
    name                       = "AllowHTTPS"
    priority                   = 100
    direction                  = "Inbound"
    access                     = "Allow"
    protocol                   = "Tcp"
    source_port_range          = "*"
    destination_port_range     = "443"
    source_address_prefix      = "10.0.1.0/24"
    destination_address_prefix = "*"
  }

  security_rule {
    name                       = "DenyAll"
    priority                   = 4096
    direction                  = "Inbound"
    access                     = "Deny"
    protocol                   = "*"
    source_port_range          = "*"
    destination_port_range     = "*"
    source_address_prefix      = "*"
    destination_address_prefix = "*"
  }
}

CC6: Logical and Physical Access

Physical access is covered by Azure's SOC 2. For logical access, implement onboarding and offboarding procedures, conduct quarterly access reviews, use PIM for just-in-time admin access, and enable activity logging for all access.

CC7: System Operations

For change management and incident response, route all changes through pull requests with approvals, use automated deployments via CI/CD, document incident response procedures, and conduct regular incident response testing.

CC8: Change Management

Your CI/CD pipeline is key evidence here. Implement code review requirements, branch protection rules, automated testing before deployment, separation of duties (so no one can approve their own PRs), and maintain an audit trail of all changes.

CC9: Risk Mitigation

For vendor management and business continuity, review SOC 2 reports from critical vendors including Azure, document disaster recovery procedures, regularly test backups, and complete a business impact analysis.

Evidence Collection and Automation

Auditors will request evidence of control operation. Automate collection where possible:

Azure Policy for Continuous Compliance

// Audit storage accounts without HTTPS
resource "azurerm_policy_assignment" "storage_https" {
  name                 = "storage-https-only"
  scope                = azurerm_management_group.main.id
  policy_definition_id = "/providers/.../policyDefinitions/..."
  
  parameters = jsonencode({
    effect = { value = "Audit" }
  })
}

Automated Evidence Export

# Export access reviews
az rest --method GET \
  --uri "https://graph.microsoft.com/v1.0/..." \
  --output json > access-reviews-evidence.json

# Export activity logs
az monitor activity-log list \
  --start-time $(date -d '-90 days' -Iseconds) \
  --output json > activity-logs-90days.json

# Export policy compliance
az policy state list \
  --query "[].{Resource:resourceId, ...}" \
  --output json > policy-compliance.json

Common Pitfalls

1. Starting Too Late

Type II requires controls to be in place for the audit period. Start implementing controls at least 6 months before you need the report.

2. Over-Engineering Controls

Controls need to be sustainable. An overly complex control that people bypass is worse than a simpler one that's followed consistently.

3. Ignoring the "People" Controls

Technical controls are only part of SOC 2. You also need security awareness training with completion tracking, background checks for employees, documented onboarding and offboarding procedures, and regular performance reviews.

4. Not Monitoring Your Monitoring

Having logs isn't enough, you need to prove someone reviews them. Implement alerting for security events, document alert response procedures, and maintain evidence that alerts are investigated.

Audit Preparation Checklist

Pre-Audit (3 months before):
□ Policy documentation complete and approved
□ All technical controls implemented
□ Evidence collection automated where possible
□ Conduct internal audit / gap assessment
□ Remediate identified gaps

Audit Preparation (1 month before):
□ Compile evidence for each control
□ Prepare system descriptions
□ Brief relevant team members
□ Review Azure's SOC 2 report for reference

During Audit:
□ Designate audit coordinator
□ Respond to evidence requests promptly
□ Document any exceptions or deviations
□ Track remediation items

Maintaining Compliance

SOC 2 isn't a one-time effort. Maintain compliance through quarterly access reviews, annual policy reviews, continuous monitoring and alerting, regular training updates, incident response testing, and vendor review updates.

Summary

SOC 2 compliance on Azure is achievable with proper planning and implementation. Leverage Azure's built-in security features, automate evidence collection, and remember that sustainable, followed controls are better than complex, bypassed ones.

The investment in SOC 2 compliance pays dividends beyond the report itself, the security practices required make your organisation genuinely more secure.