Cloud Shared Responsibility Model Explained

Moving an application to the cloud does not hand all security work to the provider. Cloud providers secure the physical data centres, hardware and core services, but customers remain responsible for much of what they build and configure on top. The shared responsibility model is the name for this division of duties. Misunderstanding it can lead to serious problems: storage left open to the internet, overly broad access permissions, unpatched virtual machines and unencrypted backups, all of which sit on the customer's side of the line. This guide explains how the model works, how responsibilities shift with different types of service and how to turn it into a practical list of tasks with named owners.

What the shared responsibility model says

AWS describes the model as security "of" the cloud versus security "in" the cloud (AWS: Shared Responsibility Model). In its description:

• AWS is responsible for protecting the infrastructure that runs its services, including hardware, software, networking and facilities
• The customer's responsibility is determined by the services they select, which determines the amount of configuration work they must perform

Other major cloud providers describe similar divisions. The exact split varies by provider and service, so read the documentation for each service you use.

How responsibilities shift by service type

The more of the stack a provider manages, the less the customer has to secure directly, though some duties never move:

• Virtual machines: the customer typically manages the operating system, patches, installed software, firewall rules and data
• Managed databases and platforms: the provider handles more of the underlying system, while the customer manages access, configuration, network exposure and data
• Software as a service: the provider runs the application, while the customer still manages users, permissions, settings and the data they put in

Across all of these, the customer usually remains responsible for who has access, how data is classified and protected, and how the service is configured.

Responsibilities that always stay with you

Whatever services you use, expect to own:

• Identity and access: who can sign in, with what permissions and how accounts are reviewed
• Data: what you store, how it is classified, encrypted, retained and deleted
• Configuration: network exposure, storage permissions, logging settings and security features you choose to enable
• Application code: vulnerabilities in what you build and the libraries you use
• Secrets: API keys, passwords and certificates used by your applications
• Monitoring and response: noticing suspicious activity and acting on it

Manage identity and access carefully

Access mistakes can be very damaging, because one over-privileged account can expose many systems. Apply least privilege: give each person and service only the permissions they need. Use multi-factor authentication for human accounts, avoid long-lived keys where better options exist, separate production from other environments and review access regularly. Our guide to service accounts covers securing the credentials that integrations and automated jobs use.

Protect data

Classify the data you store so you know what needs the strongest protection. Enable encryption for data at rest and in transit where services support it, and decide who manages the keys. Restrict public access to storage by default, and check regularly for anything exposed unintentionally. Keep backups, protect them from deletion by compromised accounts and test restores.

Keep secrets out of code

Store application secrets in a dedicated secrets manager rather than in code, configuration files or environment files committed to repositories. The OWASP Secrets Management Cheat Sheet recommends centralising secrets, applying least privilege, rotating them and auditing their use (OWASP: Secrets Management Cheat Sheet).

Worked example: a responsibility matrix

The table below is a hypothetical responsibility matrix for a business web application running on virtual machines with a managed database. It illustrates how to assign owners, not a definitive split for any provider.

AreaProviderCustomerCustomer ownerData centre security and hardwareYesNoNot applicableVirtual machine operating system patchesNoYesPlatform engineerManaged database engine maintenanceLargely providerConfiguration and accessPlatform engineerNetwork rules and public exposureProvides toolsYesPlatform engineerUser accounts and permissionsProvides toolsYesIT administratorApplication code vulnerabilitiesNoYesDevelopment leadData classification and retentionNoYesData ownerLogging, monitoring and responseProvides toolsYesOperations lead

Configure logging and monitoring

Providers offer logging and monitoring tools, but customers usually need to enable, configure and review them. Turn on audit logs for administrative actions, keep them for an appropriate period and protect them from tampering. Set alerts for high-risk events, such as changes to access policies or public exposure of storage. Decide who responds to alerts and how.

Use secure defaults and guardrails

Reduce reliance on individual care by setting guardrails:

• Templates or infrastructure as code with secure settings built in
• Policies that block public storage or unencrypted resources
• Automated checks that flag misconfigurations
• Separate accounts or projects for production and testing

These catch mistakes before they become incidents.

Patch and harden what you manage

Where you run virtual machines or containers, keeping them updated is your job. Use supported operating system images, apply security updates on a schedule, remove software you do not need and rebuild images regularly rather than patching servers by hand indefinitely. Scan container images and application dependencies for known vulnerabilities before deployment, and track how quickly important fixes reach production.

Plan for incidents

Even with good controls, incidents happen. Decide in advance who is contacted, how access can be revoked quickly, how evidence is preserved and how affected customers would be informed. Know how to reach your provider's support for security issues. Practise with a short tabletop exercise so the steps are familiar before they are needed.

Review compliance obligations

Provider certifications cover the provider's side of the model. Your organisation still needs to meet its own obligations for the data and processes it runs in the cloud. Understand which controls the provider covers, which you must implement and what evidence you need to show.

Turn the model into a routine

Write down responsibilities for each service you use, assign owners and schedule regular reviews. Include cloud security in onboarding for engineers and administrators, so new team members understand which tasks are theirs from the first day. When you adopt a new service, read its shared responsibility documentation and update your matrix. Our guide to cloud architecture consulting covers how security fits into overall cloud design.

Frequently Asked Questions

What is the cloud shared responsibility model?

It is the division of security duties between a cloud provider, which secures the underlying infrastructure, and the customer, which secures what it builds, configures and stores.

What is the customer always responsible for?

Typically identity and access, data protection, configuration choices, application code, secrets and monitoring, whatever services are used.

Does using managed services remove customer responsibility?

No. Managed services shift some work to the provider, but customers still manage access, configuration, network exposure and data.

How do you apply the shared responsibility model in practice?

List each service you use, record which tasks fall to you, assign owners, enable logging and guardrails and review regularly.

Secure your side of the cloud

We map cloud responsibilities, tighten access and configuration and set up monitoring for business applications. See our custom app development services, or talk to us about cloud security responsibilities.

About the Author

Manav Sharma is the founder of Insyrge and a CRM solutions architect. He works across Zoho, Salesforce, HubSpot, Odoo and more, designing the CRM setups, integrations and automations that keep sales and operations teams working from the same data.