Shared Responsibility Model

The shared responsibility model assigns security and operating duties between a cloud provider and its customer. AWS protects the infrastructure beneath its services; customer duties depend on the services selected. Microsoft presents a corresponding matrix across IaaS, PaaS, and SaaS.

Use the model as a service-by-service planning tool. A managed database and a virtual machine transfer different tasks, even when bought from the same provider. Identify the controls your team must configure, operate, and monitor in each case.

Duties that do not divide in two

Discussions treat this as a split. It is more accurately a three-way sort, and the middle category is where mistakes live.

• Transferred. The provider does it and you cannot. Physical datacenter security, the hypervisor, the physical network — in Microsoft’s matrix, physical hosts, physical network, and physical datacenter belong to the provider from IaaS upward.
• Shared. Parties maintain different layers of a control. In AWS’s patching example, the provider patches its infrastructure while customers patch the guest operating systems and applications they manage. A service that removes a customer-managed guest OS does not remove application maintenance.
• Retained. Customers remain responsible for their data, settings, identities, and access decisions. Microsoft also identifies customer duties for endpoints. Provider-managed mechanisms may implement parts of those controls, so specify both the intended policy and who operates each mechanism.

The retained list is short and it is the one to internalize, because it does not shrink as you move up the stack. A fully managed database still leaves you the data, its classification, who may reach it, and how they authenticate.

How the line moves between service types

AWS illustrates the boundary with EC2: customers maintain the guest operating system and installed applications and configure the instance firewall. Physical infrastructure remains the provider’s responsibility.

For S3 and DynamoDB, AWS also operates the operating system and platform. Customer work remains in data classification and protection, encryption choices, and access permissions. The platform removes maintenance tasks without choosing the right data policy for the organization.

Microsoft’s matrix generalizes it by row: the operating system is the customer’s through IaaS and the provider’s at PaaS and SaaS; network controls are the customer’s at IaaS, shared at PaaS, the provider’s at SaaS; and customer data, configurations and settings, and identities and users are the customer’s in every column, including on-premises.

The failure this model predicts

An open storage bucket, an over-permissive role, or an exposed customer credential can cause an incident within the customer’s retained duties even when provider infrastructure works as intended. Provider defects or infrastructure failures can also cause incidents and require investigation within the provider’s duties.

The mechanism is a reasonable inference drawn one step too far. A migration removes real work — patching, capacity, hardware failure — and the relief is genuine. The inference that security in general has moved is not, and it is easiest to make when nobody wrote down which rows changed.

For each service, record the transferred, shared, and retained duties in the design document. Assign access reviews, drift checks, and lifecycle duties for customer-managed keys and credentials. If rotation is automated by the provider, verify the configuration and monitor its operation. Least privilege guides the customer’s access decisions across service levels.

What the model is not

The responsibility matrix describes who configures, operates, and monitors controls. Microsoft explicitly treats it as governance guidance, rather than a change to contractual terms or a legal conclusion. Determine contractual and regulatory obligations from the applicable agreements and requirements.

And it says nothing about where data may physically sit, which is a separate constraint covered by data residency. A provider can be fully responsible for the infrastructure while running it in a jurisdiction your obligations do not permit.

How the boundary interacts with the choice between virtual machines, containers, and serverless is worked through in You Rented the Server, Not the Outcome.

References

• AWS, Shared Responsibility Model
• Microsoft Learn, Shared responsibility in the cloud