IaaS, PaaS and SaaS

What the cloud service models change

IaaS, PaaS and SaaS are not just procurement labels. They define where the operating responsibility sits, which team hardens the stack, and how much of the runtime, platform and application lifecycle remains under customer control.

With IaaS, the customer typically manages the guest OS, identity configuration, patches, application settings and data. With PaaS, the provider absorbs more of the platform burden, so the customer focuses on code, configuration, data and access. With SaaS, the provider runs most of the stack and the customer mainly governs users, data, integrations and policy.

This shift matters because the same control can move from a customer task to a provider task as you move rightward across the model. A control that is essential in IaaS may be unavailable or differently implemented in SaaS, so security teams must understand the service model before deciding who owns a safeguard.

Shared responsibility and control boundaries

The core issue across all three models is shared responsibility. The provider secures the service, but the customer still owns some combination of access management, data handling, tenant configuration and use-case governance. The exact split depends on the product, the contract and the deployment architecture, not just the marketing label.

That boundary is easy to misunderstand. Teams sometimes assume the provider covers more than it actually does, which leaves gaps in logging, configuration review, backup strategy or data governance. The reverse error also happens, when organisations try to impose controls on layers they do not administer directly.

For cloud planning, the service model is therefore a control-mapping exercise as much as a buying decision. It tells you which safeguards must be verified in-house, which are inherited, and which need compensating controls or contractual assurance.

Security and identity implications

Security obligations become more abstract as the model moves from IaaS to SaaS, but they do not disappear. Identity, sessions, API access, tenant settings and data permissions remain central in all three models, even when infrastructure patching or platform hardening is mostly provider-led.

In IaaS, the customer has the broadest exposure because it owns more of the stack and more misconfiguration paths. In PaaS, the main challenge is often controlling application and data access without full platform visibility. In SaaS, the risk shifts toward over-permissioned users, weak tenant configuration, shadow integrations and excessive trust in default settings.

The practical lesson is that “more managed” does not mean “less secure by default”. It means the risk surface changes shape. The most important controls move from host and platform administration toward governance of identities, permissions, configuration and data flows.

Choosing the right model for the control burden

Use IaaS when you need maximum technical control, custom network design, specialised system settings or workloads that do not fit a standard platform. Use PaaS when you want to reduce operational overhead and standardise the runtime while still retaining application-level control. Use SaaS when business users need a complete service and the organisation is willing to accept the provider’s operating model.

The right choice is rarely about security alone. It is about whether your team can continuously operate the controls that the model leaves to you, and whether the provider can evidence the controls it assumes. The more the service is managed, the more your assurance work shifts toward configuration review, contract terms, logging access and periodic access recertification.

For a broader cloud control perspective, the shared responsibility model, cloud logging and exit planning are covered in Cloud Security Guide, which is useful when comparing what remains customer-owned across service models.

External references that help anchor these controls include the NIST SP 800-53 Rev 5 Security and Privacy Controls for control catalog mapping and the NIST Cybersecurity Framework 2.0 for governance across identify, protect, detect, respond and recover.

Risk and Threat Considerations

These service models can create security exposure when organisations misread where responsibility shifts. The most common failure is assuming a provider-managed layer is also fully secured from the customer side, which can leave weak access governance, poor data handling or unreviewed integrations in place.

Failure mechanism: Control gaps emerge when teams do not map the service model to the actual control boundary, so the wrong party believes it owns patching, configuration, monitoring or data protection.

Impact: Misplaced trust can lead to exposed data, privilege abuse, unnoticed misconfiguration, weak auditability and delayed incident response, especially when identity and tenant controls are the only remaining customer levers.

Practitioner Guidance

Why practitioners should care: The cloud model determines your operating burden, your assurance obligations and the point at which a provider incident becomes your incident. Treat IaaS, PaaS and SaaS as different control environments, not interchangeable hosting options.

Governance implication: Define ownership by control, not by service label, so your teams know who manages identity, data, logging, resilience and recovery in each model. A clear responsibility matrix is the only reliable way to avoid coverage gaps.

Practitioner takeaway: The more managed the service, the more disciplined your review must be of access, configuration and data governance, because those become the remaining high-value control points.

Related resources from NHI Mgmt Group

• What breaks when organisations do not govern machine access in SaaS, IaaS, and PaaS environments?
• How should security teams extend cloud security controls from IaaS and PaaS into SaaS applications?
• What do organisations get wrong about shared responsibility in SaaS, PaaS, and IaaS?
• How should security teams implement data security governance across IaaS, PaaS, DBaaS, and SaaS?