SECURITYATLAS✳

✳ The reference desk / In practice

Shared responsibility

The split of security duties between a cloud or SaaS provider and the customer, which varies by service.

What it means

Using a hosted service changes who performs security work; it does not make the work disappear. The division depends on the particular service and agreement. A provider may operate facilities, hardware, and parts of the software stack while the customer manages identities, data, permissions, and configuration. A managed database and a rented virtual machine usually leave different tasks to the customer. Responsibility should be translated into named activities and owners, including detection, backup, recovery, and incident communication, rather than reduced to a generic cloud diagram.

The idea at a glance / Cloud

Provider maintenance does not set your readers.

Keep the exact service agreement, reported provider work and customer access result together.

Fictional Harbor operates a managed object store for NorthCo under S174. The agreement assigns the service OS to Harbor and object-reader policy to NorthCo’s Nora. Harbor reports patch P174. NorthCo still has an unwanted public-read grant for O174, while W174 has legitimate reading permission. Q174 to restrict public reading is unapplied.

Shared responsibility: Keep the exact service agreement, reported provider work and customer access result together. The explanation below describes the relationships.Harbor / NorthCo · managed storeS174 agreement; selected duties onlySelected service agreement S174Harbor: service OS maintenanceNorthCo: object-reader policyHarbor · provider report P174Reports service OS patchedIndependent OS check not doneNora · customer access ownerUnwanted public grant remainsW174 keeps its own read grantNorthCo · independent probesPublic 200 · W174 200 · O174Q174 restriction not appliedPROVIDER PATCH ≠ PRIVATE READ

READ THE PICTURE

Different duties, same service

Harbor reports its service OS patch, but NorthCo’s public grant still returns O174 anonymously. W174’s permitted read also works; Nora’s restriction task is unapplied.

Keep in mindS174 is a fictional selected agreement, not a contract or proof of provider performance. P174 is a provider report, not an independent OS inspection. This models object access only; backup, retention, encryption options, recovery and incident duties need their own service-specific records and tests. No real provider or customer data is used.

Read the complete example
  1. Different duties, same service. Harbor reports its service OS patch, but NorthCo’s public grant still returns O174 anonymously. W174’s permitted read also works; Nora’s restriction task is unapplied. S174 explicitly assigns managed-service OS work to Harbor and object-reader decisions to NorthCo. P174 reports the provider’s patch; its completion is not independently inspected here and it does not change NorthCo’s policy. Nora owns the selected private-object requirement and Q174 is still unapplied/unverified. Independent HTTP/SQL probes return the unchanged synthetic O174 to both an anonymous reader and permitted W174. This is a demonstrated unwanted reader under the current policy, not proof of a historic incident or failure of the provider’s OS patch. Original O174, S174 and P174 remain. Other service duties and layers require separate accountable records; the split would change for a virtual machine or a different agreement.

S174 is a fictional selected agreement, not a contract or proof of provider performance. P174 is a provider report, not an independent OS inspection. This models object access only; backup, retention, encryption options, recovery and incident duties need their own service-specific records and tests. No real provider or customer data is used.

Diagram references: AWS: responsibilities depend on the selected service · NIST SP 800-210: cloud data-owner access control

AN ILLUSTRATIVE SCENARIO

A provider patch beside customer permissions

S174 assigns CloudHost the managed-service OS and Meridian’s Kael the object-reader policy. CloudHost reports P174, but an unwanted Meridian public grant still returns O174 anonymously. Permitted W174 also reads it. Kael’s Q174 restriction is unapplied; provider maintenance does not decide the customer’s readers.

Put it to work

  1. Read the documentation and contract for the exact service and deployment. List operational tasks such as patching, access reviews, encryption-key handling, logging, retention, and restoration.
  2. Assign a customer owner to every task that remains yours, and document the provider's commitments and dependencies. Clarify notification timelines, support access, and actions required during an incident.
  3. Test critical assumptions with the configured service. Revisit the responsibility record whenever the service tier, architecture, integration, data sensitivity, or contractual terms change.

How to check your work

Choose an account compromise or accidental deletion scenario and walk through who detects it, who acts, and what evidence each side supplies. Demonstrate the customer-owned steps using test data, including access revocation and recovery.

Connect the ideas

  • Backup

    A copy of data kept so integrity and availability can be restored after loss, preferably beyond the production identity’s reach.

  • Authorization

    The decision about whether a person, device, workload, or anonymous requester may perform a particular action on a resource.

  • GRC

    The organizational functions that set policy, track risk, and collect assurance evidence. Not a product that grants safety.

Explore a field lesson

Find your next idea.

Tip: press / to open search. Escape closes this window.