The shared responsibility model

At the second cloud lunch, on September 15, Sunil Rao, the IT security manager, joins Theo and Renata with a question he has been asked by the company's auditors: "If our data is in Microsoft's data center, and something goes wrong, whose fault is it?" Renata says it is the right question to ask first, and that the answer has a name: the shared responsibility model. By the end of the hour the whiteboard holds a grid with four columns and nine rows, and Theo has a much clearer picture of what his job will look like after Skylight.

In a traditional server room, the organization is responsible for everything: the building, the power, the cooling, the network cables, the servers, the operating systems, the applications and the data. When a workload moves to the cloud, some of those responsibilities move to the provider. Which ones move depends on the kind of service. The shared responsibility model is simply the agreement about where the line falls.

The basic idea

Microsoft is always responsible for the physical layer: the data centers, the physical network, the physical hosts that run customers' workloads, and the people and processes that protect them. The customer is always responsible for its data, for the devices its people use to reach the cloud, and for the accounts and identities that can access its resources. Everything in between, such as operating systems, network controls, applications and identity infrastructure, is shared, and the share changes with the type of service.

The three main service types, which lesson 6 covers in depth, are infrastructure as a service (IaaS), platform as a service (PaaS) and software as a service (SaaS). With IaaS, Microsoft provides the physical hardware and the virtualization layer, and the customer manages almost everything above it, including the operating system. With PaaS, Microsoft also manages the operating system and the runtime, and the customer manages the application and its settings. With SaaS, Microsoft runs the whole application, and the customer manages how it is used: who has access, what data goes in, and how it is configured.

What always stays with the customer

Renata underlines three rows. However much of the stack Microsoft runs, the customer always owns its information and data, its devices and its accounts and identities. Microsoft cannot decide what data a company should store, who should be allowed to read it, or whether a sales clerk's tablet has a screen lock. If an employee's password is stolen and an attacker signs in with it, the cloud has worked exactly as designed; the failure is in the customer's identity controls.

Sunil nods. Most cloud security incidents he reads about are not failures of the provider's infrastructure. They are misconfigurations: storage left open to the internet, administrator accounts without multifactor authentication, old test machines that nobody patched. The shared responsibility model makes it clear that these are customer responsibilities, and lesson 12 covers the Azure tools that help customers meet them.

Who patches: the operating system question

Theo's own job turns on the operating system row. Today he applies Windows updates to every server once a month. If StockLine moves to Azure virtual machines, which are IaaS, he will still apply those updates; Microsoft patches the hosts underneath, but the operating system inside each virtual machine belongs to Harrow & Finch. Azure offers tools that make the job easier, such as automatic guest patching and Azure Update Manager, but turning them on and checking the results is the customer's task.

If the StockLine database moves instead to Azure SQL Database, a PaaS service, Microsoft patches the operating system and the database engine itself. Theo would no longer schedule database server updates at all. He would still be responsible for who can connect to the database, how it is backed up beyond the built-in options, and whether the application's queries are sensible. And if the HR system stays a SaaS product, the vendor patches everything; Theo's team only manages who has accounts and how they sign in.

The shared rows

Three rows in the table are marked "shared" for PaaS and SaaS: identity and directory infrastructure, applications and network controls. Shared does not mean vague; it means each party owns a different part of the same layer. For network controls in a PaaS service such as Azure SQL Database, Microsoft runs the network that carries the traffic and protects the service from large attacks, while the customer decides whether the database accepts connections from the internet, from specific addresses only, or only through a private endpoint inside its own network. Lesson 10 explains private endpoints.

For identity infrastructure, Microsoft runs Microsoft Entra ID, keeps it available and patches it. The customer decides which users exist, which groups they belong to, whether they must use multifactor authentication and which applications they can reach. For applications in PaaS, Microsoft provides and maintains the platform the application runs on, but the code, its dependencies and its configuration are the customer's. A web app on Azure App Service with a vulnerable library inside it is the customer's vulnerability, even though Microsoft patched the web server underneath.

The practical lesson is that "shared" rows need the most attention, because each side can assume the other has the problem covered. Renata asks the Skylight team to write down, for every shared row, exactly which settings belong to Harrow & Finch.

Who pays and who gets paged

The shared responsibility model is usually drawn for security, but Renata applies it to the other two questions on her whiteboard. Who pays is simpler in the cloud: the customer pays for what it uses, and Microsoft pays for the buildings, power, hardware refreshes and staff that make the service possible. That is part of what the customer is buying. Who gets paged depends on what failed. If an Azure data center loses power, Microsoft's engineers respond and the customer may never notice, provided its workloads were designed to survive the loss. If an application crashes because of a bad update, the customer's team gets the call.

This matters for staffing. Harrow & Finch will need fewer people who replace hardware and more people who understand configuration, monitoring and automation. Theo asks whether his job is at risk. Renata says no: the company needs people who know StockLine and the stores, and those people are much harder to find than people who can swap a disk.

Responsibility and compliance

The auditors' original question was about compliance. Organizations must meet laws and standards about how they protect information: state privacy laws, such as the consumer data protection laws several states have passed, and the Payment Card Industry Data Security Standard (PCI DSS) for card payments, which Harrow & Finch must meet in every store. Moving to Azure does not move these obligations to Microsoft. It does let the company rely on Microsoft's own audits for the parts Microsoft runs.

Microsoft publishes reports from independent auditors who examine its data centers and services against standards such as ISO/IEC 27001 and the SOC 2 reporting framework. Customers can download many of these through the Service Trust Portal, which MSAZ-102 covers. When Harrow & Finch's auditors ask how the physical servers are protected, the answer becomes Microsoft's audit report. When they ask who can read customer records, the answer is still Harrow & Finch's own controls.

Common misunderstandings

The shared responsibility model is simple to draw and easy to misread. Three misunderstandings come up in almost every organization's first year in the cloud. The first is assuming that because a service is "managed", it is configured securely by default. Many services are created with sensible defaults, but some settings, such as whether a storage account accepts connections from the internet, depend on choices the customer makes. The second is assuming that Microsoft backs up everything. Azure stores data durably, and lesson 11 explains how storage keeps several copies, but durability is not the same as a backup: if a user deletes a file or ransomware encrypts it, the copies faithfully reflect the change. Backups that let you go back in time are something the customer must set up, using services such as Azure Backup.

The third misunderstanding is thinking that SaaS removes all work. Harrow & Finch's Microsoft 365 tenant is SaaS, but Theo's team still decides who has licenses, whether external sharing is allowed, how long email is retained, and whether staff must use multifactor authentication. A SaaS provider runs the software; it does not run the customer's organization.

Using the model in practice

By the end of September, Renata has turned the whiteboard grid into a one-page table for each workload in Skylight. For every row, it names the person or team responsible on the Harrow & Finch side, or says "Microsoft". Theo finds the exercise useful in a way he did not expect: it exposes jobs that nobody owns today. The tape library, for example, is "Theo, on Fridays", but nobody has ever tested whether a restore from tape actually works. The Skylight table assigns that test to a named person every quarter.

The model also guides design choices. If the team wants to spend less effort on operating systems, it can choose PaaS services where they fit. If it needs full control, perhaps because a vendor's software only runs on a particular version of Windows, IaaS keeps that control, along with the responsibility that comes with it. There is no single right answer; the point is to choose knowingly.