Cloud infrastructure changes how SOC 2 is scoped, what controls apply to you versus your cloud provider, and what evidence your auditor will ask for. Most companies going into SOC 2 for the first time on cloud infrastructure have fundamental questions about the shared responsibility model in practice. We have scoped and delivered SOC 2 for cloud-native companies on AWS, Azure, GCP, and multi-cloud environments.
10–12 weeks (cloud-native programmes)
AWS, Azure, GCP — all correctly scoped
IaC-native controls (Terraform, CloudFormation)
Senior practitioner on every engagement
Shared responsibility delineation included
Every major cloud provider operates under a shared responsibility model. Your cloud provider is responsible for security of the cloud. You are responsible for security in the cloud. Getting this delineation right is the most consequential early decision in a cloud-native SOC 2 programme.
AWS, Azure, and GCP each maintain their own SOC 2 and ISO 27001 reports. These cover the physical security, data centre controls, and infrastructure hardening of the cloud provider itself. Your configurations — IAM policies, security groups, encryption settings, logging configurations, network architecture — are fully in your scope and will be tested by your auditor.
Companies that include cloud provider-managed controls in their own SOC 2 scope end up building documentation for systems that were already covered by their cloud provider's existing certifications. We scope your audit correctly from day one so you are not doing work that the shared responsibility model means you do not need to do.
The other common mistake: assuming your cloud provider's certifications cover more than they do, and leaving application-layer controls, IAM configurations, and data handling practices out of scope. Your auditor will find these gaps at audit time — not at gap assessment time. We ensure your scope covers everything your auditor will test.
Cloud-native teams managing infrastructure through Terraform, CloudFormation, or Pulumi have a significant evidence collection advantage over teams using manual configuration. We help you structure your IaC workflows to produce auditable evidence as a natural output — so evidence collection before your annual audit cycle is automated rather than manual.
We build every control specifically for your company’s architecture and team capacity — not a generic checklist designed for a different type of organisation.
IAM misconfigurations are the leading cause of cloud security incidents — and the first thing SOC 2 auditors look at in a cloud environment. We help you implement least-privilege IAM policies, enforce multi-factor authentication, segregate production and non-production access, manage service account permissions, and build access review processes that produce the evidence your auditor needs.
SOC 2 requires evidence that you monitor your environment and respond to security events. In a cloud environment, this means configuring CloudTrail, CloudWatch, Azure Monitor, GCP Cloud Logging, or equivalent services — and demonstrating that alerts are reviewed and responded to. We help you configure comprehensive logging, set up meaningful alerting, and build the response procedures your auditor will look for.
Cloud-native teams managing infrastructure through Terraform, CloudFormation, Pulumi, or similar IaC tools need SOC 2 change management controls that reflect their actual workflow. We build change management controls that integrate with your existing CI/CD pipeline: pull request approvals, automated testing gates, deployment approvals, and change documentation that produces auditable evidence.
SOC 2 requires encryption of customer data in transit and at rest. In a cloud environment, this involves your KMS configuration (AWS KMS, Azure Key Vault, GCP Cloud KMS), your encryption settings for storage services, your database encryption, and your TLS certificate management. We assess your encryption posture, identify gaps, and implement the key management practices and documentation that auditors expect.
We review your cloud architecture — services used, data flows, IAM structure, multi-tenant model, IaC configuration — and define your SOC 2 scope precisely. We produce a shared responsibility delineation that clearly maps what your cloud provider covers vs what you need to implement. This prevents both over-scoping and under-scoping.
We implement SOC 2 controls that fit your actual cloud workflow — IAM policies, logging configurations, encryption settings, change management procedures, and vendor documentation. Where possible, we integrate evidence collection into your existing IaC and CI/CD workflows rather than creating separate manual compliance processes.
We conduct a technical pre-audit review focused on your cloud configuration — testing IAM policies, logging coverage, encryption settings, and access controls against SOC 2 requirements. Every gap found here is closed before your formal auditor arrives. Evidence packages are compiled and organised for auditor review.
Your independent CPA auditor conducts the formal assessment — including technical testing of your cloud controls. We manage the evidence request process throughout. You receive your SOC 2 report with your cloud architecture correctly reflected and documented.
SOC 2 Type 2 · AWS multi-region · 12 weeks
Cloud-native SOC 2 programme
Evidence collection reduction via IaC integration
Audit findings from scoping errors
If your question is not here, book a free consultation — a senior advisor will give you a direct answer in 30 minutes.
No. AWS, Azure, and GCP each maintain their own SOC 2 reports — but these cover the physical infrastructure, data centre controls, and platform-level security of the cloud provider itself. Your application layer, your IAM configurations, your data handling practices, and your customer-facing controls are entirely your responsibility and fully within your SOC 2 scope. This is the most common misunderstanding in cloud-native SOC 2 programmes.
Your auditor will test: IAM policies and access controls, encryption configuration (storage, transit, database), logging and monitoring coverage, change management procedures, incident response capability, vendor oversight, and data handling practices. They will reference your cloud provider’s own certifications for the infrastructure layer — but they will test your configuration and usage of that infrastructure directly.
IaC-managed infrastructure can significantly simplify evidence collection for SOC 2 — if your IaC workflows are set up correctly. Pull request reviews, automated testing gates, and deployment approval workflows can produce auditable evidence as a natural output rather than requiring separate manual documentation. We help you structure your Terraform or CloudFormation workflows to generate SOC 2 evidence efficiently.
Multi-cloud SOC 2 requires a unified control framework that addresses all environments consistently. Each cloud provider has different IAM models, logging services, and encryption options — your SOC 2 programme needs to cover all of them coherently rather than as separate programmes. We have scoped and delivered SOC 2 for multi-cloud architectures spanning AWS, Azure, and GCP in a single engagement.
Serverless and managed service architectures are fully compatible with SOC 2. The key is scoping the boundary correctly: your code, your data handling, your access controls, and your monitoring are in scope; the underlying compute and storage management by your cloud provider is not. We scope serverless and managed service environments regularly and know exactly how auditors evaluate them.
Book a free 30-minute consultation. A senior advisor — not a sales rep — will talk honestly about your compliance situation and exactly what it will take to get you where you need to be.
After remediation, confirm you are genuinely ready before your auditor arrives. Our readiness assessment runs the same tests your auditor will run.
We stay with you through the formal audit — managing auditor requests, reviewing evidence, and handling every question until your report is issued.
Not sure which type of SOC 2 report your customers actually require? We break down the difference and help you choose the right path.
