The Multi-Cloud SOC 2 Challenge

SOC 2's Trust Services Criteria apply uniformly regardless of cloud provider. The same CC6 access control requirements that govern your AWS IAM configurations also apply to your Azure AD and GCP IAM policies. The same CC7 monitoring requirements that drive your AWS CloudTrail configuration also require equivalent audit logging in Azure Monitor and GCP Cloud Logging.

The challenge is that each cloud provider implements these controls differently. AWS uses IAM roles and policies. Azure uses RBAC with Entra ID. GCP uses service accounts with IAM bindings. The control outcome is the same; the implementation is entirely different.

Multi-cloud SOC 2 compliance requires a framework that achieves consistent control outcomes across platforms, not identical implementations.

Shared Responsibility in Each Cloud Provider

Before mapping controls, understand what each provider covers under their shared responsibility model.

All major cloud providers (AWS, Azure, GCP) hold SOC 2 Type II reports covering their infrastructure. Your auditor won't accept those reports as a substitute for your own controls, but they do reduce what you need to demonstrate:

• Physical security (A1.1 in part): The data center's physical controls are the provider's responsibility
• Hypervisor and underlying infrastructure security: Provider's responsibility
• Managed service security configurations: Shared — the provider secures the service; you configure it correctly

What you're responsible for across all providers:

• Identity and access management configuration
• Network security configuration (security groups, NSGs, firewall rules)
• Encryption configuration (key management, at-rest and in-transit settings)
• Audit logging configuration and retention
• Operating system and application security for IaaS instances

The same configuration responsibilities exist on every platform.

Centralized Identity: The Most Critical Multi-Cloud Control

CC6.1 and CC6.2 require that access is controlled through authenticated, authorized identities. In a multi-cloud environment, the risk is that each cloud has its own identity silo — an engineer may be correctly provisioned in AWS but have excessive permissions in GCP, or the same account may be de-provisioned in Azure but still active in GCP.

Option 1: Enterprise Identity Provider (IdP) as the Source of Truth

The most robust approach: use an enterprise IdP (Okta, Azure AD/Entra ID, Google Workspace) as the authoritative identity system, with federated access to each cloud provider.

• AWS: Configure SAML 2.0 federation or AWS IAM Identity Center (SSO) with your IdP
• Azure: Native integration with Entra ID
• GCP: Configure Workforce Identity Federation with your IdP

When an employee is offboarded, a single action in the IdP revokes access across all cloud providers simultaneously. This satisfies CC6.3 (removal of access upon termination) without requiring manual deprovisioning in each cloud.

Option 2: Cross-Cloud Access Governance Reviews

If federation isn't feasible, implement quarterly access reviews that cover all cloud environments simultaneously. The review should confirm that the same person has consistent, appropriate access across all platforms — and that accounts terminated in one platform are terminated in all.

Document the multi-cloud access review explicitly in your SOC 2 evidence. Auditors will check that your access review process covers all in-scope systems, not just the primary cloud.

Unified Logging Strategy

CC7.2 requires detection of security events. In a multi-cloud environment, this requires logs from all providers flowing into a single, searchable system.

Recommended architecture:

|---|---|---| Common SIEM destinations: Splunk, Datadog, Microsoft Sentinel, Elastic Security.

The key requirement for SOC 2: logs must be tamper-resistant, retained for the observation period plus buffer, and searchable for incident investigation. A SIEM that ingests from all providers satisfies this for all SOC 2 log retention criteria simultaneously.

For smaller teams: A simpler approach — all CloudTrail logs to S3 in AWS, Azure Activity Logs to Azure Blob Storage, GCP logs exported to GCS — is acceptable if you can demonstrate that you review logs for security events. The centralized approach scales better and reduces the effort to investigate cross-cloud incidents.

Policy Consistency Across Providers

The same control outcomes require different implementations on each platform. Create a control mapping that documents the implementation on each platform:

|---|---|---|---|

Maintain this mapping document in your compliance program. When auditors ask how CC6.7 (encryption) is implemented, you can point to the specific configuration on each platform.

Infrastructure as Code for Multi-Cloud Consistency

Terraform's multi-provider support makes it particularly valuable for multi-cloud SOC 2 compliance. A single Terraform root module can configure equivalent controls across providers:

# AWS encryption

resource "aws_s3_bucket_server_side_encryption_configuration" "data" { ... }
# Azure equivalent
resource "azurerm_storage_account" "data" {
  blob_properties { versioning_enabled = true }
  # Azure enables encryption at rest by default with Microsoft-managed keys
  # Use customer_managed_key block for CMEK
}
# GCP equivalent
resource "google_storage_bucket" "data" {
  encryption { default_kms_key_name = google_kms_crypto_key.bucket_key.id }
}

See [Terraform and SOC 2](/blog/terraform-infrastructure-as-code-soc2) for the full guide on using IaC for compliance.

SecureSpect's Multi-Cloud Roadmap

SecureSpect currently provides deep SOC 2 coverage for AWS and GitHub. Azure, GCP, Google Workspace, Microsoft Entra ID, and additional integrations are in active development.

For teams running primarily on AWS with secondary workloads in Azure or GCP, the current approach is:

• Use SecureSpect for comprehensive AWS SOC 2 monitoring (100+ checks)
• Apply the control framework documented in this guide to Azure and GCP configurations
• Document the multi-cloud control mapping in your compliance program for auditor review

As SecureSpect adds multi-cloud coverage, the same continuous monitoring model will extend to all providers. Check the SecureSpect integrations page for the current rollout status.

For existing multi-cloud coverage on Azure and GCP, see our guides: [Azure cloud security for SOC 2](/blog/azure-cloud-security-soc2) and [GCP security for SOC 2](/blog/gcp-security-soc2-guide).