Most security and compliance leaders know their cloud provider carries SOC 2 Type II and ISO 27001 certifications. Many assume those certifications cover their organization’s compliance obligations. They do not. AWS’s SOC 2 report attests to AWS’s controls over its own infrastructure. It says nothing about how your organization configured the services running on top of that infrastructure. The boundary between what the provider covers and what you cover is the shared responsibility model, and auditors treat it as your problem to document.
That misunderstanding produced a hard number: 82% of cloud data exposures in 2023 involved misconfiguration or inadequate access controls on the customer side, not provider failures [IBM Cost of a Data Breach Report 2024]. Organizations with clean cloud provider audit reports still received qualified opinions during their own SOC 2 examinations because the provider’s certification and the customer’s compliance are two separate questions. AWS’s SOC 2 never promised otherwise. The shared responsibility model makes that division explicit.
The division shifts depending on whether you run IaaS, PaaS, or SaaS, and it maps differently across SOC 2, HIPAA, PCI DSS, and FedRAMP. Get the boundary wrong, and you submit evidence that covers the provider’s controls but misses your own. Auditors know the difference. Here is the map.
The cloud shared responsibility model divides security and compliance obligations between provider and customer. Cloud providers (AWS, Azure, GCP) cover physical infrastructure and managed services. Customers own identity and access management, data classification, encryption configuration, logging, and application-level security. For SOC 2, HIPAA, PCI DSS, and FedRAMP, the customer must produce independent evidence for all controls outside the provider’s certified scope.
How the Cloud Shared Responsibility Model Divides Compliance Obligations
The cloud shared responsibility model has three tiers, each with a different customer obligation profile. IaaS, PaaS, and SaaS transfer different layers of responsibility to the provider. What stays constant across all three: the customer owns identity and access management, data classification and protection, and audit logging configuration. No provider certification removes those obligations.
IaaS: Maximum Customer Responsibility
Infrastructure as a Service (IaaS) gives customers the most control and the most compliance burden. The provider secures the physical data centers, hypervisors, and network backbone. The customer owns everything above that line: operating system configuration, network access controls, application security, identity management, encryption configuration, and monitoring.
AWS EC2, Azure Virtual Machines, and GCP Compute Engine all operate under this model. When you provision a virtual machine, you configure the security group or network security group. You install and patch the OS. You configure CloudTrail, Azure Monitor, or GCP Cloud Audit Logs. You manage IAM roles and policies. None of these appear in AWS’s SOC 2 report. They appear in yours. Under SOC 2, every one of those configurations ties back to specific Trust Services Criteria: CC6.1 for logical access controls, CC6.6 for network restrictions, CC7.2 for monitoring and detection [AICPA TSC CC6.1, CC6.6, CC7.2].
PaaS: Shared Middle Ground
Platform as a Service (PaaS) shifts infrastructure management to the provider but leaves application-layer security to the customer. AWS RDS, Azure App Service, and GCP Cloud SQL handle patching, underlying OS maintenance, and physical host security. The customer handles database access controls, connection encryption, authentication policies, audit log configuration, and application code.
The risk here is a false sense of coverage. A managed database service protects the hardware and hypervisor. It does not configure row-level security, enforce TLS for client connections, or enable audit logging on individual query operations. Those decisions belong to the customer and produce the evidence auditors request. For SOC 2, the customer must demonstrate that access to the managed database follows CC6.1 provisioning controls and that access reviews meet CC6.3 requirements [AICPA TSC CC6.1, CC6.3].
SaaS: Narrowest Customer Responsibility, Still Real
Software as a Service providers take responsibility for the entire technology stack: infrastructure, platform, application, and in many cases, the security of the application itself. Salesforce, Workday, and Microsoft 365 all carry SOC 2 Type II reports covering their platforms. The customer’s obligations narrow significantly but do not disappear.
SaaS customers own user provisioning and deprovisioning, role assignments, data they input into the platform, and integration configurations. If your Salesforce instance has a terminated employee account that remains active for 90 days post-departure, that finding appears in your SOC 2 examination under CC6.3, not Salesforce’s [AICPA TSC CC6.3]. The provider’s certification does not protect you from your own access management gaps. Under automated access reviews, SaaS user lifecycle management produces the evidence CC6.3 requires.
Build a shared responsibility matrix for every cloud service in your SOC 2 scope. Create a spreadsheet with three columns: service name, provider-covered controls (cite the provider’s SOC 2 report section), and customer-covered controls (map each to the relevant TSC criterion). Give this matrix to your auditor at kickoff. It demonstrates that you understand the boundary and have a plan to evidence your side of it.
AWS, Azure, and GCP Shared Responsibility Models Compared
AWS, Azure, and GCP each publish their shared responsibility model, but the frameworks describe the division differently. The underlying principle is consistent. The terminology and emphasis vary, and those differences affect how you document inherited controls versus customer-implemented controls for your auditor.
AWS Shared Responsibility Model
AWS frames the division as “security of the cloud” (AWS responsibility) versus “security in the cloud” (customer responsibility) [AWS Shared Responsibility Model]. AWS secures the global infrastructure: Regions, Availability Zones, and edge locations, plus the underlying hardware, software, networking, and facilities. The customer secures everything deployed within that infrastructure.
AWS publishes a SOC 2 Type II report covering the AWS infrastructure controls. Customers reference AWS’s report to inherit specific controls under frameworks like FedRAMP, using it to document the provider side of their authorization boundary. AWS Artifact provides direct access to AWS’s compliance reports and certifications. For SOC 2 audits, the customer pulls AWS’s report as evidence for physical and environmental controls while producing independent evidence for all logical, application, and data layer controls.
Microsoft Azure Shared Responsibility Model
Azure’s model introduces explicit responsibility designations that shift by service type. Microsoft publishes a table showing which responsibilities are always Microsoft’s (physical security, identity infrastructure), which are always the customer’s (accounts and identities, data, devices), and which shift based on whether the deployment is on-premises, IaaS, PaaS, or SaaS [Microsoft Azure Shared Responsibility].
The Azure model explicitly marks “identity and directory infrastructure” as a shared responsibility for IaaS and PaaS, while customers own it fully. This nuance matters for audit evidence. Azure Active Directory (now Microsoft Entra ID) is customer-managed. Microsoft secures the service. The customer configures policies, conditional access, and access reviews. Both sides produce different evidence for the same SOC 2 control.
Google Cloud Platform Shared Responsibility Model
GCP describes the model as Google’s responsibility for managing underlying infrastructure and the customer’s responsibility for securing their data and applications running on top [GCP Shared Responsibility Matrix]. GCP provides detailed shared responsibility matrices for specific compliance frameworks, including PCI DSS and HIPAA, which map specific requirement numbers to “Google-managed,” “customer-managed,” or “shared” status.
GCP’s compliance documentation is particularly useful for framework-specific audit preparation. The GCP PCI DSS Shared Responsibility Matrix identifies which PCI DSS 4.0 requirements Google satisfies through its infrastructure certifications and which the customer must address independently [PCI DSS 4.0]. For cloud-first organizations pursuing multiple framework certifications simultaneously, GCP’s matrices reduce ambiguity about which evidence bucket each requirement falls into.
| Responsibility Area | AWS (IaaS) | Azure (IaaS) | GCP (IaaS) | Customer Action Required |
|---|---|---|---|---|
| Physical infrastructure | AWS | Microsoft | Reference provider SOC 2 / ISO 27001 | |
| Hypervisor and host OS | AWS | Microsoft | Reference provider SOC 2 | |
| Guest OS and patching | Customer | Customer | Customer | Document patch cadence, tooling, evidence |
| Network access controls | Customer | Customer | Customer | Security groups, firewall rules, NSG logs |
| Identity and access management | Customer | Shared | Customer | IAM policies, access reviews, MFA enforcement |
| Data encryption at rest | Customer | Customer | Customer | KMS configuration, encryption policy documentation |
| Data encryption in transit | Customer | Customer | Customer | TLS enforcement, certificate management |
| Audit logging configuration | Customer | Customer | Customer | CloudTrail/Activity Log/Audit Logs enabled, retained |
| Application security | Customer | Customer | Customer | Code review, vulnerability management, pen testing |
Download the provider-specific shared responsibility matrix for your compliance framework directly from AWS Artifact, the Microsoft Service Trust Portal, or GCP’s compliance documentation. Import the matrix into your GRC tool or a tracking spreadsheet. Tag each control row as “provider-inherited,” “customer-implemented,” or “shared.” Every customer-implemented row requires a corresponding evidence artifact in your audit package. Start collecting that evidence 90 days before your audit window opens.
Mapping the Shared Responsibility Model to SOC 2, HIPAA, PCI DSS, and FedRAMP
The shared responsibility model does not exist in isolation. Auditors examine it through the lens of specific frameworks. Each framework maps the customer side of the shared responsibility boundary to different control categories, and each produces a different evidence list. Understanding which controls fall on your side, by framework, is the practical work that separates a clean opinion from exceptions.
SOC 2: Customer-Side Controls the Auditor Checks
SOC 2 auditors examine customer-implemented controls in five Trust Services Criteria categories. The most common customer-side findings cluster in three areas. First: logical access controls under CC6.1, CC6.2, and CC6.3 [AICPA TSC CC6.1, CC6.2, CC6.3]. The customer owns user provisioning, role assignment, MFA enforcement, and quarterly access reviews. AWS IAM’s SOC 2 report does not cover how you configured least-privilege policies in your own AWS accounts. Second: monitoring under CC7.2, which requires evidence of security event detection and alerting configured at the customer account level [AICPA TSC CC7.2]. Third: change management under CC8.1, which requires evidence that the customer’s deployment pipeline includes approval workflows and configuration testing before production changes [AICPA TSC CC8.1].
For SOC 2 security controls, the customer must produce independent evidence for each of these criteria regardless of which cloud provider the infrastructure runs on. The provider’s SOC 2 report is a reference document that closes out the physical and environmental criteria, not a substitution for the customer’s own control evidence.
HIPAA: BAA Coverage Versus ePHI Handling Obligations
HIPAA creates a structural parallel to the shared responsibility model through Business Associate Agreements (BAAs). AWS, Azure, and GCP all offer HIPAA BAAs, which contractually obligate the provider to protect ePHI they process on the customer’s behalf [HIPAA 164.314(a)(1)]. The BAA covers the provider’s infrastructure. It does not transfer any of the customer’s obligations under the HIPAA Security Rule.
The customer retains all Technical Safeguard requirements regardless of BAA coverage. Access controls under HIPAA 164.312(a)(1) require the customer to implement unique user identification, emergency access procedures, automatic logoff, and encryption or decryption for ePHI [HIPAA 164.312(a)(1)]. Audit controls under HIPAA 164.312(b) require the customer to configure hardware, software, and procedural mechanisms that record and examine ePHI access activity [HIPAA 164.312(b)]. The provider’s BAA does not satisfy these requirements. For encryption specifics, the HIPAA encryption requirements framework maps each technical safeguard to a customer configuration decision.
HHS Office for Civil Rights enforcement data shows 78% of HIPAA resolution agreements cite inadequate access controls or audit logging as primary violations [HHS OCR 2024 Annual Report]. Both categories sit firmly on the customer side of the shared responsibility model. The covered entity or business associate writes the corrective action plan, not the cloud provider.
PCI DSS: The Responsibility Matrix in Practice
PCI DSS 4.0 requires organizations to document exactly which requirements they satisfy independently and which they inherit from their cloud provider [PCI DSS 4.0 Req. 12.3.2]. This is a formal documentation requirement, not optional guidance. The qualified security assessor (QSA) will request the customer’s responsibility matrix as part of the scoping exercise.
AWS, Azure, and GCP publish PCI DSS responsibility matrices that specify per-requirement which party is responsible. Requirement 9, which governs physical access to cardholder data environments, transfers entirely to the provider for cloud-based deployments. Requirement 7, which governs access to system components, remains customer responsibility. Requirement 10, which governs audit log management, is partially shared, with the provider logging infrastructure events and the customer configuring application and account-level logging. The customer cannot submit the provider’s Attestation of Compliance (AoC) as evidence for customer-owned requirements. The QSA distinguishes between the two during the assessment.
FedRAMP: Inherited Controls and Customer Responsibility Documentation
FedRAMP structures the shared responsibility model through its inheritance model. Cloud Service Providers (CSPs) authorized under FedRAMP publish a Customer Responsibility Matrix (CRM) that maps every NIST SP 800-53 control to one of four categories: fully inherited (provider responsible), partially inherited (both parties), not inherited (customer responsible), or not applicable [FedRAMP Rev. 5 AC-2].
Federal agencies and contractors using FedRAMP-authorized cloud services must document how they satisfy the non-inherited and partially-inherited controls. This documentation forms part of the customer’s own System Security Plan (SSP). The FedRAMP 20x compliance guide details the authorization structure. For practical purposes, a customer building on AWS GovCloud under FedRAMP High must still document approximately 30-40% of controls as customer-implemented, regardless of the provider’s authorization status.
The shared responsibility model is not a compliance convenience. It is a liability allocation document. When a breach occurs in your cloud environment, the investigation starts with the customer’s side of the boundary first, because that is where misconfigurations live. Regulators do not investigate provider failures when the provider holds a clean SOC 2. They investigate what the customer configured.
What Auditors Request as Customer-Side Cloud Evidence
Understanding the shared responsibility model conceptually is preparation. Producing the evidence is the work. Auditors request specific artifacts for each customer-owned control category. Missing a category produces a finding. Submitting provider documentation in place of customer evidence produces a finding. The evidence list below covers the categories that generate the most common exceptions in cloud-hosted environments.
Identity and Access Management Evidence
IAM evidence is the most requested artifact category in cloud-hosted SOC 2 examinations. Auditors ask for four things: an export of all IAM users, roles, and groups with their associated permissions; documentation of the least-privilege review process; MFA enforcement configuration at the account or organization level; and access review records from the past 12 months showing who reviewed access, when, and what actions resulted.
AWS IAM Access Advisor, Azure Entra ID Access Reviews, and GCP Policy Analyzer each produce exports auditors accept. The review record must show human action: a list that was exported and never reviewed does not satisfy CC6.3 [AICPA TSC CC6.3]. For automated access reviews, document the workflow, the reviewer, the approval or removal actions, and the date. The automation runs the process. The reviewer attests the decision. Both appear in the audit evidence package.
Logging, Monitoring, and Alerting Evidence
Auditors verify three things about logging: that logging is enabled across all in-scope accounts and regions, that logs are retained for the period required by the framework, and that alert rules exist for defined security events. Missing any one of these three produces a finding under CC7.2 or the equivalent framework control [AICPA TSC CC7.2].
For SOC 2, the customer produces: AWS CloudTrail configuration showing all-regions, all-events logging enabled; CloudWatch Alarms or equivalent alert rules for root account usage, IAM policy changes, and unauthorized API calls; and log retention policy documentation matching the audit retention requirement. The continuous compliance monitoring framework maps each of these artifacts to the SOC 2 criteria they satisfy.
Configuration and Change Management Evidence
Cloud configuration evidence proves that customer-managed resources match approved baselines and that changes to those configurations go through an approval process. Auditors request AWS Config rules or Azure Policy assignments showing active enforcement against a defined baseline; a sample of approved change records from the past 12 months matching production configuration changes; and evidence that out-of-band changes trigger alerts and remediation. Cloud security posture management tools produce the continuous configuration evidence auditors now expect for this category.
Build your cloud compliance evidence package 60 days before the audit observation period. Start with IAM: pull the full user and role export from every in-scope cloud account, run the access review, and document reviewer sign-off. Then pull logging: confirm all regions have CloudTrail or equivalent enabled, check retention periods, and export alert configuration. Finish with configuration: run your CSPM tool against CIS Benchmarks and export the compliance posture report with a timestamp. These three packages cover the majority of customer-side findings. Deliver them at audit kickoff, not in response to auditor requests.
Where Cloud Compliance Failures Actually Originate
The distribution of cloud security failures follows a consistent pattern. Provider infrastructure failures are rare and heavily publicized. Customer-side misconfigurations are common and quietly remediated after the fact. The gap between those two categories explains why organizations with certified cloud providers still receive qualified opinions and breach notifications.
The Misconfiguration Concentration
Misconfiguration is the primary failure mode in cloud security. The five configurations that generate the majority of customer-side audit findings and security incidents are: overly permissive IAM policies (wildcard actions or administrator-level roles granted to broad principals), public storage buckets (S3, Azure Blob, or GCP Cloud Storage without public access blocks), disabled audit logging (CloudTrail, Activity Log, or GCP Audit Logs off in one or more regions), unencrypted data stores (RDS instances, EBS volumes, or storage buckets without encryption enabled), and unrestricted inbound network access (security groups or NSGs allowing 0.0.0.0/0 on sensitive ports).
Each one of these configurations produces a specific audit finding under a specific control number. Each one sits entirely on the customer side of the shared responsibility model. Provider certifications do not touch them.
The Inheritance Documentation Gap
A second failure pattern appears specifically in FedRAMP and PCI DSS assessments: the customer assumes inherited controls are automatically documented and produces no evidence to support the inheritance claim. Inheritance is not passive. The customer must review the provider’s CRM, confirm which controls are fully or partially inherited, and document that the inherited controls address the requirement for their specific deployment configuration.
A FedRAMP-authorized cloud service that inherits AC-2 (account management) still requires the customer to document that they use the provider’s inherited account management capability and have not overridden it with customer-managed configurations that break the inheritance. The auditor reviews both the provider’s CRM and the customer’s SSP to confirm alignment. Gaps in that alignment produce partially-inherited control findings even when the provider holds a full authorization.
The Vendor Tier Blind Spot
Organizations securing their primary cloud environment often miss a second layer: SaaS applications that integrate with cloud infrastructure and process regulated data. A HIPAA-covered entity running on AWS with a signed BAA and documented HIPAA controls may also be processing ePHI through a CRM, scheduling tool, or analytics platform that lacks a BAA or has a BAA that has never been reviewed for accuracy.
Each SaaS vendor operating in regulated data scope requires its own shared responsibility analysis. The SaaS vendor’s SOC 2 report covers the vendor’s platform. The customer’s access management policies, data input controls, and integration security controls remain the customer’s responsibility, regardless of the vendor’s certification status.
Conduct a vendor tier review quarterly. List every SaaS application that touches regulated data. For each vendor: confirm an active BAA or equivalent agreement exists (HIPAA), pull the vendor’s current SOC 2 or equivalent report, and document the customer-side controls your team has implemented for that integration. This review becomes part of your vendor management program evidence under CC9.2 [AICPA TSC CC9.2]. Missing a vendor in scope is more common than missing a control in the primary cloud environment.
The cloud shared responsibility model does not reduce compliance obligations. It allocates them. AWS’s SOC 2 closes the physical and environmental controls. Your SOC 2 must close everything else: identity management, access reviews, encryption configuration, logging, monitoring, change management, and application security. Every framework maps the same boundary. Auditors know where the provider’s evidence stops and yours must begin. The organizations that pass cleanly are the ones that mapped that boundary before the auditor arrived.
Frequently Asked Questions
Does the cloud shared responsibility model affect my SOC 2 compliance obligations?
Yes. The cloud shared responsibility model directly defines which SOC 2 Trust Services Criteria controls you must satisfy with independent evidence. Your cloud provider’s SOC 2 report covers the provider’s infrastructure controls. You produce separate evidence for logical access controls (CC6.1, CC6.3), monitoring (CC7.2), and change management (CC8.1) [AICPA TSC CC6.1, CC6.3, CC7.2, CC8.1]. The provider’s report does not substitute for yours.
Does an AWS, Azure, or GCP HIPAA BAA satisfy my HIPAA compliance requirements?
No. The BAA establishes a contractual obligation for the provider to protect ePHI they process on your behalf. It does not satisfy any of your Technical Safeguard requirements under HIPAA 164.312 [HIPAA 164.312]. Access controls, audit logging, encryption configuration, and automatic logoff remain customer obligations regardless of BAA coverage.
What is the difference between inherited controls and customer-implemented controls in FedRAMP?
Inherited controls are satisfied by the cloud provider’s FedRAMP authorization and documented in the provider’s Customer Responsibility Matrix. Customer-implemented controls require the customer to produce independent evidence in their own System Security Plan [FedRAMP Rev. 5]. Partially inherited controls require both: provider evidence for the infrastructure layer and customer evidence for the configuration or application layer. Inheritance must be explicitly documented to hold up in assessment.
Which cloud compliance controls does the customer always own, regardless of service type?
Across IaaS, PaaS, and SaaS deployments on any provider, customers retain ownership of user provisioning and deprovisioning, role-based access assignments, MFA enforcement policies, data classification and handling procedures, and audit log configuration at the account or application level. These controls do not transfer to the provider at any service tier.
How do AWS, Azure, and GCP shared responsibility models differ for compliance purposes?
All three providers follow the same underlying principle: the provider secures infrastructure, the customer secures their deployment. The primary difference is documentation format. AWS publishes shared responsibility guidance by service category. Azure publishes responsibility tables by deployment model (IaaS, PaaS, SaaS). GCP publishes framework-specific responsibility matrices for PCI DSS and HIPAA. Use the provider’s framework-specific matrix for audit preparation rather than the general responsibility model.
Does using a managed cloud service like AWS RDS reduce my compliance obligations?
Managed services reduce infrastructure patching and OS-level obligations. They do not reduce data-layer compliance obligations. With AWS RDS, Amazon manages the database engine patching and underlying hardware. You configure database access controls, TLS enforcement, parameter groups, and audit logging. All of those configurations are customer-owned and produce the evidence auditors request for access control and monitoring criteria.
What evidence does an auditor request for cloud-hosted SOC 2 examinations?
Auditors request four primary evidence categories for cloud-hosted environments: IAM user and role exports with associated permissions for access control criteria, access review records with documented reviewer actions for CC6.3, logging configuration exports showing all-regions enablement and retention periods for CC7.2, and CSPM or configuration baseline reports showing approved configurations and drift alerts for CC8.1 [AICPA TSC CC6.3, CC7.2, CC8.1]. Delivering these proactively at audit kickoff reduces the back-and-forth that extends audit timelines.
Get The Authority Brief
Weekly compliance intelligence for security leaders. Frameworks decoded. Audit strategies explained. Regulatory updates analyzed.
