The Shared Responsibility Model Nobody Reads (Until They're Breached)

Every AWS, GCP, and Azure customer agreed to the shared responsibility model the moment they created an account. Almost none of them have read it closely enough to know where the line actually falls.

That gap matters more than it sounds like it should. The shared responsibility model isn't a footnote. It's the document that decides who is on the hook when something goes wrong, and the line it draws is narrower than most buyers assume.

What the Provider Actually Protects

Hyperscalers are explicit about this, even if the language is buried in documentation most teams never open. AWS, GCP, and Azure are responsible for the security of the cloud: the physical data centers, the host infrastructure, the hypervisor layer, and the global network backbone. That's a real and substantial commitment, and the major providers generally execute it well.

What they are not responsible for is security in the cloud. That includes:

• Operating system patching on your instances
• Network configuration, security groups, and firewall rules
• Identity and access management policies
• Data encryption, both at rest and in transit
• Application-layer security
• Customer data itself

That second list is where the majority of cloud breaches actually happen, and it's entirely the customer's responsibility under every major hyperscaler's terms of service.

The Assumption Gap

Here's the problem: most buyers don't operate as if they understand this split. Research on the shared responsibility model consistently shows that customers assume their provider is covering more than the contract specifies, and that mismatch between assumption and reality is the source of a large share of cloud security incidents.

This isn't a knowledge problem that better onboarding emails would solve. It's a structural one. The shared responsibility model puts the customer in charge of an enormous and constantly shifting list of configuration surfaces, identity policies, and patch schedules, while the marketing language around "the cloud" implies a level of comprehensive protection the contract never promised.

The data backs this up clearly. Gartner projects that through 2025, 99% of cloud security failures will be the customer's fault, not the provider's. That number is jarring until you see it next to the shared responsibility split: the provider secures a layer most customers never touch directly, while the layer customers do touch is the one with no safety net underneath it.

Where This Plays Out in Practice

The pattern shows up the same way across breach after breach: a misconfigured permission, an exposed credential, a security group left open longer than intended. None of these are hyperscaler failures. All of them sit squarely inside the customer's half of the shared responsibility line.

SentinelOne's research found that public cloud organizations faced security incidents at a rate of 27% in 2024, compared to 19% for organizations on private cloud infrastructure. The same research found that the average AWS account carries 43 active misconfigurations at any given time. Exabeam's research on the cause of those misconfigurations is direct: 82% are the result of human error, not software defects.

Put those together and the picture is consistent. It's not that public cloud infrastructure is insecure. It's that the customer's half of the shared responsibility model is large, technical, and unforgiving, and most teams are running it with less dedicated security capacity than the model assumes they have.

Why This Boundary Is the Real Risk

The shared responsibility model isn't designed to fail customers. But it is designed in a way that quietly shifts the largest, most error-prone portion of cloud security onto the party least equipped to staff it full-time: the customer's own engineering team, who are also trying to ship product.

This is the boundary that matters more than any individual vulnerability. A team can patch a CVE. A team can rotate a leaked key. What's harder to fix is an operating model that assumes a growth-stage engineering team has the bandwidth to be a full-time cloud security operation on top of everything else they're responsible for.

Closing the Gap

InMotion Cloud's managed private cloud model is built around a different premise. Instead of asking the customer to own the security-in-the-cloud half of the equation, InMotion Cloud's engineering team manages it as part of the platform.

That means hardware provisioning and maintenance, hypervisor and OS patching, network configuration and security groups, and security monitoring and alerting are all handled by InMotion Cloud's senior engineering team, not left as a checklist for the customer's DevOps team to maintain indefinitely. The customer still owns what they should own: the application layer, the code, the data, and the business logic. What changes is the size of the list sitting entirely on the customer's side of the line.

The shared responsibility model isn't going away on any hyperscaler platform. The honest question for any team currently running production workloads on AWS, GCP, or Azure is whether they actually have the dedicated capacity to own their half of it, or whether that capacity gap is exactly the kind of risk that shows up in next year's breach statistics.

See Where the Line Actually Falls

If you want a clear picture of what you're responsible for on your current cloud setup versus what a managed private cloud model would take off your plate, InMotion Cloud's team can walk through it with you, no obligation required.