The Shared Responsibility Model – Who is Responsible for What in the Cloud?
Moving to the cloud does not mean handing all responsibility to Microsoft. Understanding exactly where their responsibility ends and yours begins could be the difference between a secure system and a serious breach.
- What the Shared Responsibility Model is and why it exists in cloud computing
- Which responsibilities always belong to the cloud provider, regardless of service model
- Which responsibilities always remain with the customer, regardless of service model
- How responsibility shifts depending on whether you use IaaS, PaaS, or SaaS
What is The Shared Responsibility Model?
The Shared Responsibility Model is a framework that defines who is responsible for which aspects of security and operations when you use cloud services. It exists because when you move workloads to the cloud, you are no longer managing everything yourself — but you also do not hand over all responsibility to the provider.
Instead, responsibility is divided. The cloud provider — Microsoft in the case of Azure — is always responsible for the security of the physical infrastructure: the data centers, the hardware, the networking equipment, and the virtualisation layer. The customer — you or your organisation — is always responsible for the data you put in the cloud, the accounts you manage, and the access you grant.
Everything in between — the operating system, middleware, applications, and network configuration — shifts between provider and customer responsibility depending on which service model you are using.
Why Does This Matter?
This model is directly tested in AZ-900 and is one of the most practically important concepts in cloud security. Misunderstanding it leads to dangerous assumptions — organisations sometimes believe that because they are using a managed cloud service, Microsoft handles all security. That is never fully true. There are always customer responsibilities, and knowing exactly what they are is essential for anyone working in cloud operations, security, or architecture.
The Real-World Story
Think about renting a flat versus owning a house.
When you own a house, everything is your responsibility. The foundation, the roof, the plumbing, the wiring, the locks on the doors, and the furniture inside — all of it is yours to maintain and secure. If the roof leaks or a window breaks, that is your problem to fix.
When you rent a flat, the building owner is responsible for the structure of the building — walls, roof, plumbing, electrical wiring in the walls, and the main entrance security. You are responsible for what you put inside the flat — your furniture, your belongings, locking your front door when you leave, and not giving your key to strangers.
If someone breaks in because the main building door lock was broken, that is the building owner's failure. If someone breaks in because you left your front door unlocked, that is your failure. Both parties have responsibilities and neither can blame the other for their own area.
Cloud computing works exactly the same way. Microsoft secures the building — the physical data centers, hardware, and infrastructure. You secure your flat — your data, your accounts, and your access controls. The Shared Responsibility Model is simply the formal agreement of who owns which part of that security.
Going Deeper
Microsoft Azure is always responsible for securing the physical infrastructure layer. This includes the physical security of data centers — access controls, surveillance, and environmental protection. It includes the hardware: the servers, storage systems, and networking equipment. It includes the virtualisation layer that separates one customer's workloads from another's. It includes the global network infrastructure that connects Azure regions. Customers have no access to these layers and no ability to affect them — they are entirely Microsoft's domain.
Customers are always responsible for certain things regardless of which service model they use. Data is always the customer's responsibility — you decide what goes in, how it is classified, and how it is protected. Identity and access management is always the customer's responsibility — you control which users and applications have access to your cloud resources and what level of access they have. End-user devices and on-premises components, if applicable, are always the customer's responsibility.
The area in between shifts depending on the service model. In IaaS, the customer takes on responsibility for the operating system, applications, middleware, network configuration, and data. The provider handles physical infrastructure and virtualisation. In PaaS, the provider takes on the operating system and platform layer in addition to the infrastructure. The customer handles the application and data. In SaaS, the provider manages almost everything including the application itself. The customer retains responsibility only for data, user accounts, and access configurations.
The practical implication is important: moving to a higher-level service model like SaaS or PaaS does not reduce your data responsibility. Your data is always your responsibility. If you put sensitive customer data into a SaaS application, you are still accountable for ensuring appropriate access controls, data classification, and compliance — even though Microsoft manages the application itself.
- The Shared Responsibility Model defines which security and operational responsibilities belong to the cloud provider and which belong to the customer.
- Microsoft Azure is always responsible for the physical infrastructure — data centers, hardware, networking, and the virtualisation layer.
- The customer is always responsible for their data, user identities, access management, and end-user devices, regardless of which service model is used.
- Responsibility for the OS, middleware, and application layers shifts depending on service model — more customer responsibility in IaaS, less in PaaS, least in SaaS.
- Using a managed service does not eliminate your security obligations — data responsibility never transfers to the cloud provider, whatever service model you use.
