What Is Shared Responsibility Model?

The shared responsibility model is the most consequential concept in cloud security and the most frequently misread. Providers state it plainly, publish diagrams of it, and still the single most common cloud breach pattern is a customer assuming the provider covered something the provider never claimed to.

The pattern is consistent: the provider secures the platform, you secure what you build on it. Where the line falls shifts with the service model, and that shifting line is where the misunderstandings live.

The line moves with the service model

With infrastructure services you receive a virtual machine and almost everything above the hypervisor is yours — the guest operating system, its patching, the software on it, the network rules around it and every access decision. With platform services the provider takes the operating system and runtime, leaving you the application, its configuration and its data. With software services the provider runs nearly all of it, and your responsibility narrows to identity, access, data classification and how the service is configured.

What never transfers, at any service model, is identity and access management, data classification, and configuration. A provider cannot know which of your staff should reach which record, and no service model makes that their problem.

The section of the provider report nobody reads

Every provider attestation contains a list of complementary user entity controls — the things the customer must do for the provider's controls to be effective. It is written by the provider, in their own report, and it is effectively your homework.

It is also almost universally skipped. An assessor reading the provider's report will read that section and ask how you satisfy each item, and teams that have never opened it discover their obligations during an audit rather than before one. For most organisations it is the single most useful page in the entire document.

Responsibility inside your own organisation

The model describes the boundary between you and the provider. It says nothing about the boundary inside your organisation, and that is where a second, quieter gap forms.

Cloud configuration is usually made by the team that builds the service, while the security team is accountable for the outcome and frequently has read-only access. Neither is wrong, and the result is a set of decisions — which region, which encryption option, which identity role, whether logging is on — taken at speed by people whose objectives are delivery.

Naming who owns each of those decisions is more useful than any diagram of the provider boundary. In practice the durable answer is that the building team owns the configuration and the security team owns the guardrails that constrain it, expressed as policy rather than as review.

Where to start

Find the complementary user entity controls section of your main provider's report and check whether you satisfy each item. It is a short list, it was written for you, and it is the part of cloud responsibility most often discovered too late.

See cloud compliance in practice and preventing misconfiguration. GuardsArm runs cloud security assessments.