The Model Everyone Agrees With and Almost Nobody Applies Correctly
Every cloud provider publishes a shared responsibility model. Every enterprise cloud security team has reviewed it. The principle is clear: the cloud provider is responsible for the security of the cloud infrastructure; the customer is responsible for security in the cloud, meaning the configuration of services, the protection of data, the management of access, and the security of applications.
The principle is clear. The application is not. The most common root cause of preventable cloud security incidents is not ignorance of the shared responsibility model. It is the systematic misapplication of it in specific service categories, compounded by the assumption that the cloud provider’s security certifications extend to configurations the customer controls.
A cloud provider holding SOC 2 Type II, ISO 27001, and PCI DSS certifications has demonstrated that its infrastructure meets rigorous security standards. Those certifications say nothing about whether the services the customer has deployed on that infrastructure are configured securely. The security of an S3 bucket’s access policy, an RDS instance’s encryption settings, an IAM role’s permission scope, and an API gateway’s authentication configuration are all customer responsibilities that the cloud provider’s certifications do not touch. When a security incident results from a misconfigured customer-controlled resource, the cloud provider is not responsible. The shared responsibility model said so. The customer simply did not apply it to this specific resource.
The Four Most Common Misalignment Patterns
The misapplications of shared responsibility that cause the most frequent incidents cluster around four service categories, each with a characteristic mistake.
Identity and access management in managed services is the first and most prevalent misalignment. When a customer deploys a managed database service, the cloud provider manages the database engine, the underlying infrastructure, and the patch management process. The customer manages who has access to the database, at what privilege level, and through which authentication mechanism. The security incidents that arise from IAM misalignment in managed services typically involve overprivileged service accounts created for convenience and never reviewed, or default credentials that were not changed because the managed service’s setup flow did not surface the credential change as a required step.
Data protection in Platform-as-a-Service environments is the second pattern. When a customer deploys an application using a PaaS service, the cloud provider manages the runtime, the operating system, and the infrastructure. The customer manages the data the application processes: whether it is encrypted at rest and in transit, what retention and deletion policies apply, and which data protection controls are configured in the managed storage services the application uses. PaaS environments that handle customer data without explicitly configuring the data protection controls the customer is responsible for are a consistently recurring source of data exposure incidents.
Network security in serverless and container-as-a-service environments is the third pattern. Serverless functions and managed container services abstract away the networking layer in ways that can create the impression that network security is the provider’s responsibility. In practice, the provider manages the underlying network infrastructure; the customer manages the network-level security controls for their applications: the VPC configurations, the security groups and network policies, and the egress controls that prevent unexpected outbound data flows. Serverless environments with unconstrained network egress are a persistent misconfiguration pattern.
Compliance in multi-cloud environments is the fourth and most complex misalignment. Multi-cloud architectures add a layer of complexity to shared responsibility that organisations with single-provider deployments do not face: the shared responsibility model differs between providers for equivalent services. An organisation that has developed a clear understanding of shared responsibility for storage services on one cloud provider cannot assume the same model applies to equivalent services on a second provider. The compliance gaps that emerge from assuming equivalence where none exists are among the most difficult to identify through automated posture management tools because they require comparing configurations across different provider models.
The Shared Responsibility Audit Framework
The systematic approach to identifying shared responsibility gaps starts with a service inventory that maps the organisation’s cloud service usage to its responsibility boundaries. The inventory is not a list of cloud services. It is a mapping of each service type to the specific security controls for which the customer is responsible, derived from the cloud provider’s documentation rather than from assumptions.
For each service type in the inventory, the audit asks three questions. Has the customer documented the specific security controls they are responsible for under the shared responsibility model for this service type? Have those controls been implemented in the current deployment? Is there an automated mechanism that continuously validates that the controls remain in place?
The third question is the one that most shared responsibility audits miss. Documentation and initial implementation are necessary but not sufficient. Cloud environments change continuously. A security control that was correctly configured at deployment may be incorrectly configured after a change made for operational reasons that did not account for its security implication. Continuous validation, through CSPM tooling or policy-as-code enforcement in the deployment pipeline, is the mechanism that converts a point-in-time audit into an ongoing assurance programme.
The audit framework should also specifically address the transition points between service tiers. Moving from Infrastructure-as-a-Service to Platform-as-a-Service, or from PaaS to Software-as-a-Service, changes the responsibility boundary in ways that require explicit re-evaluation. The organisation that understands its responsibilities for an IaaS compute instance and assumes those responsibilities transfer unchanged to an equivalent PaaS service is at risk from the assumption.
Making the Results Actionable
The shared responsibility audit produces findings that fall into three categories. Controls that are documented, implemented, and continuously validated are the correct state. Controls that are documented and implemented but not continuously validated require the addition of automated validation. Controls that are not documented or not implemented require immediate remediation, prioritised by the data sensitivity and business criticality of the service.
The remediation programme should be structured so that the highest-risk gaps are addressed first, and so that each remediation is followed by the addition of continuous validation to prevent recurrence. The goal of the remediation programme is not to reach a state where every finding is resolved. It is to reach a state where the shared responsibility model is documented, implemented, and continuously validated for every service category in the cloud estate, with residual gaps visible and being actively managed.
The Governance Process That Prevents Recurrence
The shared responsibility gaps that the audit identifies are the product of a governance process that did not include shared responsibility verification as a deployment gate. The ongoing governance process that prevents recurrence adds that verification.
The new service type checklist is the simplest and most durable mechanism. Before any new cloud service type is adopted in production, a member of the security team reviews the shared responsibility documentation for that service type, documents the customer-owned security controls, and verifies that those controls are implemented in the organisation’s deployment configuration. The review adds a small overhead to the new service adoption process and prevents the gap that would be discovered in a security incident six months later.
The shared responsibility model will not make cloud environments secure by itself. But consistently and correctly applying it, across every service type and every deployment, is the baseline that every other cloud security control depends on.