What does Azure's shared responsibility model leave to your team?

Microsoft's shared responsibility model says that in every Azure deployment type you keep responsibility for your data, your identities and users, and your configurations and settings. Microsoft always owns the physical datacenter, hosts and network. Everything between depends on whether you use IaaS, PaaS or SaaS.

What does the matrix say?

Microsoft's table divides areas of the stack among on-premises, IaaS, PaaS and SaaS. Reading across it:

• Customer data, configurations and settings, identities and users: you, in IaaS, PaaS and SaaS.
• Client devices: you in IaaS and PaaS, shared in SaaS.
• Applications: you in IaaS, shared in PaaS and SaaS.
• Network controls: you in IaaS, shared in PaaS, Microsoft in SaaS.
• Operating system: you in IaaS, Microsoft in PaaS and SaaS.
• Physical hosts, physical network and datacenter: Microsoft in all three.

Microsoft's own examples: Azure Virtual Machines and Disk Storage are IaaS, App Service, Functions, SQL Database and Storage are PaaS, and Microsoft 365 is SaaS. Many solutions mix these models, so you apply the table per service, not per company.

The page adds a caution. It uses "responsibility" in a governance sense, as who is expected to configure, operate and monitor each control. It is illustrative guidance and does not change the terms of any agreement with Microsoft. Your contract is the legal source.

What do you always keep?

Microsoft lists four: data (classification, protection, encryption decisions and data governance compliance), endpoints, accounts, and access management, including role-based access control, multifactor authentication and conditional access.

For a software team this means a PaaS move does not remove work. It moves it. On a virtual machine you patch the operating system. On App Service Microsoft handles the operating system, but you still own the application code, its dependencies, its configuration, and who can deploy it.

Constructed example: a team moves an API from a virtual machine to a managed app platform and drops its patching job. Six months later a vulnerable library in the app is exploited. The platform was patched, but the library was the team's responsibility, and nobody owned the dependency update.

What about AI workloads?

Microsoft's page points to separate shared responsibility models for generative AI workloads and for autonomous, tool-using AI agents. We did not fetch those pages, so read them directly if you run such workloads. Do not assume the matrix above covers them.

How do you turn this into a checklist?

Make one row per Azure service you use, and fill four columns: service model, what Microsoft covers, what you cover, and the evidence you hold. The last column is what an auditor or a customer questionnaire will ask for. If the evidence column is empty, the responsibility is probably unowned.

What to do

1. List every Azure service in use and tag each as IaaS, PaaS or SaaS.
2. For each, write the controls you own using the table as a starting point.
3. Assign a named owner to data classification, identity and access, and configuration baselines.
4. Enforce multifactor authentication and role-based access for every account that can change production.
5. Put application dependencies in scope: inventory them, scan them, and decide who updates them.
6. Keep configuration under review, since Microsoft treats configurations and settings as yours in all models.
7. Read the AI responsibility pages if you deploy AI features.
8. Record where your contract differs from the guidance page.

Safeguard SBOM and dependency scanning, policy gates and compliance automation cover the application and evidence side of that list. They do not cover Microsoft's side of the model.

Quick check

Sources

• Shared responsibility in the cloud, Microsoft Learn, fetched 18 October 2026

Last reviewed: 18 October 2026.