The Shared Responsibility Model

Why the model exists

Before public cloud, security was conceptually simple — you bought hardware, you secured everything from the rack up. When AWS launched EC2 in 2006, it raised an obvious question: "If Amazon is running my server, are they responsible for keeping it patched? Is my data their problem?"

The shared responsibility model is the answer. It's a contract — partly explicit, partly implicit — that says: we (the provider) handle the things you can't see and can't touch; you (the customer) handle everything else.

The model isn't a regulatory document or a single specification. Each provider publishes their own version — close in shape but different in detail. The CSA's Cloud Controls Matrix attempts a vendor-neutral version. NIST SP 800-145 defines the IaaS/PaaS/SaaS service models that the responsibility line traces. ISO 27017 codifies the model in compliance language.

By service model: IaaS, PaaS, SaaS, FaaS

The single biggest variable in the model is which service tier you're using. The customer's responsibility shrinks as you move up the stack.

IaaS — you own everything above the hypervisor

EC2, Azure Virtual Machines, GCE, Lightsail, bare-metal services. You picked the OS image, so you own its patching, hardening, and runtime monitoring. You picked the security group rules and the VPC layout — those are yours. You wrote the code on top — definitely yours. The provider's job ends at "the VM boots and the network works."

Real-world implication: if the OS in your EC2 instance is unpatched and gets popped, that's not AWS's problem. They'll keep CloudTrail running so you can see what happened, and they'll honor your encryption-at-rest setting, but they're not going to ask you to update Apache.

PaaS — provider takes the OS, you keep configuration and code

App Service, Cloud Run, Elastic Beanstalk, RDS, Cloud SQL, Aurora. The runtime gets patched for you — when AWS releases a new RDS engine version, they'll prompt you to upgrade but they handle the actual patch. Same for App Service's underlying .NET runtime, or App Engine's Python interpreter.

You still own: the database schema, IAM policies, network endpoints, application code, and dependencies. Critically, you still own identity — a database with a default password is your problem regardless of who's patching MySQL.

SaaS — provider runs the application; you keep data and access

Microsoft 365, Salesforce, Workday, Slack, GitHub, Snowflake (yes, it's mostly SaaS). You don't see the runtime; you don't pick the version; you don't care about the OS. But you absolutely still own:

• User accounts and access — every M365 admin without MFA is your incident waiting to happen.
• Data classification and DLP — Salesforce won't stop your sales rep from emailing customer lists.
• Sharing and collaboration settings — open-by-default link sharing in OneDrive/Drive is the source of constant data leaks.
• Third-party app integrations — OAuth grants you forgot about.
• Audit log review — providers will keep the logs; whether anyone's watching them is on you.

The Snowflake / UNC5537 wave (2024) is the canonical SaaS-side breach pattern: customers using Snowflake without MFA enforcement, attacker uses infostealer-harvested creds to log in, exfiltrate data. Snowflake didn't get breached. Their customers' configurations did.

FaaS / Serverless — the awkward in-between

Lambda, Cloud Functions, Azure Functions. The OS, runtime, and (for fully managed serverless) even much of the network is the provider's. But the code is yours, dependencies are yours, the function's IAM permissions are yours, and the event sources you wire up (S3 buckets, API Gateways, queues) are yours.

The catch: you can't run an EDR agent on Lambda. CWPP coverage of serverless workloads relies almost entirely on provider-side telemetry (CloudTrail, function logs, X-Ray) — there's no syscall stream to monitor. This shifts more of the practical detection burden onto the provider's logging without explicitly shifting the contractual responsibility.

By provider: AWS, Azure, GCP differences

The shape is the same; the framings, language, and edge cases vary. Quick tour:

AWS — the cleanest documented model

AWS coined the phrase "security of the cloud" vs. "security in the cloud" and runs with it. They publish a per-service responsibility breakdown — for each AWS service (EC2, RDS, S3, Lambda, etc.) they describe what they handle and what you handle. The documentation is good; the AWS Well-Architected Security Pillar codifies the customer side.

Notable AWS quirks:

• S3 bucket configurations have moved toward "secure by default" — public-block-by-default in 2023, Block Public Access at account level enforceable. AWS responsibility, not yours, for ensuring the FEATURE exists; yours for using it.
• IAM is fully customer-side. AWS provides Access Analyzer as help, but every IAM finding is yours to fix.
• CloudTrail logging is on for management events by default; data events still require explicit configuration.

Microsoft Azure — service-tier framing

Microsoft published their model as a tiered diagram showing how responsibility shifts between on-prem, IaaS, PaaS, and SaaS. Same core shape as AWS. Microsoft's published document is clear; the Microsoft 365 service-side responsibility carve-outs are particularly explicit about what's yours (e.g., "you are responsible for the security of your data in our SaaS").

Notable Azure quirks:

• Entra ID (formerly Azure AD) is a critical shared-responsibility surface — it's a Microsoft-managed identity service but YOU configure conditional access, MFA, privileged role assignments, and OAuth app permissions.
• Defender for Cloud and Sentinel are first-party offerings; "they're built in" doesn't mean "they're on" — you still must enable.
• Microsoft has a stronger contractual SaaS responsibility position than other providers — Microsoft 365's data residency, key management (Customer Lockbox), and audit guarantees are particularly explicit.

Google Cloud — "shared fate"

Google explicitly extends the standard model with the shared fate framing: rather than just publishing what you have to do, Google takes more responsibility for helping you do it well. Examples include Assured Workloads (regulatory compliance with provider-supplied controls), opinionated organization-policy defaults, and the Risk Protection Program (insurance partnership).

Notable GCP quirks:

• BeyondCorp/zero-trust framing is built into the platform's default architecture more than AWS or Azure.
• VPC Service Controls offer a "service perimeter" concept that catches data exfiltration at a layer AWS and Azure don't have an equivalent for.
• Smaller market share means smaller research community — both threat research and detection-content tooling has less coverage of GCP than AWS.

SaaS providers — wildly variable

"SaaS" is not one thing. A regulated-industry SaaS like Workday or Veeva publishes detailed responsibility documents. A tiny B2B SaaS may have nothing beyond a one-page security summary. The variability is itself a risk: when you adopt SaaS, the diligence question is "what does THIS vendor consider their responsibility," not "what does the SaaS model say."

Snowflake is an instructive case. It's SaaS — Snowflake patches the database, runs the infrastructure, manages the underlying clouds. But customers can disable MFA per-account. Snowflake's pre-2024 default was "MFA available but not required." That choice put MFA enforcement squarely on the customer's side of the line, and the UNC5537 campaign exploited it across hundreds of customer accounts. After the incidents, Snowflake changed the default to "MFA required for all human users" — moving more of the responsibility to their side.

What's ALWAYS yours, no matter the model

Across IaaS, PaaS, SaaS, every provider, every service tier — these stay on the customer's side of the line:

• Data classification. Provider can't tell you which data is sensitive.
• Access management. Who gets in, with what permissions, with what authentication strength.
• Account configuration. Public-vs-private, encryption-on-vs-off, logging-on-vs-off.
• Third-party integrations. Every OAuth grant, every connected app, every API key you issue.
• Use of features. The provider may offer MFA, encryption, logging, alerting — turning them on is yours.
• Compliance evidence collection. Provider gives you the raw data; you assemble it for your auditor.
• Incident response. Provider may detect and notify, but coordinating internal communications, customer notification, and regulatory disclosure is yours.

What's ALWAYS the provider's

• Physical security. The data centers, badge access, environmental controls, physical media destruction.
• Hypervisor isolation. Tenant-to-tenant isolation; cross-tenant escapes are the provider's problem.
• Hardware-level security. Server lifecycle, supply-chain integrity at the hardware level.
• Backbone network security. Provider-internal links, region-to-region encryption, BGP / DDoS protection at the perimeter.
• Managed service internals. The actual code running RDS, Snowflake, Cosmos DB, Cloud Run.
• Provider-side logging integrity. CloudTrail's tamper resistance is AWS's problem; whether you're storing those logs durably is yours.

Gotchas and edge cases

"Managed" can mean very different things

Two services with "managed" in the name can have vastly different responsibility splits. EKS (managed Kubernetes) means AWS manages the control plane; you still manage the worker nodes, the workload security, and the pod-level config. Aurora Serverless v2 means AWS manages essentially everything below the schema. Read the per-service documentation — assumptions don't transfer.

Default-on vs. default-off security features

Most providers ship features that are "available, not enabled." Encryption-at-rest, audit logging, MFA enforcement, access logging, anomaly detection — features exist but require configuration. The provider's responsibility is to provide the feature; yours is to use it.

The "we offer" trap

Provider documentation often phrases responsibilities as "we offer X" rather than "we do X." Microsoft offers Conditional Access. AWS offers IAM Access Analyzer. Google offers Security Command Center. None of those are doing anything until you turn them on, configure them, and respond to their findings. "Offered" features that are unconfigured are zero-value features.

Subprocessors

SaaS vendors use other SaaS vendors. Your CRM might be SOC 2 compliant; their email-delivery vendor's security is one layer further down the chain. Major incidents like the Capital One AWS engineer-turned-attacker case have implications for the entire stack — the data was Capital One's responsibility but the infrastructure-side attacker access was an AWS-side incident response question.

Third-party data — is it yours or theirs?

If your customer uploads data to your SaaS app running on your AWS account: in your contract with the customer, that data is yours to protect. In AWS's contract with you, it's still your data — AWS doesn't see a difference between customer data and any other data in your S3 buckets. The chained responsibility is yours alone.

Region-specific data residency obligations

EU customers under GDPR have data-residency requirements. Provider responsibility ends at "we keep this region in this region;" YOU ensure your services are configured to use the right region, your replication is restricted, and your support tickets don't include EU customer PII as text in screenshots that get processed in non-EU support centers.

Storm-0558: a rare provider-side breach

Most cloud breaches are customer-side. Storm-0558 (2023) is one of the few high-profile exceptions: Microsoft's signing key for Outlook web access was compromised, allowing the attacker to forge tokens for victim accounts. Microsoft owned the failure. Even so, the customer-side investigation question — "did the attacker access OUR mailboxes" — was left to customers because Microsoft initially didn't have the logging customers needed. That experience caused Microsoft to change which audit-log fields are available without paid tiers. Read the full Storm-0558 kill chain.

The contractual layer (and why it matters)

The shared responsibility model is partly framework, partly contract. Both layers matter — and they're not always aligned.

• Cloud provider Master Service Agreements spell out the responsibility split in legally binding language. They describe service-level commitments, breach notification timelines, customer data handling, audit rights, and the limited liability provisions that come with all of it.
• Provider compliance attestations (SOC 2, ISO 27001, FedRAMP, PCI DSS) — these tell you what audited controls THE PROVIDER has in place. They don't audit your configurations.
• Your contracts with your customers may flow down obligations the cloud provider doesn't accept on your behalf. Your customer says you must encrypt their data with customer-managed keys; the cloud provider doesn't make that promise to you. Bridging the gap is on you.
• Regulator-specific responsibility transfers — for example, HIPAA Business Associate Agreements (BAAs) explicitly assign responsibility for handling PHI. Major cloud providers offer BAA-eligible services lists; using a non-BAA-eligible service for PHI is your problem.

Practical implication: when you're scoping a new service or vendor, the question is never just "is this secure?" — it's "who's responsible for what aspect of the security, who's accepting that responsibility contractually, and where do the gaps fall." Most cloud security maturity is just consistently asking that question.

"Shared fate" — the model's evolution

The original shared responsibility model has a fairness problem: it asks customers to operate enterprise-grade security on infrastructure they didn't design. A small company's IAM administrator is competing with the same threat actors as Capital One's; the model says "you're responsible for it" without addressing the asymmetry.

Google introduced the term shared fate in 2021 to extend the model. The framing: we're in this together. Google makes opinionated defaults (organization policies that prevent common misconfigurations), invests in customer-side tooling (Security Command Center as part of the platform, not a paid bolt-on for many features), and partners on insurance and incident response.

Microsoft and AWS have evolved similarly even without using the term — secure-by-default S3 settings, MFA enforcement defaults, Center for Internet Security benchmarks integrated into native posture tools. The trend is toward providers taking more practical responsibility while the contractual responsibility stays where it is.

Practitioner take: this is good. The math has always been that providers can build a control once and benefit thousands of customers; customers building the same control individually is wasteful and error-prone. Defaults that prevent the default failure modes are an order of magnitude more valuable than any documentation about who's responsible for what.

FAQ

Where does Kubernetes fit?

Managed Kubernetes (EKS, AKS, GKE) is roughly PaaS for the control plane and IaaS for the workers. Provider patches the API server; you patch the worker node images and operate the workloads. Pod-level security, Network Policies, RBAC, admission control — all yours.

Who's responsible if I get DDoSed?

Generally: the provider absorbs the network-layer DDoS (because it's hitting their pipes), and you handle the application-layer DDoS (because the requests are legitimate-looking traffic to your app). AWS Shield Standard, Azure DDoS Protection Basic, and Cloud Armor's standard tier handle the network layer; advanced application-layer protection is a paid add-on you'd typically buy if you're a high-value target.

What about data when I delete my account?

Providers commit to data destruction within a stated SLA. AWS does this within 90 days for almost all services. The customer responsibility is to verify deletion (where attestation is available) and to handle any backup or replication you set up — those persist independently of your account deletion.

If I use a managed service and there's a vulnerability in the underlying engine, who fixes it?

Provider, but the timing is theirs. Critical patches typically roll out without customer action; less-critical patches may be queued for the next maintenance window you control. The Microsoft Storm-0558 case was unusual in that the vulnerable code was in a managed service customers couldn't patch themselves.

Does the model differ for government / FedRAMP / regulated workloads?

The framework is the same. The difference is in what evidence the provider must produce — FedRAMP authorization compels providers to operate against specific NIST 800-53 controls in specific environments (AWS GovCloud, Azure Government, GCC High). Your customer-side responsibilities don't shrink; you just have more compliance documentation to maintain alongside them.