Shared responsibility model

The provider owns what you cannot touch: physical data centers, hardware, the hypervisor, the internals of managed services. You own what you can: identity and access, network and storage configuration, data classification and encryption choices, application code, and your users. The line moves with the service model — running your own virtual machines leaves most of the stack on your side, while managed platforms and SaaS absorb progressively more — but customer-side misconfiguration remains the classic cloud breach story, because the provider never takes that duty off your plate.

Audit frameworks formalize the model rather than trusting the marketing diagram. In a SOC 2 examination, your cloud provider appears as a subservice organization — typically carved out of your report — with the controls you rely on them for documented explicitly, while your report covers everything above the line. The same logic runs downstream: your report lists complementary user entity controls, the duties your customers must handle for your controls to work. The auditor then tests whether you genuinely operate your side — least-privilege access, hardened configurations, encryption settings, logging.

The model fails quietly when each side assumes the other has it covered. The fix is a written responsibility matrix per major provider — who patches, who configures, who monitors, who responds — kept beside your vendor reviews and reflected in your system description. Security reviewers and enterprise buyers often ask for it by name, and auditors treat its absence as a scoping question you should have answered long before fieldwork.