Academmia

Shared Responsibility Model

az-900•mixed•

Cloud concepts

Shared Responsibility Model

Short Summary

The shared responsibility model explains how cloud responsibilities are split between Microsoft and you. Microsoft is responsible for security of the cloud (the Azure platform and infrastructure), while you are responsible for security in the cloud (how you configure and use what you deploy). This split changes depending on whether you use Infrastructure as a Service (IaaS), Platform as a Service (PaaS), or Software as a Service (SaaS).

Learning Objectives

By the end of this lesson, you will be able to:

  • Define the shared responsibility model in cloud computing.
  • Distinguish “security of the cloud” from “security in the cloud.”
  • Compare how responsibilities shift across IaaS, PaaS, and SaaS.
  • Identify responsibilities that remain yours in every service model.
  • Explain how reliability and backups fit into shared responsibility.

Core Concepts

What “shared responsibility” means

The shared responsibility model means the cloud provider and the customer each own different parts of the overall solution:

  • Microsoft is responsible for the parts you cannot control (for example, the datacenter facilities and the underlying platform).
  • You are responsible for the parts you can control (for example, identities, configuration choices, data, and access).

A simple mental model:

  • Security of the cloud: Microsoft secures the foundational Azure infrastructure and platform.
  • Security in the cloud: you secure what you deploy, configure, and allow users to do.

What is always your responsibility

No matter which cloud service model you use, you always retain responsibility for:

  • Data (what you store, how it’s classified, protected, and governed)
  • Endpoints (devices that access your cloud resources)
  • Accounts (how accounts/identities are managed)
  • Access management (who has access, what permissions they have, and how access is reviewed)

What changes across IaaS, PaaS, and SaaS

The overall trend is: as services become more managed, Microsoft takes on more platform responsibilities. However, the exact split still depends on the specific service you use.

  • Infrastructure as a Service (IaaS): you manage more of the stack (for example, the guest operating system, patching, and what runs inside your Virtual Machines (VMs)).
  • Platform as a Service (PaaS): Microsoft manages more platform components (for example, the underlying runtime/OS), but you still control and must secure configuration, identity, access, and data.
  • Software as a Service (SaaS): Microsoft runs the application, but you still control key items like data governance and who can access what.

Shared responsibility also applies to reliability

Reliability is shared too:

  • Microsoft is responsible for core platform reliability (the underlying platform, infrastructure, and processes).
  • Microsoft provides reliability-enhancing capabilities (for example, regions, availability zones, and backup options), but you are responsible for selecting and configuring what matches your workload’s needs.
  • You are responsible for application and workload design (how your solution behaves during failures and how it recovers).

Practical Understanding

Practical Situation 1: “We moved to Azure IaaS, so Microsoft handles all security now”

A team migrates servers to Azure as Virtual Machines (VMs). Someone assumes Microsoft now owns security tasks like protecting data, managing identities, and configuring the applications.

How to think about it: In IaaS, Microsoft secures the underlying physical infrastructure and core platform. You still secure what you run: the guest operating system, applications, network configuration you control, and your identities and data.

Common misunderstanding: “Cloud means the provider does everything.” In IaaS, you still own a large part of the stack.

Practical Situation 2: “We’re using PaaS, so we can ignore access controls and configuration”

A team deploys an app to a managed service (PaaS) and assumes security is fully handled because Microsoft runs the platform.

How to think about it: PaaS reduces platform maintenance, but you still control (and therefore must secure) identity, access, data protection, and service configuration. If you can configure it, you should assume you must secure it.

Common misunderstanding: “Microsoft secures Azure” means “Microsoft secures my app configuration.” Your configuration choices are still your responsibility.

Practical Situation 3: “We use SaaS, so our data and accounts are the provider’s responsibility”

A business uses a SaaS product and assumes everything about security is the provider’s job.

How to think about it: SaaS is highly managed, but you still own key responsibilities such as data governance, account management, and access decisions. You also own endpoint security (the devices that connect to the service).

Common misunderstanding: “SaaS transfers data responsibility.” Even in SaaS, your data and access decisions remain your responsibility.

Practical Situation 4: “Azure handles backups and disaster recovery automatically”

A team assumes that because Azure is reliable, they don’t need to configure backups or plan disaster recovery for their workload.

How to think about it: Azure provides reliability capabilities, but you still decide what to use and how to configure it: backup settings, retention, restore testing, and a workload-appropriate business continuity/disaster recovery plan.

Common misunderstanding: “Cloud reliability means I don’t need a plan.” The platform is resilient, but your workload still needs deliberate recovery decisions.

Common Pitfalls

  • Mistake: Assuming that moving to the cloud makes Microsoft responsible for all security and operations, including data, identities, and application configuration. Correction: Microsoft secures the cloud platform; you still secure and manage what you deploy, configure, and control.

  • Mistake: Treating the responsibility split as identical across IaaS, PaaS, and SaaS. Correction: Responsibilities generally shift toward Microsoft as services become more managed, but you must still understand the responsibilities for each specific service you use.

  • Mistake: Ignoring identity and configuration risks because “Microsoft secures Azure.” Correction: “Security of the cloud” does not replace “security in the cloud.” Your identity, permissions, and configuration choices remain yours.

  • Mistake: Treating data and access as “provider-owned” in PaaS or SaaS. Correction: You always retain responsibility for your data and access management, regardless of service model.

  • Mistake: Assuming reliability features are automatic and complete without your involvement. Correction: Microsoft provides reliability capabilities; you must choose, configure, and validate the ones your workload requires (including backups and recovery testing).

Check Your Understanding

  1. In your own words, explain the difference between “security of the cloud” and “security in the cloud.”
  2. Name the four responsibility areas that remain yours in all service models, and give one example for each.
  3. For IaaS, PaaS, and SaaS, describe one responsibility that typically shifts toward Microsoft as services become more managed.
  4. Pick one Azure workload (real or hypothetical). What backup and recovery decisions would you still need to make?
  5. Write a short “first 10 minutes” checklist for reviewing identity and access in a new cloud environment.

Further Reading