2.1.1. The Shared Responsibility Model
💡 First Principle: In any cloud service, security responsibility splits between the provider and the customer, and exactly where that split falls depends entirely on how much of the stack the provider manages for you — the more the provider manages, the more responsibility shifts to them, but the customer never reaches zero responsibility.
On-premises, you own the entire stack — physical building, hardware, OS, and data — so you own all the security. Move to Infrastructure as a Service (IaaS), like an Azure virtual machine, and the provider now handles the physical datacenter and the hypervisor, but you still patch the guest OS, configure the network security rules, and secure the data. Move further to Platform as a Service (PaaS), like Azure App Service, and the provider now manages the OS and runtime too — you're mostly responsible for your application code, configuration, and data. At Software as a Service (SaaS), like Microsoft 365, the provider runs almost everything — but identity, access control, and data classification decisions are still yours, in every single model, with no exceptions.
⚠️ Exam Trap: Moving to the cloud does not mean the cloud provider handles all security. Identity and access management, and the data itself, remain customer responsibilities across IaaS, PaaS, and SaaS without exception.
Reflection Question: If a company migrates a virtual machine from on-premises to Azure IaaS, which specific security tasks disappear from their to-do list, and which ones stay exactly where they were?
