Shared responsibility model

The model draws a line between what the provider is responsible for (the physical facilities, the hardware, the virtualisation layer, the managed services they operate) and what the customer is responsible for (their data, their identity and access configuration, their network settings, their application code, and how they use the services). The line moves with the service type. With raw infrastructure the customer owns almost everything above the hypervisor, including the operating system. With a managed platform or database the provider takes on more of the stack. With a fully managed application the customer’s job shrinks to access, data and configuration. The provider secures the cloud; the customer secures what they put in it.

The recurring failure is a boundary the customer assumed the provider owned. “It is managed” is read as “it is secured”, so identity policy is left loose, data is stored without the access controls the customer alone can set, and a cloud misconfiguration on the customer’s side of the line goes unaddressed because someone believed it was the provider’s problem. From an attacker’s perspective, this gap is reliable: the provider’s half is generally well run, and the exploitable weaknesses live almost entirely in the customer’s configuration, which is exactly the half the model makes the customer’s responsibility.

The model sets the scope. Before testing, we agree which layers are the customer’s to secure and therefore in scope, and which belong to the provider and are out of scope, so the rules of engagement reflect reality and the report does not raise findings against a layer the customer cannot change. It also frames compliance work, since an auditor asks the customer to evidence controls on their side of the line. Getting this boundary right is the difference between a targeted assessment and one that wastes effort on the provider’s estate. This is part of how we scope a cloud assessment.