5 Shared Responsibility Model Gaps Teams Keep Missing
The shared responsibility model is not vague about where provider duty ends; what makes it fail in real environments is the unowned middle. The provider secures facilities, hardware, and the virtualization layer; the customer assumes responsibility for the guest operating system, including updates and security patches, plus application software and the provider firewall configuration — and everything above it: identities, buckets, policies, encryption settings, and logging. Five gaps recur in nearly every estate, and none of them is fixed by buying another scanner.
Where the Line Actually Sits
AWS frames the split as security of the cloud versus security in the cloud, and the line moves with every service choice. On EC2, an infrastructure service, customers perform all operating system hardening, patching, and firewall configuration themselves. On abstracted services such as S3 and DynamoDB, the provider runs the platform layer and the customer’s exposure shifts to data classification, encryption choices, and IAM permissions. The same team can carry very different residual risk per service with no dashboard that says so.
For assigning internal ownership, one test beats every diagram: if you have access to configure the resource, you are responsible for the security of that resource. That is AWS’s own simplest interpretation of the model, and it is the foundation for distributing security work to application teams without arguments about jurisdictions.
Five Gaps Teams Miss
The same gaps show up across providers, industries, and maturity levels. Each one starts as an assumption nobody wrote down.
| Gap | Unspoken assumption | What actually happens | Corrective move |
|---|---|---|---|
| Split patching duties | “The provider patches our stack” | Guest OS and frameworks wait unpatched; managed-service updates need customer-approved windows | Write a per-service patch contract: provider SLA on one side, your maintenance windows on the other |
| Console sprawl | “One team sees all policy” | Rules live in three or more consoles; nobody holds the merged view | Export policy state into a single inventory refreshed on every change |
| Manual policy changes | “Reviews catch mistakes” | Hand-edited rules ship typos straight to production | Generate policy from code and validate before apply |
| Attestation equals coverage | “The provider’s audits cover us” | Inherited controls cover the facility layer; your configuration layer stays unverified | Map each compliance requirement to who operates the control: provider, you, or both |
| Abstracted services feel safe | “S3 is managed, so it is secure” | Data exposure comes from bucket policy, not platform failure | Enforce preventive guardrails on public access and encryption at the organization level |
The fifth gap deserves emphasis because it inverts intuition: the more a service abstracts away, the more the remaining customer controls — permissions, retention, encryption — concentrate the entire risk. A managed database with a permissive public setting is a breach waiting for a script, not a failure of the provider.
What Incident Data Shows
The damage from these gaps is measurable. In a Cloud Security Alliance survey reported in August 2026, 65% of surveyed IT and security professionals reported at least one business-critical application outage attributed to a misconfigured security policy during the previous twelve months. The same research found 92% had difficulty getting one accurate policy view across environments, 48% described policy changes as mostly or fully manual, and 67% use three or more management consoles daily. Policy errors are not primarily a tooling problem; they are an operating-model problem in which Security Operations, Network Operations, cloud architects, and application owners each hold a piece of the same rule set.
Shared Fate Moves the Default
Google Cloud has argued the model itself is the ceiling: the shared responsibility model stops short of helping cloud customers achieve better security outcomes, so the provider should take an active role through what it calls shared fate — opinionated defaults, secured landing zones, attested infrastructure code, and risk programs that go beyond drawing a line. Whatever you think of the branding, treat it as a design signal. When a provider ships secure-by-default configurations and validated blueprints, the customer-side misconfiguration surface shrinks, because the insecure option was never reachable in the first place.
An Operating Model That Holds
Closing the gaps is sequenced work, not a purchase. This order minimizes rework:
- Assign ownership by configuration access. Every resource class gets a named team using the configure-it-you-own-it test; publish the map where engineering can find it.
- Contract the split controls. For patching, service updates, and communications protection, document which half the provider runs and which half your team schedules, with dates and SLAs.
- Consolidate policy visibility. Pull firewall, IAM, and bucket policy state into one inventory before adding automation — pre-change risk analysis needs a baseline to compare against.
- Move policy into pipelines. Generate rules from code with pre-apply checks; when identity paths drift anyway, follow a CloudTrail privilege-escalation runbook instead of ad-hoc console forensics.
- Guard the state layer. Infrastructure definitions are the highest-value target in your estate; enforce Terraform state controls so a leaked state file cannot replay your whole environment.