Why Shared Responsibility Is a Contract Problem
Cloud security shared responsibility is treated as a diagram to acknowledge rather than a clause to negotiate, and that is exactly why it goes wrong. The numbers make the stakes clear: through 2025, around 99% of cloud security failures have been attributed to the customer side, primarily misconfiguration, with 82% of those misconfigurations stemming from human error. The average data breach now costs $4.35-4.44 million globally and over $10 million in regulated sectors, and a misconfiguration-driven breach takes roughly 186 days to identify and another 65 to contain. When the fault usually sits with the customer, the contract that defines where the customer's responsibility actually ends becomes the most important security document the enterprise signs.
The problem is that standard cloud agreements do not define it. As the cloud security and compliance contracts pillar sets out, SLAs are written around uptime and support, not data protection and breach response, so the responsibility split lives in marketing diagrams and not in the enforceable agreement. That ambiguity is where each party assumes the other is accountable — and where, after an incident, the liability falls on whoever has the weaker contract.
Who Owns What: Of the Cloud vs In the Cloud
Every major provider — AWS, Microsoft Azure and Google Cloud — frames the model the same way: security of the cloud versus security in the cloud. The provider is responsible for the infrastructure — data centres, hardware, the network fabric — while the customer is responsible for what they place on it: data, identities, endpoints, applications and, above all, configuration. The wording is consistent across vendors; what changes is the line's position, and that shift by service model is the part buyers most often get wrong.
With Infrastructure as a Service, the customer owns everything from the guest operating system up — the most control and the most responsibility. With Platform as a Service, the provider absorbs the operating system, network controls and audit logging, leaving the customer with data, code and application security. With Software as a Service, the provider assumes the most operational and security burden, but the customer never fully escapes responsibility for data, access and identity. Misreading which tier a given service sits in is how an enterprise ends up assuming a provider secures something it never agreed to.
| Responsibility | IaaS | PaaS | SaaS |
|---|---|---|---|
| Physical / infrastructure | Provider | Provider | Provider |
| Operating system | Customer | Provider | Provider |
| Network controls | Customer | Shared | Provider |
| Application security | Customer | Customer | Shared |
| Data, identity, access | Customer | Customer | Customer |
| Configuration | Customer | Customer | Customer |
Data, identity and configuration stay with the customer at every tier — IaaS, PaaS and SaaS alike. Since 99% of cloud failures are customer-side and configuration is the leading cause, the contract should fund the tooling that controls those layers, not assume the provider covers them.
The Liability Gap and the Super Cap
The most expensive ambiguity in cloud security shared responsibility is financial. A standard master-agreement liability cap — typically a multiple of fees paid — is an order of magnitude below modern regulatory exposure. A GDPR penalty can reach EUR 20 million or 4% of annual global turnover, and where a provider's negligence causes a breach that triggers that fine, the standard cap leaves the enterprise carrying the difference. The cap that looks routine in the contract is in fact a transfer of risk onto the customer for a failure they may not have caused.
The remedy is a separate, higher data-breach liability cap — a "super cap" — negotiated specifically for security failures and sized to your real regulatory exposure, paired with provider indemnification where the provider's negligence is the cause. This is the same risk-allocation discipline our vendor audit defence practice applies to compliance disputes, and it belongs in the agreement before signature, because no provider reopens a liability cap after an incident. The Cloud Contract Framework treats the super cap as a default term, not an exception.
Closing the Shared Responsibility Gap
Five clauses convert the shared responsibility diagram into an enforceable contract. First, a responsibility matrix annexed to the agreement, mapping each security control to an accountable party for the specific services purchased — the single most effective way to remove the "I assumed you had it" gap. Second, the data-breach super cap and indemnification described above. Third, incident-notification timelines stated in hours, not the unenforceable "without undue delay", so you can meet your own regulatory reporting clock.
Fourth, audit rights that let you or an independent assessor verify the provider's controls rather than relying on an annual attestation, plus clear treatment of subcontractor liability, since many providers expressly disclaim responsibility for the third-party hosts they depend on. Fifth, exit terms defining data portability and secure destruction. Because the customer owns data, identity and configuration at every tier, the tooling that governs those layers — vulnerability management for misconfiguration, DLP for data, zero trust for identity, and SIEM for detection — is what actually discharges the customer's side of the bargain. If your organisation is negotiating or renewing a cloud agreement, request a confidential briefing and our cloud contract negotiation team will build the responsibility matrix, size the super cap, and write the clauses that close the gap.