The Shared Responsibility Model: Knowing Which Half Is Yours

"We're on AWS, so we're secure" is the dangerous half-truth

Moving to the cloud quietly rewired how security works, and a lot of teams never updated their mental model. The comforting story goes: a hyperscaler runs world-class data centers, employs armies of security engineers, and holds every certification under the sun — so by being on their platform, you inherit all of that. Half of that is true, and the half that isn't is where the breaches happen.

Cloud providers operate on a shared responsibility model: they secure the infrastructure of the cloud, and you secure what you put in it. The provider guarantees the physical data center, the hypervisor, the network backbone, the managed-service plumbing. Everything you configure on top — your data, your access controls, your network rules, your application — is yours. The provider's compliance certifications cover their layer; they say nothing about whether your layer is configured safely. Almost every cloud breach lives in this seam, where each side assumed the other had it covered.

The line moves depending on what you rent

There isn't one fixed boundary — it shifts with the kind of service you consume, and confusion about where the line sits for a given service is itself a source of risk:

Infrastructure (IaaS). You rent raw compute and storage. The provider secures the hardware and hypervisor; you own the guest OS, patching, network configuration, and everything above. This is the most responsibility you'll carry.
Platform (PaaS). You rent a managed runtime or database. The provider also handles the OS and the service's own patching; you still own your data, your access policy, and how you configure the service.
Software (SaaS). You rent a finished application. The provider runs almost everything — but you still own your data, who can access it, and how you configure the tenant. The single most common SaaS failure is assuming "they handle security" and never touching the access settings.

The constant across all three: your data and your access controls are always yours. No tier of cloud ever takes responsibility for who you let in or how you configure what you rent. That's why a cloud misconfiguration — a public storage bucket, an over-permissive security group — is a breach that needs no exploit. The provider's infrastructure worked perfectly; your half of the model is where the door was left open.

Your half, concretely

Once the line is clear, your responsibilities stop being abstract and become a checklist you already recognize from the rest of your program:

Identity and access. Who can reach what, enforced with MFA and least privilege. The provider authenticates that a request is valid; only you decide whether it should be allowed.
Configuration. Network rules, encryption settings, public-exposure flags — the CSPM territory where a single wrong toggle becomes an incident.
Data. Classification, encryption choices you control, retention, and backups. The provider's durability guarantee is not a backup strategy — it won't save you from a fat-fingered delete or ransomware.
The non-human identities you mint. Every service account and API key you create in the cloud console is squarely your half to scope, rotate, and own.
Monitoring. The provider gives you the logs; turning them into detection is your job. A log nobody reads is not a control.

Map the boundary, then prove you own your side

The practical move is to write the line down for each provider you use — what they own, what you own — so a responsibility never falls in the gap because both sides assumed the other had it. That mapping is also a compliance artifact: an auditor will ask which controls are inherited from the provider and which you operate yourself, and the provider's own attestation (their SOC 2 or ISO report) is evidence for their layer only. You still have to demonstrate your half.

This isn't a one-time diagram. Cloud environments drift — a new service gets adopted, a config changes, a bucket goes public — so "is our half of the shared responsibility model actually configured and monitored?" is a continuously verified dimension of your posture, not a slide from the migration project. A drifted configuration on your side of the line is a finding like any other, ranked by exposure.

One honest caveat: a platform can help you map the boundary, track whether your half — access, configuration, data, monitoring — is in good shape, and keep that evidence current for an auditor; it organizes, tracks, and proves the work on your side of the line. It does not secure the provider's infrastructure, configure your cloud for you, make you compliant, or grant or guarantee any certification; inheriting the provider's attestation covers only their layer, the configuration of your half is an operational step your team owns, and which obligations apply to you is a question for counsel.

The cloud secures the cloud; you secure what you put in it — and the breaches live in the seam where each side assumed the other had it. Draw the line for every provider you use, claim your half out loud, and verify you're actually holding it. The provider's certifications protect their layer, never yours.

The Shared Responsibility Model: Knowing Which Half Is Yours

"We're on AWS, so we're secure" is the dangerous half-truth

The line moves depending on what you rent

Your half, concretely

Map the boundary, then prove you own your side

See Hosting Security in action

Related articles

Passkeys and Passwordless Authentication: Killing the Password Without Betting the Company on One

Quantum-Safe Cryptography: Why a Lean Team Should Start Planning the Migration Now, Not Later

Endpoint Security: Hardening the Laptops Your Perimeter Now Lives On

Related articles

Security Posture
Passkeys and Passwordless Authentication: Killing the Password Without Betting the Company on One
Passwords are the root cause behind most breaches a small business will ever suffer, and passkeys are the first replacement that is both more secure and easier to use. But swapping the front door of every account is the kind of change that either quietly hardens your whole company or locks half of it out on a Monday morning. A plain-language walk through what a passkey actually is, why it cannot be phished, the synced-versus-hardware choice that shapes your rollout, the recovery problem that is harder than the login problem, and how to move a lean team off passwords without stranding anyone.

Security Posture
Quantum-Safe Cryptography: Why a Lean Team Should Start Planning the Migration Now, Not Later
A cryptographically relevant quantum computer does not exist yet — but "harvest now, decrypt later" means the clock on your long-lived secrets is already running, and the standards to fix it landed in 2024. This is a plain-English planning guide to the post-quantum transition: what actually breaks, what NIST finalized, why crypto-agility matters more than any single algorithm, and how a small team turns a decade-long migration into tracked work it can start this quarter.

Security Posture
Endpoint Security: Hardening the Laptops Your Perimeter Now Lives On
The office network died and the laptop became the perimeter. For a lean team, endpoint hardening — disk encryption, EDR, screen locks, and a way to wipe a lost machine — is the highest-leverage control you can actually finish. A practical baseline, and how to prove it.