How should security teams apply the shared responsibility model across SaaS, PaaS, and IaaS environments?

Security teams should map controls to the layer they actually govern. Providers secure the underlying cloud infrastructure, while customers secure identities, access settings, data handling, and application configuration inside the environment. The practical test is simple: if you can change it, you own it. That includes access limits, policy enforcement, privilege reviews, and validating the visibility the provider offers.

How the shared responsibility model changes by cloud layer

The model is easiest to apply when teams separate infrastructure responsibility from service responsibility. In IaaS, customers typically own far more of the security configuration, including operating systems, network rules, identity settings, patching, and workload hardening. In SaaS, the provider owns most of the stack, but the customer still owns access governance, data controls, and tenant configuration.

The important practitioner point is that “shared” does not mean evenly split. The split follows the service boundary: the more managed the service, the more your control plane shifts toward identities, permissions, data handling, configuration, and monitoring rather than platform maintenance.

For CSA Cloud Controls Matrix mappings, the practical outcome is to assign each control to the party that can actually enforce it, then verify that the provider’s service description and customer documentation match that allocation. That is especially important when a control is visible in the console but not fully enforceable by the tenant.

What teams should own in SaaS, PaaS, and IaaS

In SaaS, teams should focus on tenant-level settings, identity and access policies, data retention, auditability, and the security features exposed by the vendor. The provider handles most platform security, but customers still need to decide who can sign in, what data can be shared, and which integrations can be trusted.

In PaaS, customers usually inherit more of the runtime and platform maintenance from the provider, but they still own application code, secrets used by the application, access policies, and secure configuration of the service. A common failure mode is assuming a managed database, queue, or app service removes the need for entitlement review or data protection.

In IaaS, the customer responsibility boundary is widest. Security teams generally need to manage guest OS hardening, patching, firewalling, workload identity, logging, and encryption choices, while the provider secures the underlying compute, storage, and network fabric. For control mapping, NIST Cybersecurity Framework 2.0 is useful for separating governance, protection, detection, response, and recovery duties across the service layers.

How to avoid gaps, overlap, and false assumptions

The biggest error is treating cloud adoption as a simple transfer of responsibility to the provider. That creates blind spots around access review, shared secrets, cross-tenant exposure, logging gaps, and misconfigured settings that the customer can still change. The better approach is to document every control as provider-owned, customer-owned, or jointly administered, then test the actual service behavior rather than the marketing summary.

Another common mistake is using the same control standard for every service model without checking what is technically available. Some SaaS services expose strong configuration and audit options; others expose very little. Likewise, some PaaS products place tight constraints on patching and network tuning, so teams need compensating controls elsewhere rather than trying to force an IaaS-style control set onto a managed service.

For teams that need a prescriptive control baseline, NIST SP 800-53 Rev 5 Security and Privacy Controls provides a good way to assign access control, configuration management, audit, and system integrity requirements to the layer that owns them. Where cloud access and configuration are central, the Cloud Controls Matrix is especially useful for documenting shared duties across SaaS, PaaS, and IaaS.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CSA Cloud Controls Matrix, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
CSA Cloud Controls Matrix	IAM — Identity & Access Management	Cloud-layer responsibility hinges on who controls identity and access.
Recommendation — Map tenant, platform, and infrastructure access duties to the owning party.
NIST CSF 2.0	GV.OC-01 — Organizational Context	Shared responsibility depends on defining cloud service roles and boundaries.
	PR.AA-01 — Identities and Credentials are Issued, Managed, Verified, Revoked, and Audited	Customers retain identity governance across SaaS, PaaS, and IaaS.
Recommendation — Document which cloud controls the provider owns and which the customer owns. Enforce lifecycle control over cloud identities and credentials.
NIST SP 800-53 Rev 5	AC-2 — Account Management	Teams must manage accounts and access within the layers they control.
Recommendation — Assign account ownership and review access at the correct cloud layer.
ISO/IEC 27001:2022	A.5.23 — Information security for use of cloud services	Cloud use requires clear assignment of security responsibilities between parties.
Recommendation — Define cloud shared responsibilities and document supplier/customer security roles.

Practitioner Guidance

What to verify: Do not trust the shared responsibility diagram alone. Verify which party can actually enforce access changes, inspect logs, rotate secrets, patch components, and restore data after an incident. If the customer can change a setting but cannot prove the provider enforces it end to end, treat it as a customer control with provider dependency.

Decision rule: If the control affects tenant configuration, identities, data, or application behavior, assume the customer owns operational oversight even in SaaS. If it affects hardware, host OS, or core service availability, assume the provider owns it unless the contract and documentation explicitly say otherwise.

Practitioner takeaway: The right operating model is not “who sells the service,” but “who can still fail the control.” Build your control inventory from that question, then validate it against the real service boundary before relying on it.