What the shared responsibility model is
Every major cloud provider publishes a version of the same idea: the provider secures the cloud itself, and the customer secures what they put in the cloud. The provider owns the physical data centers, the hardware, the hypervisor and the core network. You own your data, your identities, your configurations and, depending on the service, your operating systems and applications. Misunderstanding where that line sits is the single most common root cause of cloud security incidents.
Why it matters
When a storage bucket is left publicly readable, the provider did nothing wrong. The encryption, the access controls and the logging were all available. The customer simply did not turn them on or configured them incorrectly. The shared responsibility model tells you, before anything is built, which controls are yours to configure and which you can inherit. It also drives contracts, audits and incident response: if something goes wrong, you need to know whose job it was.
How the line moves by service model
- Infrastructure as a Service (virtual machines, virtual networks): you patch the operating system, harden the host, manage firewalls and manage data. The provider handles the physical layer and the virtualization layer.
- Platform as a Service (managed databases, container platforms, serverless): the provider patches the runtime and operating system. You own identity, data, application code and configuration.
- Software as a Service (hosted email, CRM, collaboration tools): the provider runs almost everything. You still own user accounts, access policies, data classification and how the tool is integrated with other systems.
Step by step: mapping responsibility for a new workload
- List every cloud service the workload uses, from compute to DNS to logging.
- For each service, write down the service model (IaaS, PaaS or SaaS).
- For each one, answer: who patches it, who configures access, who encrypts data, who monitors it, who backs it up.
- Mark every item that lands on your side as a control you must implement and evidence.
- Review the list with whoever owns the budget so the staffing matches the responsibility.
Worked example
A small company moves its customer portal to a managed container service with a managed database and object storage. The provider patches the container nodes and the database engine. The company still owns the container images (vulnerable libraries inside them), the identity roles the containers run under, the network rules between the containers and the database, the database users, encryption settings, backup schedules and every log that proves all of this is working. Writing that down turns a vague sense of being secure into a checklist of ten concrete controls.
Common mistakes
- Assuming a managed service means a fully secured service.
- Forgetting that identity and data are always the customer’s responsibility, in every model.
- Not documenting the split, so nobody owns a control until an incident forces the question.
Action Step: Pick one workload you run today. Build the responsibility table described above and identify at least three controls that are yours but currently have no named owner.