Cloud Security
Beginner 15 min read Cloud Security

The Shared Responsibility Model

The foundational cloud security concept: what the provider protects, what you protect, and how the line moves depending on the service type.

shared responsibilityIaaSPaaSSaaSabstractionprovider vs customer
Prerequisites: Security Principles Risk Management
Introduction

What is this?

The shared responsibility model is the contract that maps every cloud control to either the provider (the physical/data-center layer) or the customer (their data, config, and access).

Motivation

Why do you need it?

  • Most cloud incidents are 'customer side of the line' — a misconfigured bucket, key, or policy, not a provider failure.
  • Your compliance evidence depends on proving exactly which controls you own and which you inherit.
  • The line moves with the service: IaaS you patch, SaaS (mostly) you configure.
Think about it

Mental model

Imagine

Renting a building

Think of

La carte office rental

In a bare shell you own the plumbing; in a serviced office the landlord does — until your desk drawer is your responsibility.

Mechanics

How it works

  • At the top, the provider guarantees physical/edge security: datacenters, power, network, and the hypervisor.
  • The customer is always responsible for data, identities, and access controls — regardless of service type.
  • IaaS shifts OS/runtime patching to you; PaaS pushes the runtime to the vendor, still leaving app and access to you.
  • SaaS moves the most to the vendor, but you remain accountable for configuration, user access, and data lifecycle.

The responsibility line for each service model

Physical
Hypervisor
OS+Runtime
App+Data
Identity
Real world

In production

  • An org's incident playbook first asks 'which side of the line' — that single question scopes the whole response.
  • A compliance team maps every PCI requirement to provider-inherited vs customer-owned controls in a table auditors can read.
  • A startup buying serverless confirms the vendor patches the runtime, and their team still owns the app config and permissions.
Guidelines

Best practices

  • Write the line explicitly per service: which of 'patch, config, access, data' does the vendor do for you?
  • Keep the model in runbooks and interview answers — it is the first question of every cloud role.
  • Review the line on every new service type: serverless and SaaS shift the boundary silently.
  • Document inherited vs owned controls for your auditor before they ask.
Watch out

Common mistakes

  • Assuming 'cloud is secure' and skipping your own reviews because the provider has a million-page SOC report.
  • Keeping OS-level patching for a PaaS that already manages it — paying twice and owning a false control.
  • Handing off data protection to a SaaS vendor without reading their data-processing terms.
  • Mapping the model once at onboarding and never revisiting after a service migration.
When things break

Debugging tips

  • When a control is ambiguous, check the service's compliance whitepaper: most publish a responsibility matrix.
  • Ask 'what happens to my data at vendor exit?' — the answer reveals who owns the lifecycle.
  • Run a quarterly 'line review' table with one row per service.
Security

Security considerations

  • The line is a contract, not a slogan: read the DPA and shared-responsibility matrix for each provider.
  • Your data stays your data — the provider's obligations end where your configuration begins.
Interviews

Interview checkpoint

Test yourself

Quick quiz

0/2
1

In a SaaS model, which is usually STILL your responsibility?

2

Which area is the provider responsible for across ALL service models?

Go deeper

Official documentation

AWS Shared Responsibility Model
docs
Azure shared responsibility
docs