BLOG

Key Takeaways

• The shared responsibility model is a legal and contractual framework, not just a security concept. When a breach results from a cloud misconfiguration, the provider’s terms of service establish that securing that configuration was the customer’s contractual obligation. The provider’s security certifications, including ISO 27001, SOC 2, and PCI DSS attestations, cover the infrastructure the provider operates; they do not extend to the configurations the customer deploys on top of it. Understanding the boundary is not only a security planning question but a risk and liability question.
• The boundary shifts based on the service model. For IaaS, such as AWS EC2 or Azure Virtual Machines, the customer is responsible for the operating system, runtime, applications, and data, in addition to network configuration and IAM. For PaaS, such as AWS RDS or Azure SQL Database, the provider manages the operating system and database engine; the customer owns the data, access controls, network exposure, and database configuration. For SaaS, such as Microsoft 365, the provider manages almost everything in the platform; the customer owns tenant configuration, identity governance, and data protection. As the service model moves up the stack, the provider takes on more infrastructure responsibility, but the customer’s identity, configuration, and data responsibilities remain.
• Identity and access management is always the customer’s responsibility, regardless of platform or service model. The provider issues the IAM framework and the tools; the customer decides who gets which permissions, whether MFA is enforced, which roles have administrative rights, and whether service accounts are scoped correctly. The most common identity-related cloud breach, compromised credentials with excessive permissions reaching resources far beyond the initial compromise, results entirely from customer-side IAM decisions the provider had no role in.
• Data classification and protection is always the customer’s responsibility. The provider encrypts data at rest with provider-managed keys by default. The customer decides whether to use customer-managed keys, how data is classified and labeled, who can access specific data stores, whether data can be shared externally, and what DLP policies govern how data moves. A publicly accessible S3 bucket exposing sensitive customer records is not a failure of AWS security; it is a failure of the customer’s storage configuration, which AWS had no obligation to prevent.
• Compliance attestations cover the provider’s infrastructure, not your workloads. When a provider publishes a PCI DSS Attestation of Compliance or an ISO 27001 certificate, those documents attest that the provider’s infrastructure meets the standard. They do not attest that workloads running on it meet the standard. An organization that relies on its provider’s certifications to satisfy its own PCI DSS or ISO 27001 requirements is misunderstanding the model in a way that produces findings in every audit.

The Responsibility Line, Platform by Platform

Amazon Web Services (AWS)

AWS defines its shared responsibility model as security “of” the cloud (AWS) versus security “in” the cloud (the customer). AWS is responsible for the physical infrastructure: the data centers, the hardware, the network fabric, and the virtualization layer that runs EC2 instances. AWS is also responsible for the security of managed services at the infrastructure level: the underlying compute, storage, and networking that runs services like S3, RDS, Lambda, and EKS.

The customer is responsible for everything configured and deployed within AWS: IAM policies and role assignments (who can access what and with what permissions), S3 bucket policies and access control lists (whether data is publicly accessible), security group rules (what network traffic is permitted to reach instances and services), VPC configuration (network segmentation and routing), CloudTrail and logging configuration (whether administrative actions are recorded), encryption settings for data at rest and in transit (whether data in S3, RDS, and other services uses the appropriate key management), and the operating system and application security of EC2 instances and containers. The most common breach patterns in AWS environments reflect exactly these customer-side misconfigurations: public S3 buckets, overpermissioned IAM roles, security groups open to the internet on administrative ports, and CloudTrail disabled so that the attacker’s activity is not logged.

Microsoft Azure

Microsoft Azure’s shared responsibility model follows the same structure as AWS, with the specific controls varying by service. Microsoft is responsible for the physical infrastructure of Azure data centers, the hypervisor, and the network fabric. For managed services, Microsoft extends its responsibility to the managed platform: the operating system for Azure SQL Database, the Kubernetes control plane for Azure Kubernetes Service, and the runtime environment for Azure Functions.

The customer is responsible for Entra ID (formerly Azure Active Directory) configuration: role assignments, Conditional Access policies, MFA enforcement, privileged identity management, and service principal permissions. Network Security Group rules, Azure Firewall configuration, and virtual network architecture are the customer’s responsibility. Storage account access tiers, including whether blobs are publicly accessible, are the customer’s responsibility. Key Vault access policies and the rotation of secrets and certificates are the customer’s responsibility. Microsoft Defender for Cloud is a tool Microsoft provides; whether it is configured and its alerts acted upon is the customer’s responsibility. A recurring pattern in Azure breaches is the misconfiguration of Entra ID: service principals with excessive permissions, Conditional Access policies with too many exceptions, and MFA not enforced for administrative accounts. These are all customer-side configurations that Microsoft’s infrastructure security controls do not and cannot prevent.

Google Cloud Platform (GCP)

Google Cloud operates the same shared responsibility structure as AWS and Azure. Google is responsible for the physical infrastructure, the network fabric, the hardware security module infrastructure, and the control plane of managed services like Google Kubernetes Engine. Google also provides a suite of security tools through the Security Command Center, but configuring and acting on those tools is the customer’s responsibility.

The customer is responsible for IAM bindings that control who can access which GCP resources and with what permissions, VPC firewall rules that govern network traffic, Cloud Storage bucket permissions and uniform bucket-level access settings, Cloud Logging configuration and log sink management, the Kubernetes RBAC configuration for workloads running on GKE, and the security settings for Cloud SQL instances including network exposure and IAM authentication configuration. GCP environments are particularly susceptible to the IAM binding misconfiguration pattern: the allUsers and allAuthenticatedUsers principals in GCP IAM allow any internet user or any Google-authenticated user, respectively, to access a resource without being in the organization’s own IAM directory. Resources exposed to allUsers are publicly accessible; this is entirely a customer-side configuration that the organization controls.

Microsoft 365

Microsoft 365 represents the SaaS end of the service model spectrum, where Microsoft manages the most and the customer’s responsibility is concentrated in tenant configuration and identity governance rather than infrastructure. Microsoft is responsible for the uptime and availability of the M365 platform, the encryption of data at rest within Microsoft’s data centers, the security of the M365 application code and infrastructure, and the physical security of the data centers where M365 data is stored.

The customer is responsible for the entire tenant configuration: Conditional Access policies that control who can access M365 services from where and with what authentication requirements, Defender for Office 365 configuration including Safe Attachments, Safe Links, and anti-phishing policies, Data Loss Prevention policies that govern how sensitive data can be shared within and outside the organization, SharePoint and OneDrive external sharing settings, Teams governance and guest access controls, sensitivity labels and information protection configuration, privileged identity management for administrative roles, audit logging enablement and retention, and the Secure Score remediation actions that address the most impactful configuration gaps. A Microsoft 365 tenant operating at default settings, without any customer-side security configuration, presents significant exposure that Microsoft’s platform security does not and cannot address. This is the premise of Armour Cybersecurity’s M365 Security Optimization engagement: the platform is secure; the tenant configuration is the customer’s responsibility, and most organizations have not configured it to an adequate standard.

What Misunderstanding the Model Costs

The most damaging misunderstanding of the shared responsibility model is the assumption that using a major cloud provider’s platform with strong security certifications means the workloads and configurations on that platform are secure by association. This assumption leads directly to the configuration gaps that produce the most significant cloud breaches: the S3 bucket left public because the team assumed AWS would prevent public data exposure, the Azure SQL database accessible from the internet because the team assumed Azure’s platform security would block unauthorized access, the M365 tenant with no Conditional Access policies because the team assumed Microsoft’s platform security covered login protection.

The cloud provider’s compliance certifications are documentation that the provider has met the standard for the infrastructure they operate. They are not documentation that your workloads, configurations, or data handling meet any standard. Auditors who review cloud-hosted environments as part of a SOC 2, ISO 27001, PCI DSS, or HIPAA assessment understand the shared responsibility model precisely and evaluate the customer-side controls, not the provider’s infrastructure certifications. An organization that presents its cloud provider’s SOC 2 report in response to an auditor’s request for evidence of its own controls will receive a finding noting that the evidence addresses the wrong side of the responsibility line.

Across the 260+ organizations Armour Cybersecurity protects in 52+ industries, the most expensive cloud incidents are rarely the ones where the provider’s infrastructure failed. They are the ones where a competent team assumed the provider’s certifications extended to their own configuration, and left a bucket, an identity, or a tenant setting unowned on the customer side of a line they had not mapped.

A cloud security program addresses the customer’s side of the shared responsibility model comprehensively: posture assessment to establish the baseline across every customer-side configuration, CSPM to monitor continuously for drift, identity hardening to enforce least privilege and MFA across all platforms, infrastructure hardening against CIS Benchmarks, and managed monitoring to detect and respond to threats that exploit customer-side configuration gaps. The provider handles the infrastructure; the program handles everything the provider does not.

Frequently Asked Questions

If we are breached because of a cloud misconfiguration, is the cloud provider liable?

No. The cloud provider’s terms of service explicitly establish that the customer is responsible for the configurations deployed in their account. A breach resulting from a misconfigured storage bucket, an overpermissioned IAM role, or an exposed administrative port is a breach of the customer’s configuration, not the provider’s infrastructure. The provider’s liability for service availability is typically governed by the service level agreement, not by the security of customer configurations. The legal and regulatory consequences of a breach from a customer-side misconfiguration fall on the customer: the data breach notification obligations, the regulatory fines for failing to implement required controls, and any civil liability to affected parties. This is precisely why understanding and actively managing the customer side of the shared responsibility model is a risk management priority, not merely a technical consideration.

How do compliance frameworks like PCI DSS and HIPAA apply to cloud environments?

Compliance frameworks apply to wherever the in-scope data exists and flows, not to the infrastructure platform on which it runs. An organization processing cardholder data in AWS is subject to PCI DSS for those workloads regardless of AWS’s own PCI DSS compliance. The organization must demonstrate that the customer-side controls it has implemented in AWS, such as IAM policies, network segmentation, encryption, logging, and access management, meet PCI DSS requirements. AWS’s PCI DSS Attestation of Compliance demonstrates that the infrastructure the organization is using meets the standard at the infrastructure level; the organization’s own controls assessment demonstrates that the organization’s use of that infrastructure meets the standard at the configuration and application level. Both are required; neither is sufficient without the other. Armour Cybersecurity’s cloud security program includes compliance mapping documentation that organizes the customer-side controls against each applicable framework, structured for direct use by QSAs, ISO 27001 assessors, and SOC 2 auditors.

What does a cloud security posture assessment evaluate on the customer side?

A cloud security posture assessment evaluates the full set of customer-side configurations across the cloud platforms in scope: IAM policies, role assignments, and permission boundaries; network configuration including security groups, VPC peering, public subnets, and internet gateways; storage configuration including bucket policies, access control lists, and encryption settings; logging and monitoring configuration including which logging services are enabled, what retention periods are set, and whether alerts are configured; data protection settings including encryption key management, DLP policies, and data classification; administrative account configuration including MFA enforcement, privileged access controls, and separation of administrative from daily-use accounts; and compliance posture across the applicable frameworks including the number and severity of failing checks against each benchmark. The assessment produces a prioritized remediation roadmap that sequences the identified gaps by risk level and estimated remediation effort, giving the organization a structured plan for closing the customer-side gaps that CSPM will then monitor for recurrence.

The Bottom Line

The cloud shared responsibility model is simple to state and expensive to misread: the provider secures the infrastructure, and you secure everything you build on top of it. The line shifts a little from IaaS to PaaS to SaaS, but identity, data, and configuration never leave your side of it, on AWS, on Azure, on Google Cloud, or in Microsoft 365. Every provider certification you rely on covers their half, not yours, and every auditor knows the difference. The organizations that stay out of the breach headlines are the ones that mapped their side of the line and put a program on it. Armour Cybersecurity’s cloud security program owns that customer side end to end, across every major platform, so the responsibility that is contractually yours is actually covered.