Domain 1: Cloud Concepts, Architecture & Design Module 4 of 70

Module 4: Cloud Service Categories (SaaS, IaaS, PaaS)

CCSP Domain 1 — Cloud Concepts, Architecture & Design Section A 7 min read
The CCSP exam uses service models as the framework for nearly every responsibility question. If you cannot instantly identify the shared responsibility boundary for IaaS, PaaS, and SaaS, you will struggle with a significant portion of the exam.

The Three Service Models

ISC2 follows the NIST service model taxonomy: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). These are not just categories — they are responsibility frameworks. Each model shifts the boundary between what the provider manages and what the customer manages.

Infrastructure as a Service (IaaS)

IaaS provides the consumer with processing, storage, networks, and other fundamental computing resources. The consumer can deploy and run arbitrary software, including operating systems and applications. The consumer does not manage the underlying cloud infrastructure but has control over operating systems, storage, and deployed applications.

Customer manages: Operating systems, middleware, runtime, applications, data, access controls, guest OS patching, application-level security.

Provider manages: Physical data center, physical networking, physical servers, hypervisor, storage hardware.

IaaS gives the customer the most control and the most responsibility. The exam often presents IaaS scenarios where a security incident occurs at the OS level and asks who is responsible. The answer is always the customer.

Platform as a Service (PaaS)

PaaS provides the consumer with the capability to deploy consumer-created or acquired applications using programming languages, libraries, services, and tools supported by the provider. The consumer does not manage the underlying infrastructure, but has control over deployed applications and possibly configuration settings for the application-hosting environment.

Customer manages: Applications, data, user access, application-level configurations.

Provider manages: Everything below the application layer — OS, middleware, runtime, infrastructure.

Exam insight: PaaS is where the exam tests "vendor lock-in" most frequently. Because the provider controls the runtime and middleware, applications built on PaaS may use proprietary APIs or services that do not port easily to other platforms. When a question mentions portability concerns, think PaaS.

Software as a Service (SaaS)

SaaS provides the consumer with the capability to use the provider's applications running on cloud infrastructure. The consumer does not manage or control the underlying infrastructure, including network, servers, operating systems, storage, or individual application capabilities, with the possible exception of limited user-specific configuration settings.

Customer manages: Data, user access, user-specific settings.

Provider manages: Everything else — the entire stack from infrastructure through the application.

SaaS gives the customer the least control. The exam tests this by presenting scenarios where a SaaS customer wants to implement a specific security control but cannot because the provider does not offer it. The correct answer often involves contractual negotiation, compensating controls, or choosing a different provider.

The Shared Responsibility Stack

Think of the cloud stack as layers: physical facilities, physical network, physical compute/storage, hypervisor, operating system, middleware/runtime, application, data. As you move from IaaS to PaaS to SaaS, the provider's responsibility line moves up the stack, and the customer's responsibility shrinks.

The one constant across all three models: the customer is always responsible for their data and user access management. Even in SaaS, where the provider manages the entire application, the customer must classify their data, control who can access it, and ensure it meets regulatory requirements.

Anything as a Service (XaaS)

The exam acknowledges that the service model landscape has expanded. Security as a Service (SECaaS), Database as a Service (DBaaS), and other XaaS offerings exist. For exam purposes, map any XaaS to its closest NIST model to determine the responsibility boundary. DBaaS, for instance, is essentially PaaS with a database focus — the provider manages the database engine and infrastructure, while the customer manages the data and queries.

Common Exam Traps

  • Assuming SaaS means zero responsibility: The customer always retains accountability for data governance, access control, and compliance.
  • Confusing control with accountability: In SaaS, the customer has minimal control but full accountability for data protection outcomes.
  • Ignoring portability risks in PaaS: The exam treats vendor lock-in as a real risk. If the question mentions migration difficulty, PaaS-specific dependencies are likely the issue.
  • Misplacing the OS boundary: In IaaS, the customer patches the OS. In PaaS, the provider does. This is one of the most tested boundaries.

Key Takeaways

Service models define responsibility boundaries. IaaS: customer manages from OS up. PaaS: customer manages applications and data. SaaS: customer manages data and access. Data accountability never transfers. When the exam presents a scenario, identify the service model first — the responsibility boundary follows automatically.

Next Module Section A Review: Cloud Fundamentals