One of the most dangerous sentences in cloud hosting is “the cloud is secure.” It is not wrong, exactly — cloud providers invest more in physical and infrastructure security than almost any individual customer could — but it is dangerously incomplete. The provider secures some layers of your stack. You secure the rest. The line between the two is called the shared responsibility model, and misunderstanding it is behind a remarkable share of cloud security incidents.
This guide lays out the model layer by layer: what the provider handles, what you handle, how the line moves between IaaS, PaaS, and SaaS, and the common misunderstandings that get people into trouble.
The Model in One Picture (Described in Words)
Imagine your application as a stack of layers, from the physical world up to your users:
┌─────────────────────────────────┐ │ 7. Your data & content │ ← always yours │ 6. Application code & config │ ← always yours │ 5. Runtime / middleware │ ← depends on service model │ 4. Operating system │ ← depends on service model │ 3. Virtualization (hypervisor) │ ← provider │ 2. Physical servers & network │ ← provider │ 1. Data center building │ ← provider └─────────────────────────────────┘
The bottom three layers — the building, the hardware, the virtualization — are always the provider’s. Nobody expects you to guard a data center door or patch a hypervisor. The top two — your data and your application — are always yours. The provider will not write secure code for you or decide who should access your database.
The middle layers — runtime and operating system — are where the line moves. Who patches the OS depends entirely on which service model you bought. That moving line is the whole game.
How the Line Moves: IaaS vs PaaS vs SaaS
| Layer | IaaS (virtual servers) | PaaS (managed platform) | SaaS (finished software) |
|---|---|---|---|
| Data center & hardware | Provider | Provider | Provider |
| Virtualization / network | Provider | Provider | Provider |
| Operating system | You | Provider | Provider |
| Runtime / middleware | You | Provider | Provider |
| Application code | You | You | Provider |
| Data & access control | You | You | You |
Read the table bottom-up for the uncomfortable part: in every model, your data and who can access it are your responsibility. Even in SaaS — where the provider runs everything else — misconfigured sharing settings, weak passwords, and over-permissioned users are still on you. There is no service model that outsources access control.
Concrete examples of the moving line:
- IaaS: You rent a virtual server. The provider keeps the data center secure and the hypervisor patched. You install the OS, patch it, configure the firewall, install your app, and secure it. Maximum control, maximum responsibility.
- PaaS: You deploy code to a managed platform. The provider patches the OS and runtime. You still secure your application code, manage secrets and environment variables, and control who can deploy.
- SaaS: You use finished software in a browser. The provider secures nearly the whole stack. You manage user accounts, permissions, sharing settings, and your data lifecycle.
What the Provider Handles: “Security OF the Cloud”
Providers call their side “security of the cloud” — protecting the infrastructure that runs the cloud itself:
- Physical security: guarded buildings, biometric access, camera coverage, hardware destruction procedures. This is genuinely world-class at major providers.
- Hardware and virtualization: server firmware, hypervisor patching, isolation between tenants on shared hardware.
- Network infrastructure: the provider’s backbone, DDoS absorption capacity at the network edge, and isolation between customers’ virtual networks.
- Managed-service internals: for PaaS/SaaS offerings, patching and hardening of the managed components themselves.
- Compliance of the infrastructure: certifications (like SOC 2 or ISO 27001) covering the provider’s facilities and processes — which you can inherit for audits, but which say nothing about your configuration.
This is the part providers are excellent at, and it is a genuine advantage of cloud over self-hosting. But notice what is absent: nothing here protects you from your own mistakes.
What You Handle: “Security IN the Cloud”
Your side is “security in the cloud” — everything you put on and around the provider’s infrastructure:
- Your data: classification, encryption (at rest and in transit), retention, and deletion. The provider gives you the tools; you decide how to use them.
- Identity and access: who can log in, with what credentials, and what they can touch. The single biggest source of cloud breaches is misconfigured access — overly broad permissions, leaked keys, public storage buckets.
- Application security: your code, your dependencies, your configuration. A SQL injection flaw in your app is yours no matter how secure the data center is.
- OS and runtime patching (IaaS): keeping the guest operating system and everything you installed on it updated.
- Network controls you configure: firewall rules, security groups, VPNs. The provider supplies the knobs; you turn them — and “allow all” is always one careless click away.
- Backups and recovery: the provider keeps its infrastructure durable, but point-in-time recovery of your data is your design decision.
If you have not already worked through the practical side, our cloud hosting security basics checklist turns this half of the model into concrete actions.
Five Misunderstandings That Cause Incidents
1. “The provider encrypts everything, so my data is safe.”
Providers encrypt storage infrastructure by default, which protects against someone stealing a physical disk. It does not protect against someone accessing your data through your application with stolen credentials, or through a misconfigured permission you set. Encryption at rest is the provider’s lock on the warehouse; access control is your lock on the door — you need both.
2. “The cloud backs itself up.”
Durability (the provider not losing your bits) is not backup (you being able to restore last Tuesday’s version after a bad deploy or a ransomware event). Replication across zones protects against hardware failure; it faithfully replicates your mistakes too. Versioned, tested, separate backups are your job.
3. “Default settings are secure settings.”
Sometimes; often not. Defaults optimize for “it works when you try it,” which historically meant permissive network rules and broad access. Every service you enable deserves a pass through its security settings before it touches real data.
4. “The provider’s certifications cover me.”
A provider’s SOC 2 or ISO certification covers the provider’s controls, not your configuration. Auditors know this: they will ask how you manage access, encryption, and logging on top of the certified platform. Inherited compliance is a head start, not a finish line.
5. “The provider absorbs DDoS attacks, so I don’t need protection.”
Providers do absorb enormous volumetric attacks at their network edge — that is genuinely their responsibility. But application-layer attacks that exhaust your server’s resources, and the bill for the traffic your auto-scaling spins up to absorb an attack, land on your side of the line. See our DDoS protection basics for where provider protection ends and yours begins.
Worked Example: Managed WordPress Hosting
The model gets concrete fast with a familiar product — managed WordPress hosting on cloud infrastructure:
- Provider: data centers, servers, network, the hypervisor, and — because it is managed — the server OS, PHP runtime, web server software, and often a WAF and automated backups of the server.
- You: WordPress core updates (unless the host auto-updates), every plugin and theme, your admin passwords and 2FA, user roles, the content and customer data in your database, and DNS.
Notice how much stays with you even in a “managed” product: the application layer is almost entirely yours. This is why managed hosting customers still get hacked — usually through an outdated plugin or a brute-forced admin login, both firmly on the customer’s side of the line. “Managed” moves the OS and runtime across the line; it does not move your application or your access controls.
The same exercise works for any service you buy. Take thirty seconds per product, draw the line, and write down what is yours. The services where customers get surprised are always the ones where they never explicitly drew it.
Applying the Model: Three Questions for Every Service
Whenever you adopt a new cloud service, ask these three questions before it touches production:
- Where exactly is the line for this service? Read the provider’s shared-responsibility documentation for that specific service — the line differs between a VM, a managed database, and a serverless function.
- What am I assuming the provider does that it doesn’t? List your assumptions explicitly: patching, backups, monitoring, DDoS handling. Verify each one.
- Who owns access control? The answer is always you — but “you” might mean three different teams. Name the owner, or nobody owns it.
The Bottom Line
The shared responsibility model is simple to state and easy to get wrong: the provider secures the cloud itself — buildings, hardware, virtualization, and the internals of managed services — while you secure everything you put in it: data, access, applications, and configuration. The line moves with the service model, but it never moves past your data and your access controls. Internalize that, verify your assumptions per service, and you will avoid the most common — and most embarrassing — category of cloud security incidents: the ones where the infrastructure was fine and the configuration was not.
One final habit worth building: revisit the line once a year, or whenever you adopt a new service. Providers add features, deprecate old ones, and occasionally shift where a responsibility sits — a managed service that once required you to patch its agents may automate it tomorrow, or vice versa. The model does not change, but the exact position of the line for any given product can drift. A yearly fifteen-minute review of “who secures what” across your stack is cheap insurance against the slow creep of wrong assumptions.
