SOC 2 Cloud Compliance & the Shared Responsibility Model

What You Inherit vs What You Must Implement

Cloud providers operate SOC 2‑compliant infrastructure, but that does not cover your application, data, or access controls. The shared responsibility model defines where provider responsibility ends and yours begins.

Inherited controls (provider side):

• Physical data center security (facility access, environmental controls, hardware disposal)
• Base infrastructure controls (hypervisor, network isolation, compute and storage layer security)
• Some managed service controls, depending on the service model (e.g., AWS RDS manages database patching, but you configure access and encryption)
  
  

Customer controls (you still own):

• Identity and access management: Single sign‑on (SSO), multi‑factor authentication (MFA), least privilege role assignment, access reviews
• Network design: Virtual private cloud (VPC) or VNet configuration, security groups, firewall rules, segmentation
• Data protection: Encryption at rest and in transit, key management, data retention, secure deletion
• Logging and monitoring: Cloud audit logs, application logs, alert configuration, security event triage
• Change management: Deployment approvals, infrastructure as code (IaC) workflows, emergency change procedures
• Incident response: Detection procedures, escalation paths, tabletop exercises, post‑incident reviews

Auditors test whether you operate these controls consistently, with evidence that proves they ran as documented.

Cloud Controls Auditors Test First

Auditors focus on controls that demonstrate you manage your cloud environment securely and with discipline. These controls show up in every cloud‑based SOC 2 audit.

Cloud evidence that shows maturity:

• Multi‑factor authentication enforcement: Proof that MFA is required for all privileged access, not just enabled
• Least privilege IAM roles: Role definitions with documented review cadence (monthly or quarterly access reviews)
• Centralized logging: Cloud audit logs, application logs, and security alerts configured and stored with retention policies
• Vulnerability management: Scan results, remediation tickets, and proof of closure within defined SLAs
• Backup and restore testing: Backup schedules, retention policies, and evidence of successful restore tests
• Change management: Change tickets tied to production deployments, with approvals, timestamps, and rollback procedures

Inconsistent evidence creates audit exceptions. Missing evidence fails controls.

How to Use Your Cloud Provider's SOC 2 Report

AWS, Azure, and Google Cloud publish SOC 2 reports that describe their control environment. These reports are useful for inherited controls but do not replace your own controls.

Provider SOC 2 reports support:

• Infrastructure control environment: Evidence that the underlying cloud platform operates with strong physical, logical, and environmental controls
• Managed service assurance: Documentation that managed services (databases, storage, compute) operate within a compliant environment
  
  

They are not a substitute for your controls. Auditors will still ask:

• How do you control access to the cloud account?
• How do you approve infrastructure and application changes?
• How do you monitor security alerts and respond to incidents?
• How do you protect customer data (encryption, retention, deletion)?

You can reference your provider's SOC 2 report in your system description and control descriptions, but you must still collect evidence for your own controls. AWS, Microsoft Azure, and Google Cloud each publish compliance documentation and SOC reports for customers.

A Simple Mapping Method for Cloud Controls

Map your cloud controls to Trust Services Criteria, assign ownership, and define evidence collection. This method works for any cloud provider.

1. List in‑scope services: Compute (EC2, VMs, Compute Engine), storage (S3, Blob, Cloud Storage), databases (RDS, Azure SQL, Cloud SQL), CI/CD pipelines, monitoring and logging tools
2. Assign each control to a service owner: One named person per control, not a team or department
3. Mark evidence type: API export, configuration screenshot, change ticket, review meeting notes, scan report
4. Set cadence: Monthly access review, quarterly vulnerability scan, annual penetration test
5. Store artifacts in one place: Same folder structure every month (e.g., Access_Review_January_2026, Vuln_Scan_Q1_2026)

Consistency matters more than perfection. Use the same process and template every time so evidence is repeatable.

Common Pitfalls That Create Audit Findings

Most cloud compliance failures trace back to four issues:

• Too many administrators: "Temporary" admin access granted during onboarding or troubleshooting that never gets revoked
• No review cadence: Access reviews exist in policy but do not run on schedule or produce documented results
• Logs without action: Security alerts fire, but no triage record exists to show investigation, resolution, or escalation
• Configuration drift: Infrastructure changes made outside of infrastructure as code (IaC) or approval workflows, creating undocumented modifications

Fix the process before the observation period starts. Auditors sample evidence across the full period, so one missed month fails the control.

Common Questions About SOC 2 Cloud Compliance

Does AWS, Azure, or Google Cloud SOC 2 compliance make us compliant?

No. Your cloud provider's SOC 2 report supports inherited controls (physical security, infrastructure management), but you must operate your own controls for identity, data protection, change management, logging, and incident response. Reference provider reports in your system description, but collect evidence for customer‑side controls. AWS, Microsoft Azure, and Google Cloud publish SOC 2 reports and shared responsibility documentation.

What evidence do auditors want for cloud access controls?

Auditors request IAM role lists, admin group membership exports, MFA enforcement configuration, and access review records showing who reviewed, when they reviewed, exceptions identified, and remediation actions taken. Screenshots alone are not sufficient. Evidence must be time‑stamped and repeatable.

What matters more for cloud compliance: tooling or process?

Process. Tools help automate evidence collection and enforce configuration baselines, but auditors test whether the process ran consistently. If you have great tools but no review cadence, controls fail. If you have a strong process with manual evidence collection, controls pass.

How do we keep evidence clean for Type 2 audits?

Use a calendar. Assign each control to an owner, set a recurring due date (monthly access review, quarterly vulnerability scan), and store evidence in the same folder structure every month. Type 2 audits sample evidence across the observation period, so missing one month fails the control.

Where does Neutral Partners help with cloud compliance?

We map inherited vs customer controls, tune your control set to your cloud architecture and scope, and build evidence collection habits that hold up under audit sampling. You get a year‑round compliance process that keeps engineers building while cloud controls stay audit‑ready. Learn more about our compliance services or explore our full SOC 2 certification service.

Key SOC 2 Cloud Compliance Resources

• AWS SOC compliance and FAQs: https://aws.amazon.com/compliance/soc-faqs/
• Microsoft Azure SOC 2 compliance: https://learn.microsoft.com/en-us/azure/compliance/offerings/offering-soc-2
• Google Cloud SOC 2 compliance: https://cloud.google.com/security/compliance/soc-2
• Neutral Partners SOC 2 services: https://neutralpartners.com/frameworks/soc-2
• Full compliance services: https://neutralpartners.com/services

Next step: If you want to map your cloud controls and build an evidence system that auditors accept, talk to us about cloud compliance readiness. We will identify inherited vs customer controls, assign ownership, validate evidence quality, and keep your audit on track.