Moving a workload to the cloud does not hand all of its security to the cloud provider. The shared responsibility model sets out which security tasks the provider handles and which stay with the customer, and the split depends on the service model in use.
The three cloud service models are:
- Infrastructure as a service (IaaS): the provider supplies virtual machines (VMs), disks and networks; the customer manages the operating systems and applications on them. Azure Virtual Machines and virtual networks are examples.
- Platform as a service (PaaS): the customer deploys applications without managing VMs or operating systems. Azure App Service, Azure Functions and Azure SQL Database are examples.
- Software as a service (SaaS): the customer uses a ready-made application, such as Microsoft 365 or Dynamics 365.
In an on-premises datacentre (one the organisation runs itself) the customer owns the whole stack. Each step from IaaS to PaaS to SaaS moves more of the stack to Microsoft. Microsoft’s responsibility matrix looks like this:
| Responsibility area | On-premises | IaaS | PaaS | SaaS |
|---|---|---|---|---|
| Customer data | Customer | Customer | Customer | Customer |
| Configurations and settings | Customer | Customer | Customer | Customer |
| Identities and users | Customer | Customer | Customer | Customer |
| Client devices | Customer | Customer | Customer | Shared |
| Applications | Customer | Customer | Shared | Shared |
| Network controls | Customer | Customer | Shared | Microsoft |
| Operating system | Customer | Customer | Microsoft | Microsoft |
| Physical hosts | Customer | Microsoft | Microsoft | Microsoft |
| Physical network | Customer | Microsoft | Microsoft | Microsoft |
| Physical datacentre | Customer | Microsoft | Microsoft | Microsoft |
Three patterns in the table are worth memorising:
- Always the customer’s: whatever the service model, the customer keeps responsibility for its data, its endpoints (the laptops, phones and desktops that connect to cloud services; in SaaS the matrix marks client devices as shared only because Microsoft can supply some device management, while endpoint protection and compliance stay with the customer), its accounts and its access management (role-based access control, multifactor authentication and Conditional Access policies). Microsoft also lists configurations and settings as always the customer’s: a misconfigured storage account exposes data even on a perfectly secured platform.
- Moves to Microsoft at IaaS: physical hosts, the physical network and the physical datacentre, together with the hypervisor (the virtualisation layer that runs VMs).
- Moves to Microsoft at PaaS: the operating system. In IaaS the guest operating system on a VM is still the customer’s to patch and harden; in PaaS and SaaS Microsoft manages it.
Applications and network controls are shared in the middle of the range. In PaaS, for example, Microsoft provides baseline network security but the customer configures application-level network controls. Figure 1.1 shows the whole matrix.
Microsoft points out an advantage of the model: on-premises teams often leave responsibilities unmet (delayed patching, weak physical security, untested backups), and handing the lower layers to the provider frees people and budget for the layers the customer keeps.
The same idea extends to AI workloads. Microsoft’s training splits an AI-enabled application into the AI platform, the AI application and AI usage; whatever the service type, the customer stays responsible for the data it lets the AI system reach, who can use it, how it is configured, and risks such as prompt injection (instructions hidden in input that manipulate the AI’s behaviour).
Common trap: Choosing SaaS means Microsoft is responsible for the data and user accounts - wrong. Data, endpoints, accounts and access management stay with the customer under every service model; SaaS moves the infrastructure, operating system and network controls to Microsoft, and only shares applications and client devices.