Terms / Scope and assets
Shared responsibility matrix
A cloud provider's description of which parts of security it owns and which you own. Read it as the starting point, not as your evidence.
Also called SRM, shared responsibility model, shared responsibility matrices.
Practitioner Guidance
What it means in practice
A shared responsibility matrix describes the division of labour in a cloud service.
The provider secures the platform: the facilities, the hardware, the hypervisor, and the services it operates. You secure what you put on it: your data, your accounts, your configuration, and who may reach it. Every major cloud provider publishes one. Read it before you assume a service solves a requirement.
The name is close to the customer responsibility matrix, and the two do different jobs.
A shared responsibility matrix is a general model for a platform. A customer responsibility matrix maps specific security requirements to specific owners for the service you bought. The rule asks for the second one. The first is useful background and it is not what your assessment works from.
The boundary in the model is where most misconfiguration lives.
Providers secure their side reliably. The failures that reach the news sit on the customer side of the line. A storage location is left open. An account has no multifactor authentication. A permission is granted widely and never reviewed. Read the model to find your side, then check it.
Your side of the line grows as the service gets simpler to operate.
With a bare virtual machine you own the operating system, the patching, and the configuration. With a fully managed application you own accounts, data handling, and settings. Neither extreme removes your responsibility. Know where your service sits so you can tell which requirements land on you.
What falls short
- A requirement marked as handled by the platform because the provider is large. The model says which side the requirement sits on, and the answer is often yours.
- A review of the model with no check of the actual configuration. The model describes duties, and the settings are the evidence.
- Treating the model as the document the rule asks for. Section 170.19(c)(2)(ii) asks for a customer responsibility matrix from your external service provider.
Edge cases
- You use a service built on another provider's platform. Two models apply, and your evidence still has to reach the control.
- The provider revises the model after a change to the service. Re-read your side, because a duty may have moved onto it.
- Your provider offers a version of a service for Government work alongside a commercial one. The models differ, so read the one for the version you bought.
Over-engineering
- A control you build to cover a duty the provider already owns. Check the model, then spend the money elsewhere.
- Rewriting the provider's model into your own words. Cite it, map it to your requirements, and keep the original.