Home / Knowledge hub / Shared responsibility model
Knowledge hub
Shared responsibility model
The split between what your cloud provider secures and what you must secure yourself.
What it means
The shared responsibility model is the cloud providers' statement of who secures what. The provider secures the underlying platform: data centres, hardware, and the core services. You secure what you put on it: your data, settings, access rules and the code you run.
AWS describes this as security of the cloud versus security in the cloud. How the line falls depends on the service. With a virtual machine you manage the operating system. With a managed database the provider manages more. With serverless, more still, but never everything.
Why it matters
Most cloud incidents involve the customer's side of the line: open storage, broad roles, unpatched software, weak passwords. A provider's certificate does not mean your application is secure, and teams that assume otherwise leave their own half of the work untended for years.
It matters in contracts and audits too. Customers and regulators will ask what you control. Knowing the line helps you answer, and it focuses effort on configuration and access, which are yours. A clear map of the line also stops two teams each assuming the other one handles a task.
How it shows up
You meet it when choosing a service model, reading a provider's compliance reports, and answering a customer questionnaire. The repeated mistake is treating the provider's certificate as covering your own application. Another is not knowing who patches what on each service.
For each service you use, write down what the provider handles and what you do: patching, network rules, identity, encryption keys, backups, logging, and your code. Review the list when you adopt something new. The provider's documentation spells out the split for its services.
Questions people ask
Shared responsibility model, answered
Who is responsible if my cloud data leaks?
Usually you, if the cause is your configuration, access rules or application code. The provider is responsible for the security of its own platform and hardware. Read the provider's model for each service you use, since the line moves.
Does a provider's SOC 2 or ISO 27001 cover my app?
No. Those reports cover the provider's own controls, not yours. They help you, since you inherit some assurance, but your application, data and settings still need their own controls and their own evidence of testing.
Does the split change for serverless or managed services?
Yes. The more managed the service, the more the provider handles, such as the operating system, the runtime and patching of both. You still own your data, your identities, your configuration and your code, and each of those can still go wrong.
What do customers mean when they ask about it?
They want to know which controls you run and which you rely on the provider for. A short, accurate table of the two answers most questionnaires and shows you understand your side.
Is there an official statement of the model?
Each major provider publishes its own. AWS, Microsoft Azure and Google Cloud all describe the division and how it varies by service. Use the one for each platform you run on.
Sources
Where this comes from
Related
Terms that sit next to this one
Cloud misconfiguration
A cloud setting left unsafe, such as open storage or an overly broad permission.
CSPM
Tools that keep checking your cloud settings against security good practice.
Security questionnaire
The list of questions a buyer's security team sends before they sign.
Identity and access management (IAM)
The tools and rules that manage who your people and services are and what they reach.
SOC 2
An audit report on how well a service provider protects customer data.
Which half of the line is yours?
Your side of the line includes the application and its settings, which is where we test. We report what we proved on your app and can run privately inside your network. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.