---
{
  "title": "Cloud shared responsibility",
  "summary": "Assign ownership for each cloud control using the specific service boundary, then verify customer configuration instead of relying solely on provider assurance.",
  "topic": "networking",
  "level": "Beginner",
  "updated": "2026-10-12",
  "units": [
    6
  ],
  "aliases": [],
  "sources": [
    {
      "title": "AWS: Shared Responsibility Model",
      "url": "https://aws.amazon.com/compliance/shared-responsibility-model/"
    },
    {
      "title": "NIST: Definition of Cloud Computing",
      "url": "https://csrc.nist.gov/pubs/sp/800/145/final"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---
## The idea

Cloud security is shared between the provider and customer, but the boundary changes by service. Providers typically protect the infrastructure they operate. Customers remain responsible for relevant configuration, identities, data, and use of the service. In infrastructure services, customers may also own guest-system patching. Review the actual service’s responsibility documentation and assign an owner to each control so a gap is not hidden by assumptions.

## In practice

A provider secures storage infrastructure, while the customer configures who can read a storage object and whether it contains sensitive information.

## A common misunderstanding

A provider compliance report does not prove that your accounts and resources are correctly configured.

## Check your understanding

Who should check whether a storage resource is exposed?

**Think it through:** The responsible customer team, using the service’s permission and configuration model.

## Turn the boundary into assigned work

Imagine a fictional academy stores private enrollment records in a managed object-storage service. The provider operates underlying infrastructure, while the academy configures identities, sharing, and its use of the data. These tasks need named owners inside the academy.

“Shared” should not mean that either party assumes the other will notice every mistake. Write the control, the responsible party, the configuration or evidence, and the review frequency. The boundary can vary between products even within one provider.

## Provider evidence has a defined scope

A provider assurance report can help evaluate controls operated by that provider. It does not demonstrate that the academy's own identities have appropriate permissions or that a specific object is private.

Suppose the storage service is operating as designed but the customer accidentally permits anonymous reads. The infrastructure's security and the customer's exposure are separate questions. Validate the actual resource policy and observable access rather than treating an assurance badge as a configuration test.

## Managed does not mean unowned

When a platform handles patching or replication, the customer still needs to understand the offered capability and its limits. Recovery of provider infrastructure may differ from recovering an accidentally deleted customer record or an unwanted configuration change.

For the academy, document its required recovery outcome and verify whether the service's features meet it. Assign ownership for the remaining gaps, including account recovery, key access, and data export.

For a paper exercise, list a virtual machine, managed database, and hosted document application. For each, assign operating-system maintenance, account permissions, sensitive-data sharing, and recovery verification. Mark uncertain tasks for service-documentation review. The exercise succeeds when every necessary control has an accountable owner and appropriate evidence, rather than when the table contains the word provider in as many rows as possible.

## Keep exploring

- [[cloud-security-architecture]]
- [[cloud-identity]]
- [[cloud-storage-security]]