The shared responsibility model across IaaS, PaaS and SaaS: a CCSP cheat sheet

By Emmanuel Aigbehi Walstra — CISSP, CCSP, CEH, CCSE. Thirty-plus years in cybersecurity, Lead Cloud Security Trainer at TSTC since 2020, more than 10,000 people trained, and author of CCSP Excellence (2024).

If one idea runs through every CCSP domain, it's the shared responsibility model. It sets out who secures what when a workload moves to the cloud. It appears directly in the CCSP exam outline. Subdomain 1.4 lists "security considerations and responsibilities for different cloud categories (SaaS, IaaS, PaaS)". It also sits behind questions on data security, operations, forensics, audit and contracts.

This cheat sheet gives you one table to memorise, what the major providers and the Cloud Security Alliance (CSA) actually say, and the traps that catch candidates.

The one-sentence version

The provider is responsible for security of the cloud. The customer is responsible for security in the cloud. The line between them moves up the stack as you go from IaaS to PaaS to SaaS.

AWS uses exactly that wording: security "of" the cloud versus security "in" the cloud. CSA's Security Guidance (v5) describes the same split and calls it the Shared Security Responsibility Model (SSRM). It adds that the line "will differ for IaaS, PaaS, and SaaS and often between different CSPs."

The cloud shared responsibility matrix

Key: C = customer · P = provider · S = shared (both parties have duties, in different parts of the stack)

The rows for data, configuration, identities, client devices, applications, network controls, the operating system and the physical layers follow Microsoft's published Azure responsibility matrix. The rows for runtime and middleware, hypervisor, patching and logging are my summary of Microsoft's, AWS's and CSA's descriptions.

How to read it

• Four rows are always yours: data, identities, configuration and, nearly always, endpoints. Microsoft states that "for all cloud deployment types, you own your data and identities." CSA makes the same point for SaaS. The customer's responsibilities "seldom drop to zero," and the customer still manages authorisation and entitlements.
• "Shared" doesn't mean half each. AWS describes shared controls as applying to both layers "in completely separate contexts." Patching is the standard example. AWS patches its infrastructure, and you patch your guest operating system and applications.
• Logging is shared in every model. The provider runs and logs its own platform. You have to switch on, collect, retain and actually review the logs available to you.

IaaS, PaaS and SaaS in practice

IaaS (for example, virtual machines and virtual networks)

You manage the guest OS and everything above it. AWS says that for Amazon EC2, the customer is responsible for "the guest operating system (including updates and security patches)," any software installed on the instance, and the configuration of security groups. The provider covers the hypervisor, hosts, physical network and facilities.

Typical failures: unpatched images, overly open security groups, and management interfaces exposed to the internet.

PaaS (for example, managed databases, app hosting and serverless platforms)

The provider manages the OS and runtime, and you manage your code, its dependencies, the service configuration and access. CSA describes the split as "more evenly split." The provider patches and configures the platform core. The customer handles everything they build on it, including how they configure the security features on offer. For abstracted services such as Amazon S3 or DynamoDB, AWS says customers remain responsible for "managing their data (including encryption options), classifying their assets, and using IAM tools to apply the appropriate permissions."

Typical failures: publicly accessible storage, weak database authentication, and secrets left in code or environment variables.

SaaS (for example, email, CRM and collaboration suites)

The provider runs almost the entire stack. Google Cloud's documentation says that "in SaaS, we own the bulk of the security responsibilities." Your part is still significant: who has access, with what rights, with MFA or without, what data goes in, how sharing is configured, and whether you review the audit logs.

Typical failures: over-shared files and links, no MFA, former employees who still have access, and unmanaged third-party integrations.

Where the providers differ

The model is broadly the same everywhere, but each provider has its own way of describing it:

• AWS groups controls into inherited controls, such as physical and environmental controls, shared controls, such as patch management, configuration management and awareness training, and customer-specific controls. It also stresses that your responsibility "will be determined by the AWS Cloud services that a customer selects."
• Microsoft Azure publishes the most explicit matrix, which the table above follows. It also notes that its matrix is "illustrative guidance" and does not change your contract.
• Google Cloud also publishes shared responsibility guidance and promotes shared fate. In that approach, Google takes a more active part through secure-by-default blueprints, landing-zone guidance and risk tooling. Google also notes that serverless functions (FaaS) have "a similar shared responsibility list as SaaS." Other sources group FaaS with PaaS, so check the specific service.

Exam takeaway: know the general model well, and treat any single provider's diagram as an example of it. Questions test the principle, not one provider's terminology.

Five traps that catch CCSP candidates

1. "In SaaS the provider is responsible for everything." It isn't. Data, identities, access and configuration always stay with the customer.
2. Confusing responsibility with accountability. A provider can take on responsibility for operating a control. Accountability for protecting your data, and for meeting your regulatory obligations, stays with you as the data owner or controller.
3. Assuming the model is identical across services. CSA and AWS both stress that the split varies by provider and by individual service, so check each service.
4. Forgetting the contract. The responsibility matrix only becomes enforceable through the contract, the SLA and the provider's audit reports, such as SOC 2 and ISO certifications. Domain 6 tests this.
5. Ignoring forensics and incident response. In IaaS you can usually snapshot a disk. In SaaS you depend on the logs and support the provider offers. Plan for this before an incident.

Quick self-check

1. A company runs its own code on a managed application platform. Who patches the underlying operating system? A. The customer · B. The provider · C. Both equally · D. Neither, because PaaS has no OS

Show the answer

Answer: B. In PaaS the provider manages the OS and runtime. The customer is responsible for its code and dependencies.

2. In a SaaS CRM, which task stays with the customer? A. Patching the CRM application · B. Securing the hypervisor · C. Reviewing which users have administrator rights · D. Physical data centre access

Show the answer

Answer: C. Access and entitlements always stay with the customer.

3. Which control does a customer fully inherit from an IaaS provider, in AWS's terms? A. Guest OS patching · B. Security group configuration · C. Physical and environmental controls · D. Employee awareness training

Show the answer

Answer: C. AWS lists physical and environmental controls as inherited. Patching and training are shared, and security groups are the customer's job.

For more scenario practice, try 30 free CCSP practice questions with explanations. To fit this topic into a wider schedule, see the six-week CCSP study plan. If you're still choosing between certifications, read CCSP vs CISSP: which first, and for whom.

Going further

The shared responsibility model is the thread that runs through all six domains, and it's worth revisiting at every stage of your preparation. Sectutor's free samples include a chapter of the study book, about 50 slides and 30 practice questions, with no email needed. The CCSP Kit ($49) has the full 430-page PDF and 600-question offline bank. Security teams teaching this internally can use the CCSP Slide Deck, which is licensed for internal training. There are no videos, classes, labs or vouchers, and sales are final.