The Shared Responsibility Model in Plain English

Think of it as a lease, not a purchase

When you rent an apartment, the landlord maintains the roof, the wiring and the front door of the building. You decide who gets a key to your unit, whether you lock it, and what you leave on the balcony. Nobody finds this confusing, and nobody blames the landlord when a flatmate loses a key.

Cloud security works the same way, and the arrangement has a name: the shared responsibility model. The provider secures the infrastructure that delivers the service. You secure what you put into it and who can reach it. Both halves are necessary, and neither party can cover for the other.

The reason this needs explaining at all is that the dividing line moves. It sits in one place for a virtual machine, somewhere else for a managed database, and somewhere else again for a software product you merely log into. Most real incidents happen because a team assumed the line was further along than it was.

The line moves with the service model

The single most useful mental model is a stack. At the bottom sit the building, the power, the racks and the physical network. At the top sit your data and the people who can see it. Between them are the hypervisor, the guest operating system, the runtime, the application and its configuration.

As you move from infrastructure toward software, the provider absorbs more of the middle. What never moves is the top of the stack. The service models themselves are described in IaaS, PaaS and SaaS compared, and the security division maps directly onto them.

Read the bottom two rows again. Identity and data are yours in every column, on every platform, under every service model. No purchasing decision transfers them.

The parts that never move

Always the provider

Physical access to facilities, the integrity of the hypervisor, patching of host systems, the security of the storage fabric, decommissioning of failed drives and the isolation between tenants. You cannot audit these yourself, which is why providers publish third-party attestations instead. What those attestations do and do not cover is the subject of cloud compliance basics.

Always you

Who holds credentials, what those credentials may do, how strongly they are protected, what data you place in the service, how it is classified, how long it is kept and who you share it with. Also yours: the decision to make something reachable from the internet.

Genuinely shared

Patching in a managed service is the clearest example. The provider supplies a patched engine version and a maintenance window; you choose when to apply it and you carry the risk if you defer for a year. Similarly, the provider offers encryption and logging features, and you decide whether to enable them.

Each provider words it slightly differently

The concept is universal, but the phrasing in the documentation is not, and the phrasing shapes how teams reason about it.

AWS uses a memorable formulation: it is responsible for security of the cloud, and the customer is responsible for security in the cloud. Its published model distinguishes infrastructure services, container services and abstracted services, with the customer burden shrinking across those categories.

Microsoft frames the division as a chart that shifts across on-premises, infrastructure, platform and software, and is explicit that information, devices, accounts and identities remain the customer's responsibility in every column. Microsoft's own wording is a useful antidote to the assumption that a managed service is a managed risk.

Google Cloud adds a second idea it calls shared fate: rather than simply drawing a line and pointing at your side of it, the provider supplies secure-by-default configurations, blueprints and guardrails to help you hold up your end. It is a philosophical difference more than a contractual one, but it does show up in product defaults.

Developer clouds publish shorter versions of the same idea. When a provider hands you a virtual machine and a firewall and nothing else, almost everything above the hypervisor is yours by definition, which is the reality behind the first-hour checklist in securing a new cloud server.

Five misreadings that cause real incidents

"The provider backs it up"

Durability is not backup. Replication across zones protects against hardware failure, not against a bad migration, a wrong command or ransomware that encrypts what your application can write. You need your own retained copies with a restore you have actually tested.

"Managed means patched everywhere"

A managed database patches the engine. It does not patch your application dependencies, rotate your credentials or restrict who may connect. The blast radius of a leaked connection string is unchanged by the service being managed.

"It is private because it is internal"

Default networking is more permissive than most people assume, and one misconfigured rule or one public storage setting is enough. Exposure is a configuration you own, which is why firewall and security group design deserves its own attention.

"Their certification covers our application"

An attestation covers the provider's controls for the services in its scope. Your application, your access model and your data handling are assessed separately. Inheriting controls is real and useful, but it is a head start rather than a finish line.

"The root credential is fine because only I use it"

Root and global administrator identities sit at the top of every hierarchy and are outside most guardrails. Protecting them with strong multi-factor authentication and using scoped roles for daily work is the cheapest security improvement available in any cloud account.

Common questions