Shared Responsibility Model
The shared responsibility model is the division of security labor between a cloud provider and its customers: the provider secures the infrastructure — physical data centers, hypervisors, managed-service internals — while you secure what you build and configure on top: identities, access, data, application code, and configuration.
The one-line version per layer
The deeper the service manages your stack, the more the provider carries: on raw compute (EC2-style), you own the OS upward; on managed databases, you own configuration, access, and data; on serverless, you own code, identity, and data. At every layer, three things never leave your side of the ledger: your data, your identities, your configuration.
Why it shows up in audits
Auditors and security questionnaires probe the boundary directly: your provider’s SOC 2 covers their half, and reviewers want evidence you know where their half ends. “AWS is SOC 2 compliant” answers nothing about your open security groups. The classic breach headline — a public storage bucket — is almost always a customer-side configuration failure inside a perfectly compliant data center.
The practical takeaway
Inherit the provider’s report for their layer (that’s what it’s for), then evidence your own layer: IAM policies, encryption configuration, logging, access reviews. Our platform monitors exactly that customer-side surface — the half no provider report will ever cover for you.
Access Review — An access review is the periodic check that everyone's system access matches their role — the most-sampled SOC 2 control and the most common exception.
Sub-processor — A sub-processor is any third party your company uses to process customer personal data — your cloud host, email provider, analytics. You must disclose them.