The Shared Responsibility Model, Explained (So You Know What’s Actually Yours)

The Basics

Cloud providers keep the infrastructure running. You decide how you use it.

• AWS - “security of the cloud” is on them, “security in the cloud” is on you.
• Azure - responsibility shifts depending on whether you use IaaS, PaaS, or SaaS.
• Oracle - their infra is covered, but data, apps, and identities are yours.

(btw, those scenarios apply to most cloud providers, not specific to the ones in the example).

What Shifts With Service Type

The shared responsibility line moves depending on whether you’re using IaaS, PaaS, or SaaS.

• With IaaS, you manage the operating system, apps, and data.
• With PaaS, the provider handles the OS and runtime, while you focus on code and data.
• With SaaS, almost everything is handled for you, but you still own identity and how users access the service.

The higher you go up the stack, the less you manage directly - but you never hand off everything.

Whose Job Is It Anyway?

Think of this as the cloud’s version of “not it!”. The provider keeps the hardware alive, but you decide who gets access, what runs on it, and how it’s protected.

The tricky part is, sometimes the line isn’t obvious. With IaaS you’re patching the OS, with PaaS you’re patching just the app, and with SaaS you’re mostly patching your users’ bad habits. The rules change depending on what you buy into.

At the end of the day, the provider is responsible for keeping the infrastructure secure and reliable, while you remain accountable for how your data, applications, and access are managed. Clear boundaries prevent confusion and make it easier to respond when issues arise.

Why It Exists

Providers control data centers, hardware, and the global backbone. But they can’t control your passwords, your app code, or whether you misconfigure access (outages are rare, human mistakes are not 🙃). That’s why there’s a clear split between what they cover and what you must manage.

Common Missteps

This is where customers usually trip up:

• Leaving databases or buckets exposed.
• Using weak or shared admin accounts.
• Forgetting to patch applications.
• Assuming “the cloud” automatically equals “secure.”

Why It Matters

This model isn’t paperwork, it shapes how you actually build and run apps.

• On AWS, you need to enable encryption and set IAM correctly.
• On Azure, you’re the one who decides firewall rules and access policies.
• On Oracle, user roles and database access are fully yours to manage.

The takeaway: the platform is secure, but the way you use it decides the outcome.

The TAM Lens

Security in the cloud works best when responsibilities are clearly understood. The provider ensures the platform and infrastructure are reliable, while you need to focus on proper configuration, access control, and protecting the data that lives on top of it. Building with this mindset makes cloud environments far more predictable and resilient.

Staying Ahead

Some of these tiny steps can go a long way:

• Tag ownership - know who owns what.
• Enable alerts - catch problems before they escalate.
• Patch often - hardware is theirs, apps are yours.
• Encrypt everything - databases, storage, backups.
• Tighten IAM - always go least privilege.
• Review configs - misconfigurations cause more breaches than outages.

Final Thoughts

The shared responsibility model is basically where the handoff happens. The provider makes sure the platform is running, but you’re still the one in charge of who gets in and what happens inside. Knowing where that line is makes the difference between a setup that feels predictable and secure, and one that ends in finger-pointing later.