Shared responsibility model

There is no single normative version of the model; each provider publishes its own matrix, AWS as "security of the cloud" versus "security in the cloud", Microsoft as a responsibility chart by service type, and Google under the label "shared fate", which stresses secure defaults and blueprints on the provider's side. The formal anchors lie elsewhere. The CSA Cloud Controls Matrix (version 4, 197 control objectives in 17 domains) comes with implementation guidance that assigns each control to the cloud service provider, the cloud service customer or both. ISO/IEC 27017:2015 gives cloud-specific implementation guidance written separately for provider and customer, and ISO/IEC 27001:2022 Annex A 5.23 (information security for use of cloud services) requires processes for acquiring, using, managing and exiting cloud services.

The split is set per service and per feature, not only per service model. In managed Kubernetes the provider runs the control plane (API server, etcd), while node OS patching may stay with the customer depending on the node mode, and workloads, RBAC and network policies always do. In a managed database the provider patches the engine inside maintenance windows, while the customer owns database accounts, network exposure, backup retention settings and key choice. Customer-managed encryption keys move key lifecycle and availability risk to the customer: disabling or deleting the key makes the data unrecoverable by design.

In audits the customer relies on the provider's controls through its SOC 2 Type II or ISAE 3402 reports. These reports list complementary user entity controls, which the customer must operate for the provider's controls to be effective, and they state whether subservice organisations are carved out or included. Unread complementary controls and carved-out subservice providers are a common blind spot in supplier reviews. US federal authorisations use an equivalent customer responsibility matrix.

Allocating tasks does not allocate accountability. Under GDPR the controller remains accountable (Art. 5(2) and Art. 24), while Art. 28(3)(c) obliges the processor to take the Art. 32 security measures; NIS2 Art. 21(2)(d) covers supply chain security; and for the financial sector DORA (Regulation (EU) 2022/2554) Arts. 28 to 30 set out ICT third-party risk management and mandatory contract terms. A known limitation is that the model divides duties but says little about provider-side compromises that customers cannot prevent, such as the 2023 theft of a Microsoft signing key in the Storm-0558 incident; customers still need detection, logging and exit plans for that residual risk.