Shared Responsibility in IaaS, PaaS and SaaS – The Complete Breakdown
The Shared Responsibility Model does not work the same way for every Azure service. Your obligations look very different depending on whether you are running a virtual machine or using a SaaS application.
- Exactly which responsibilities sit with the customer in IaaS and why there are so many
- How PaaS reduces customer responsibility compared to IaaS and what remains
- What a customer is actually responsible for when using a SaaS product
- How to use this knowledge to make more informed decisions about which Azure service to use
What is Shared Responsibility in IaaS, PaaS and SaaS?
The Shared Responsibility Model gives different results depending on the cloud service model you choose. This is not just a theoretical point — it has direct practical implications for your team's workload, your security posture, and your compliance obligations.
Think of it as a sliding scale. The further you move from IaaS toward SaaS, the more responsibility slides from your side to Microsoft's. But it never reaches zero on your side — there are always things that remain your responsibility regardless of what service you use.
Why Does This Matter?
This is the level of detail where AZ-900 exam questions get specific. Understanding the responsibility breakdown not just at the model level but at the service model level lets you answer nuanced scenario questions confidently. It also directly informs real decisions — if your team has limited security expertise, choosing PaaS over IaaS removes a significant set of responsibilities you would otherwise need to manage.
The Real-World Story
Preethi is the IT manager at a growing HR software company. Over the course of a year, she moves different parts of their infrastructure to Azure using different service models — and each move changes her team's job description in a different way.
When they first moved their legacy payroll system to Azure Virtual Machines — IaaS — her team found themselves busier than before in some ways. Yes, they no longer had a server room to maintain. But now they were responsible for patching Windows Server every month, managing antivirus on the virtual machines, configuring the firewall rules inside the OS, and monitoring application logs themselves. The cloud moved the physical work away but kept all the software management work exactly where it was.
When they moved their new expense management application to Azure App Service — PaaS — her team's work changed noticeably. The OS patching disappeared from their schedule. The runtime environment was managed automatically. They focused entirely on deploying their application code, managing their database, and handling their user accounts. The server-level work was simply gone.
When they switched to a third-party HR SaaS platform for employee onboarding, her team's technical responsibilities shrank to almost nothing for that specific function. They configured user accounts, set access permissions, uploaded their company policies, and that was essentially it. Microsoft and the SaaS vendor handled everything else.
Same IT manager, same organisation, three service models, three completely different sets of daily responsibilities.
Going Deeper
In IaaS, the customer carries the heaviest responsibility load. Microsoft manages the physical infrastructure and the virtualisation layer. The customer manages: the guest operating system including all patches and updates, any middleware or runtime environments installed on the OS, all application software and its configuration, network security within the virtual machine including firewall rules and network interfaces, and all data stored within the environment. This is the closest cloud model to running your own on-premises server — just without the physical hardware to maintain.
In PaaS, Microsoft takes on the operating system and the platform layer in addition to the physical infrastructure. The customer's responsibilities reduce to: the application code and its logic, application-level security including input validation and authentication handling, the data stored in the platform's managed services, and identity and access management for who can access the platform and deploy code. The customer no longer worries about OS vulnerabilities, runtime version management, or patching the platform itself.
In SaaS, Microsoft or the SaaS provider manages the entire stack including the application. The customer's remaining responsibilities are: data governance — deciding what data enters the system, how it is classified, and how long it is retained. User identity management — creating accounts, assigning appropriate roles and permissions, and removing access when people leave. Device security for the endpoints used to access the SaaS application. These are not trivial responsibilities, but they are significantly lighter than the IaaS or PaaS equivalent.
The consistent theme across all three models is that data and identity are always the customer's responsibility. No matter how managed the service is, Microsoft does not make decisions about your data or manage your users for you.
- In IaaS, customers manage the OS, middleware, applications, network configuration inside the VM, and all data — the heaviest responsibility load of any service model.
- In PaaS, Microsoft takes over OS management and platform maintenance, leaving the customer responsible only for application code, data, and identity management.
- In SaaS, customer responsibility reduces to data governance, user identity management, and end-device security — the lightest technical responsibility of any service model.
- Data and identity management are the two responsibilities that never transfer to the cloud provider regardless of service model.
- Choosing a higher-level service model like PaaS or SaaS is a legitimate strategy for reducing security and operational burden when your team has limited capacity.
