Under the shared responsibility model, the cloud provider secures the infrastructure that runs its services, and you secure what you build and store on it. How much falls to you depends on the service. On a virtual machine you patch the guest operating system. On a managed storage service you still own data and access.
Of the cloud and in the cloud
AWS describes it as security of the cloud versus security in the cloud. Security of the cloud means the hardware, software, networking and physical facilities that run the services. Security in the cloud means how you configure and use them.
The other major providers publish their own versions of the same idea. This post uses AWS's wording, since that is what I fetched, but the principle carries over.
It changes by service
AWS gives two contrasting examples:
- Amazon EC2 is an infrastructure service. You manage the guest operating system, including updates and patches, any software you install, and the security group firewall.
- Amazon S3 and DynamoDB are abstracted services. AWS runs the operating system and platform. You manage your data, encryption settings, classification and IAM permissions.
AWS summarises the pattern: the more abstracted the service, the less configuration work you do, but you always remain responsible for your data and access decisions.
Three kinds of control
AWS splits controls into three groups:
- Inherited controls come entirely from the provider, like physical and environmental protection.
- Shared controls involve both sides. The provider patches its infrastructure, you patch your guest OS and applications.
- Customer-specific controls are yours alone, such as how you zone data within your own environments.
Where teams go wrong
Assuming the provider handles patching on a VM. A VM image does not update itself unless you set that up. Missing patches on guest systems are your item.
Assuming default settings equal safe settings. The provider operates the platform, but whether a bucket is shared widely, a role is over-permissive or a database is open to the internet is your configuration.
Forgetting that managed does not mean unowned. Using a managed database moves the patching of the engine to the provider. It does not move who can log in or what is stored in it.
Mixing up compliance. A provider's audit reports cover their part. They do not make your workload compliant. You need your own evidence for your part.
A one page ownership table
For each service you use, write down:
- Who patches the runtime?
- Who configures network access?
- Who manages identities and permissions?
- Who encrypts and classifies the data?
- Where are logs, and who reads them?
Fill it in once per service type. It becomes a useful reference in audits and incident reviews.
Where Safeguard fits
Safeguard's asset discovery and compliance evidence automation are aimed at the customer side of this table, finding what you run and collecting evidence that your controls operate. The provider's side stays with the provider.
Quick check
Does using a managed service remove my responsibility for data?
No. AWS states that you always remain responsible for your data and access decisions, however abstracted the service is.
Is the split identical for every service?
No. AWS notes it varies by service, Region, how services fit into your environment, and applicable laws.
Sources
Last reviewed: 19 October 2026.
