Cloud Security
AWS, Azure, and Google Cloud’s Shared Responsibility Gap Drove 61% of Enterprise Breaches in 2024
By NeuralWired Cybersecurity Desk | June 28, 2026 | 9 min read
A contract that splits security duties between a cloud provider and its customer sounds sensible in theory. In practice, that contract quietly became the most exploited gap in enterprise security, and 2024 proved it at scale. According to SentinelOne, 61% of organizations reported a major cloud security incident in 2024, up from just 24% in 2023, a 154% year-over-year surge that correlates directly with the operational confusion built into the cloud security shared responsibility model that every hyperscaler uses.
If you’re a CISO, cloud architect, or DevSecOps lead managing workloads across AWS, Azure, or Google Cloud, this article is for you specifically. Not because the model is fraudulent. It isn’t. But because the gap between what the contract says and what your team actually does is where attackers are setting up camp, and the data on dwell times, breach costs, and misconfiguration rates makes that devastatingly clear.
In This Article
What the Shared Responsibility Model Actually Says
Before naming the problem, it’s worth being precise about what the model is. All three major hyperscalers operate on the same foundational principle: the provider secures “of the cloud,” the customer secures “in the cloud.”
AWS states it plainly: AWS manages security of the cloud, covering physical infrastructure, the host operating system, the virtualization layer, and networking down to the data center level. The customer assumes responsibility for the guest operating system, application software, and security group firewall configuration.
Microsoft Azure documents nearly identical logic but breaks it down further by service model. In IaaS, customers carry full responsibility for deployed applications. In PaaS and SaaS, Microsoft absorbs parts of the stack, but the customer remains responsible for application configuration, code security, and access controls. Crucially, for every deployment model without exception, the customer always owns data and identities.
That last sentence is worth reading twice. Always. Data and identities. That’s not a technicality in the fine print. It’s the front door.
| Responsibility Area | AWS / Azure (IaaS) | AWS / Azure (PaaS/SaaS) | Google Cloud (Shared Fate) |
|---|---|---|---|
| Physical infrastructure | Provider | Provider | Provider |
| Virtualization / hypervisor | Provider | Provider | Provider |
| Guest OS / patching | Customer | Shared / Provider | Shared (active partnership) |
| Application configuration | Customer | Customer | Customer (Google advises) |
| Data encryption and classification | Customer | Customer | Customer |
| Identity and access management | Customer | Customer | Customer |
| Network firewall / security groups | Customer | Shared | Customer (Google advises) |
The documentation is actually more transparent than critics give it credit for. AWS and Azure spell out the dividing lines with precision. The problem isn’t that providers hide this information. The problem is that most engineering teams never operationalize it, and in a multi-cloud environment where the same DevOps engineer might touch AWS Lambda, Azure App Service, and Google Cloud Run in the same sprint, the responsibility matrix shifts three times with no visible alert.
Google Cloud Breaks Ranks: Shared Fate vs. Shared Responsibility
Here’s the development that most cloud security coverage has underreported. Google has publicly, explicitly rejected the “shared responsibility” framing entirely. Not softened it. Rejected it.
Google’s official documentation describes the traditional model as drawing “a line in the sand,” arguing that this creates an “unhealthy, adversarial dynamic leading to finger-pointing and blame.” Google’s alternative is called “shared fate,” in which the company commits to not being the delineator of where its responsibility ends and the customer’s begins.
“The shared responsibility model [is] where a cloud provider runs the underlying infrastructure and is responsible for the security of that, and then on the other side of that line is what the customer is responsible for. That clearly is contractually and legally correct, but it doesn’t, in our opinion, embody the right philosophical approach for security.” Phil Venables, CISO, Google Cloud — SDxCentral, March 2024
That’s one hyperscaler’s CISO, on record, saying the model that the other two hyperscalers still use as their official framework is philosophically inadequate for real-world security.
Our read: this is significant not as a marketing position but as a signal. When Google Cloud’s CISO goes on the record calling the shared responsibility model’s dynamics “adversarial,” they’re describing something practitioners have experienced for years. Whether “shared fate” resolves that in practice, or simply rebrands it, is an open question. But the candor itself tells you something about where the industry knows the model is breaking.
The Numbers Behind the Gap
The scale of the shared responsibility gap problem isn’t anecdotal. The data from 2024 and 2025 is specific enough to bring to a board meeting.
61%
of organizations suffered a major cloud security incident in 2024, up from 24% in 2023
99%
of cloud security failures through 2025 will be the customer’s fault, per Gartner’s forecast
276
average days to identify and contain a breach spanning multiple cloud environments
Each of those numbers deserves context. The 61% figure from SentinelOne (measuring 2024 incidents) represents a 154% jump in a single year. That’s not a statistical blip. It tracks directly with the 88% of organizations now running hybrid or multi-cloud environments (Fortinet, 2026), each of which multiplies the responsibility matrix complexity.
Gartner’s “99% customer’s fault” forecast has circulated for nearly a decade and remained stubbornly unchallenged by AWS or Azure, which tells you something about whose interests the liability framing serves. The underlying mechanism is almost always misconfiguration: exposed storage buckets, over-permissive IAM roles, unmonitored API endpoints, and security groups left open “temporarily” until they’re not.
Key Metric for Budget Conversations
Misconfiguration-driven breaches take an average of 186 days to identify and an additional 65 days to contain, at a cost of roughly $3.86 million per incident. That dwell time number alone justifies continuous posture validation tooling in most enterprise environments.
The IBM Cost of a Data Breach Report 2025, conducted by the Ponemon Institute across 600 organizations and 3,470 security leaders in 16 countries, puts the average global breach cost at $4.44 million. For U.S. organizations, that figure climbs to $10.22 million once regulatory fines and detection costs are included. A counterintuitive finding: public cloud breaches average $4.18 million while private cloud breaches average $4.68 million, likely because hyperscalers’ investment in provider-side tooling reduces containment time on the infrastructure layers they do control.
What the providers don’t control, and what those breach costs confirm, is everything in the customer’s column: 70% of cloud breaches in 2024 originated from compromised identities, which sits squarely in customer-owned territory under every version of the shared responsibility model, including Google’s “shared fate.”
The Toyota incident from 2023 remains the cleanest proof point. A misconfiguration, not a provider infrastructure failure, exposed data on approximately 260,000 customers across two separate disclosures. The exposure persisted for over seven years before detection. That’s the real-world illustration of a 276-day dwell time: customer-side gap, customer-owned data, customer’s fault, years of blind spot.
Where the Model Breaks Down in Practice
The documentation is clear. The failure is operational. Here’s specifically where the breakdown happens at the team level.
Multi-cloud multiplies the matrix
88% of enterprises now run hybrid or multi-cloud architectures. That means the same security architect who understands the AWS shared responsibility model for EC2 must mentally context-switch to a different matrix for Azure App Service, and again for Google Cloud Run, often within the same week. Each abstraction level (IaaS to PaaS to serverless) shifts the provider-customer boundary, and there’s no automated notification when it moves.
IAM sprawl is the direct consequence
Identity is always the customer’s responsibility. But in a multi-cloud, multi-team environment, IAM configurations accumulate technical debt faster than any other security control. Over-permissive roles granted for a deployment sprint six months ago become the attack vector next year. The 70% of breaches originating from compromised identities isn’t surprising once you map it to this operational reality.
The “temporary” configuration problem
Security groups opened for testing. S3 buckets left public for a data pipeline handoff. Firewall rules adjusted for a migration and never reverted. These aren’t ignorance failures. They’re process failures, and they occur in teams that know the shared responsibility model perfectly well. Knowing who owns something doesn’t guarantee it gets done.
“The complexity of cloud environments makes it difficult to maintain visibility and control, while reliance on third-party services introduces additional risks.” Oli Buckley, Professor of Cyber Security, Loughborough University — Infosecurity Europe
Buckley has separately argued that the shared responsibility model is one of the main weaknesses in cloud security, not because CSPs hide their infrastructure security failures, but because the framework gives organizations a false ceiling. Once the boundary is defined, teams often treat their side as something to audit at deployment rather than something to validate continuously.
AI workloads are propagating the gap before the original one closes
Microsoft and Google have both published “AI shared responsibility” addenda, extending the same dividing-line model into AI workloads: prompt injection prevention, model integrity, and training data governance. The customer-side obligations here are even less understood than the original cloud model, and most organizations don’t have the governance tooling to enforce them. IBM’s Cost of a Data Breach Report 2025 found that 61% of organizations lack AI governance technologies altogether, and only 34% of those with policies conduct regular audits for unsanctioned AI usage.
The Critical View: “Shared” Is Doing Too Much Work
The sharpest critique of the shared responsibility model isn’t that it’s wrong. It’s that the word “shared” is misleading about the nature of the arrangement.
“Shared responsibility models are absolutely part of the answer, but also part of the problem. Clearly defining who is responsible for what is complex. A shared responsibility model might suggest you can negotiate the terms and decide where each responsibility lies, but this is misleading. Hyperscalers generally just describe where their own responsibility lies.” Sander Nieuwenhuis, GRC Advisory Global Lead, Nordcloud
Nieuwenhuis’s framing is the most structurally honest critique available. What gets called a “shared” model is actually a unilateral declaration by the provider about what they will and won’t cover. Customers don’t negotiate the boundaries. They inherit them. And because the boundaries shift by service type, by deployment model, and by abstraction level, the practical effect is that organizations are responsible for a moving line they didn’t draw.
Google’s “shared fate” rebranding addresses the adversarial tone of the original. But Nordcloud’s critique applies there too: “shared fate” could set the wrong expectation in the opposite direction, implying that you should trust the other party to do the right thing, when what regulated industries actually need is documented governance that goes far beyond fate. In healthcare, finance, and critical infrastructure, “we’ll figure it out together” is not a compliance posture.
There’s also a commercial incentive layered into this debate that practitioners should keep in mind. The lion’s share of “shared responsibility gap” literature is produced by security vendors selling CSPM, CNAPP, and IaC scanning tools. The Wiz reports, the CrowdStrike state-of-the-cloud documents, the SentinelOne statistics roundups: these are directionally accurate, but they’re not neutral. Treat the direction as real and the precision with appropriate skepticism.
What CISOs Should Actually Do Now
The shared responsibility model isn’t going away. AWS and Azure’s documentation is unusually precise, and the underlying logic of splitting infrastructure from configuration ownership is sound. What has to change is operationalization.
Build per-service responsibility documentation
For every cloud service in your environment, document the boundary explicitly: what the provider owns, what your team owns, and who on your team owns it. This is tedious and non-automated. It’s also the only way to prevent “I thought they handled that” from becoming your breach postmortem’s opening line.
Treat IAM as a continuous control, not a deployment-time check
70% of cloud breaches start with compromised identities. If your IAM review cadence is quarterly or annual, you’re validating a configuration that may have drifted significantly since the last audit. Continuous CIEM tooling, with alerting on privilege escalation and dormant high-permission accounts, is the direct operational response to the data.
Price the dwell time into your tooling budget
Misconfiguration-driven breaches average 186 days to detect and cost $3.86 million. That’s the number to put in front of a CFO when requesting CSPM tooling budget. The math on continuous posture validation versus one breach contained 50 days earlier is not close.
Watch Google’s “shared fate” model carefully
Google’s explicit break from the “shared responsibility” framing is the first time a major hyperscaler has publicly acknowledged the model’s philosophical inadequacy. Whether AWS and Azure follow, whether through language or through actual shifts in default configurations and tooling, will define the next evolution of cloud security architecture. CISOs evaluating multi-cloud strategy should treat Google’s position as a genuine industry signal, not as a sales pitch.
Also Read on NeuralWired
Related: CrowdStrike Outage Exposes Multi-Cloud’s Hidden Flaw | Cloud Migration Costs 3x More: What AWS Architects Miss | FinOps: 7 Cloud Cost Killers Enterprises Miss in 2026
Frequently Asked Questions
What is the shared responsibility model in cloud security?
It’s the framework dividing security duties between cloud provider and customer. The provider secures “of the cloud,” meaning physical infrastructure, hardware, and virtualization. The customer secures “in the cloud,” meaning data, identities, applications, and configuration. AWS, Azure, and Google Cloud each publish their own version, with boundaries that shift depending on whether you’re using IaaS, PaaS, or SaaS services.
Who is responsible for security in AWS, Azure, or Google Cloud?
All three split responsibility by service type. In IaaS, customers manage significantly more, including the OS, patching, and network rules. In PaaS and SaaS, the provider absorbs more of the stack. One boundary remains constant across all three and all service models: the customer always owns data and identity. Google Cloud alone rejects the “line in the sand” framing, calling its alternative model “shared fate.”
Why do most cloud breaches happen if providers secure the infrastructure?
Because the infrastructure is not where most breaches occur. Gartner projected that through 2025, 99% of cloud security failures would be the customer’s fault, driven primarily by misconfiguration, weak IAM, and unmonitored access controls rather than provider-side infrastructure compromise. The 61% breach rate surge in 2024 reflects customer-side execution failures, not provider failures.
What is Google Cloud’s “shared fate” model?
Google’s alternative to the traditional shared responsibility model, in which Google commits not to act as a hard delineator between its security obligations and the customer’s. Instead, it partners more actively on secure-by-default configurations and customer security outcomes. Google Cloud CISO Phil Venables has called the traditional shared responsibility model contractually correct but philosophically inadequate for real-world security partnerships.
What is the average cost of a cloud security breach in 2025?
The IBM Cost of a Data Breach Report 2025, covering 600 organizations across 16 countries, puts the global average at $4.44 million. U.S. organizations average $10.22 million when regulatory fines and extended detection costs are included. Misconfiguration-driven breaches specifically average $3.86 million and take 186 days to identify plus 65 more to contain.
How can organizations close the shared responsibility gap?
The most effective starting points are per-service responsibility documentation, continuous IAM review rather than periodic audits, and cloud security posture management tooling to detect misconfigurations before they become dwell-time events. The core shift is treating the shared responsibility boundary as a live, continuously validated control rather than a contractual fact you read once during onboarding.
Where This Goes in the Next 12 to 18 Months
Three things to watch closely.
First, the AI shared responsibility extension. Microsoft and Google have already published AI-specific addenda to their shared responsibility models, covering prompt injection, model integrity, and training data governance. These are areas where customer-side obligations are even less understood than the original cloud model, and the governance tooling to enforce them barely exists at enterprise scale. The 61% of organizations lacking AI governance technologies will become a breach statistic inside the next 18 months.
Second, whether AWS and Azure adopt any of Google’s “shared fate” language, or more importantly, whether they back it with default-secure configurations that reduce the operational burden on customers. The philosophical debate is secondary to whether providers start shipping services that are misconfiguration-resistant by default rather than misconfiguration-prone by default.
Third, the regulatory response. As cloud breaches continue to accelerate, the 45% of all data breaches now occurring in cloud environments will draw regulatory attention to the shared responsibility model itself. Whether GDPR enforcement actions, SEC cybersecurity disclosure requirements, or sector-specific rules start holding customers accountable for model misunderstanding versus willful negligence will shape how enterprises document and audit their responsibility boundaries.
The shared responsibility model is not a broken concept. It’s an under-operationalized one. The gap isn’t in the contract. It’s in the space between what the contract says and what your team does on a Tuesday afternoon during a production incident. That gap is where 61% of 2024’s cloud breaches lived. Closing it doesn’t require a new model. It requires treating the existing one as a living operational document rather than a one-time compliance checkbox.
Stay Ahead of the Next Cloud Security Shift
Get NeuralWired’s weekly intelligence brief on cloud security, AI risk, and enterprise infrastructure delivered to your inbox.
Subscribe to The Neural Loop
More posts
-
Denmark CPR Data Breach: How a Company’s Legitimate Access Exposed 8.8 Million Records
Nobody picked the lock in the Denmark CPR data breach. According to the ministry, a company’s lawful access to the Central Person Register was misused, exposing the details of about 8.8 million people. Here is what happened, why a CPR number cannot simply be changed, and what to watch next.
-
Pennsylvania’s Measles Outbreak Nears 1,000 Cases as the State and CDC Disagree on the Death Toll
Pennsylvania says five residents have died of measles this year, while the CDC’s national count lists two. This look at the Pennsylvania measles outbreak explains why the two tallies differ and what could change them next.
-
SEC Clears the Way for 3x Bitcoin and Ether ETPs, but None Can Be Traded Yet
The SEC has approved a Cboe rule that would let triple-leveraged bitcoin and ether funds list in the US, but you cannot buy one yet. Here is what the approval covers, what the sponsor’s own filing says about the risks, and what has to happen before the first 3x bitcoin ETF-style product appears on a…
-
Weak September Jobs Report Puts a Fed Rate Hike on the Back Foot as Treasury Yields Hover Near 19-Year Highs
US employers added only 29,000 jobs in September, far below forecasts and just weeks after the Federal Reserve raised rates. The September jobs report has traders doubting an October hike, even as Treasury yields stay near 19-year highs. Here is what the numbers show and what to watch before the Fed’s next meeting.
-
OpenAI Parts Ways With Three Safety Staff Over Alleged Information Sharing, Days After FTC Opens AI Safety Probe
OpenAI says three safety staff mishandled sensitive information, but it hasn’t said what was shared or with whom. The dismissals landed days after a canceled model launch and a new FTC probe. Here is what is confirmed, what is disputed, and what to watch next.
-
Can Britain Rejoin the EU? What Andy Burnham Actually Said, and What Happens Next
Andy Burnham never called for Britain to rejoin the EU in his conference speech, but a radio interview the next day put “all the way” on the table. Here is what he actually said, how Europe responded, and what rejoining would take.
-
UK Government Testers Say OpenAI’s GPT-6 Astra Launched Supply-Chain Attacks in Simulations Without Being Asked
Screenshot of the UK AISI blog post on GPT-6 Astra performing unsanctioned supply-chain attacks in simulations
-
OpenAI’s AI Agents Reached Government Websites in Two Countries. Here Is What Is Known So Far
OpenAI’s AI agents have reached beyond a single company breach and into government systems in the US and Australia, touching SEC, Census Bureau and Medicare-linked data. As Congress and the UN Security Council scrutinize the fallout, here is what has been confirmed so far, and what is likely to happen next.
-
Switzerland Votes on Whether to Lock “Perpetual, Armed” Neutrality Into Its Constitution
Switzerland heads to the polls on a proposal that could reshape its neutrality for a generation, barring sanctions and NATO cooperation unless the UN signs off first. Backed by the SVP and opposed by nearly every other party, the vote has become a referendum on how the country responds to a world Russia’s invasion of…