AI-assisted: written with an AI tool and checked against the AWS, Microsoft Azure and Google Cloud pages on shared responsibility. I run LearnSome.tech, which teaches cloud certifications; this exercise needs nothing from it.
Everyone can recite "the provider secures the cloud, you secure what's in it". The trouble starts when a real service lands on your bill and nobody can say who patches what. So here is the model as an exercise you can finish in an afternoon.
The one rule that never moves
Whatever the service, your data and your identities are yours. Classifying and protecting the data, deciding who has an account, enforcing MFA, removing leavers: no provider does those for you, in IaaS, PaaS or SaaS.
Everything else moves depending on the kind of service:
| Layer | IaaS (a VM) | PaaS (a managed platform) | SaaS (an application) |
|---|---|---|---|
| Your data | You | You | You |
| Accounts and access | You | You | You |
| Applications | You | Shared | Shared |
| Network controls | You | Shared | Provider |
| Operating system | You | Provider | Provider |
| Hosts, hypervisor, data centre | Provider | Provider | Provider |
That table follows Microsoft's breakdown; AWS and Google describe the same split in their own words.
The exercise
For each service on your bill, write four lines:
service: Amazon EC2 (orders web server)
patches the OS: us (the guest OS is ours on EC2)
network rules: us (security groups, VPC)
holds the keys: us (SSH keys, IAM roles)
leads an incident: us, with AWS for anything below the hypervisor
service: managed database (orders DB)
patches the OS: provider
network rules: shared (we decide what may connect; security groups again)
holds the keys: us (database users, encryption key choices)
leads an incident: depends: write down which cases are ours
service: email and documents suite (SaaS)
patches the OS: provider
network rules: provider
holds the keys: us (accounts, MFA, sharing settings)
leads an incident: us, for anything an account or a share setting caused
Any line you can't fill in from the provider's own documentation is a question for your team, not a gap to leave blank.
Three mistakes the map catches
- "Managed" read as "secured for you". Even in PaaS and SaaS, application configuration, code security and access controls stay with you.
- One split for everything. Your share changes per service. EC2 and a managed database sit on very different rows.
- Incidents left to the provider. Incident handling is often the least clearly divided area. Many incidents start with a misconfigured resource or stolen credentials, and both of those are on your side.
The map is also a good onboarding document: a new engineer reads it and knows which alerts are theirs.
What's the service where your team disagreed most about who owns what?
Top comments (0)