Cloud shared responsibility: IaaS vs PaaS vs SaaS, and the controls you still own

Shared responsibility is a control-allocation model. In IaaS, the provider secures facilities, hardware, and core infrastructure while the customer often owns operating systems, network configuration, identity, data, and applications. In PaaS, the provider owns more of the stack, but the customer still owns access, configuration, data use, and monitoring. In SaaS, the customer usually still owns users, roles, settings, data classification, integrations, and retention choices.

The model is service-specific. Object storage, managed databases, serverless functions, Kubernetes, identity providers, email platforms, and CRM systems all draw different lines. Mature cloud security documents those lines before an incident or customer questionnaire asks who was supposed to operate the control.

The split also changes as teams adopt managed features. Enabling provider-managed keys, private endpoints, backup services, security posture tools, or SaaS admin controls may shift some operation to the provider while leaving configuration decisions with the customer. The shared-responsibility record should be updated when architecture changes, not only during audits. That record should also identify evidence sources, such as provider reports, tenant logs, policy-as-code results, and access reviews, so assurance answers can be proven quickly.

The checklist cannot decide your risk posture for convenience features. Long-lived access keys, broad admin roles, public sharing, unmanaged integrations, and weak tenant logging may speed delivery, but they also create predictable breach paths. Leadership must decide which shortcuts are unacceptable.

It also cannot decide the right cloud organization design. Account structure, subscription boundaries, landing zones, centralized logging, guardrails, and exception paths depend on scale and risk. A small team and a regulated enterprise should not use the same operating model blindly.

The checklist will not interpret provider certifications for customers. The provider's ISO or SOC report can support your answer, but it does not cover your tenant configuration, IAM decisions, data exposure, or workload security. You must explain the split honestly.

The classic cloud failures remain long-lived keys and overbroad privileges. Access keys sit in CI, laptops, or forgotten integrations for years. Service accounts have production admin rights forever because rotating or scoping them feels risky.

Public storage and missing audit logs are another pattern. Buckets, containers, snapshots, or SaaS folders become public through convenience or inheritance. Meanwhile, organization-level audit logging is absent, not retained, or not monitored, so the team cannot reconstruct what happened.

The biggest misconception is that the CSP's compliance covers tenant misconfiguration. Provider certifications prove provider controls in scope for the report. They do not prove customer encryption choices, network exposure, IAM reviews, backup isolation, or data retention settings.

Cloud programs also fail when development accounts become production by accident. A prototype receives customer data, a temporary integration creates permanent keys, or an analytics bucket becomes a reporting dependency. Without organization-level guardrails and tagging, those environments escape the control model until an incident or customer audit discovers them.

Use the checklist per service, not per provider. For each workload or SaaS tenant, document who owns identity, network exposure, data protection, logging, vulnerability management, backup, incident response, and configuration monitoring.

Then test control ownership against evidence. Confirm org-level logs, key rotation, privileged roles, public exposure, storage policies, encryption settings, SaaS admin configuration, and alerting. Where the provider owns a control, keep the relevant trust-center or report evidence linked.

Use the checklist during cloud onboarding and architecture review. New accounts, SaaS tools, CI integrations, and data stores should not become production dependencies until the shared-responsibility split is explicit and operational. Add ownership for each customer-controlled setting so future audits do not depend on guessing who accepted the default configuration. Review exceptions after launch so temporary exposure does not become standard architecture by habit or convenience. Keep customer-facing assurance language aligned with the same responsibility split and current tenant evidence from production services and logs reviewed. Reconcile that evidence after major provider changes.