IaaS, PaaS and SaaS: Differences and Security Model

IaaS, PaaS and SaaS are the three cloud service models that appear in any modern architecture conversation, and also in any audit report touching AWS, Azure or GCP environments. The three acronyms describe how much the provider hands over to you and how much you still have to do yourself. Telling them apart matters because it changes three things at once: cost, flexibility and, above all, which parts of security are your responsibility and which are the provider's. That last one is where we see most failures in real cloud audits: organisations assuming the provider covers something it doesn't actually cover, and discovering the gap when an incident hits. This piece explains the differences between IaaS, PaaS and SaaS with real examples and digs into what truly matters for a company: the shared responsibility model and typical mistakes per model.

Quick definitions

IaaS (Infrastructure as a Service)

You rent virtualised infrastructure: virtual machines, storage, networks, load balancers. You install the operating system, the database, the runtimes, the code and everything else. It's the closest thing to having your own servers, but pay-as-you-go and without the physical layer.

Examples: AWS EC2 (virtual machines), Azure Virtual Machines, Google Compute Engine, OVHcloud Public Cloud.

PaaS (Platform as a Service)

You get a ready-made execution platform: the operating system, runtimes, managed database, queues, autoscaling. You upload your code (or your containers) and orchestrate it. You don't deal with the OS or runtime patches.

Examples: AWS Elastic Beanstalk / ECS Fargate / App Runner, Azure App Service / Container Apps, Google App Engine / Cloud Run, Heroku, Render, Vercel.

SaaS (Software as a Service)

You get software ready to use, in browser or app. There are no servers to maintain or code to deploy: you pay a subscription and configure whatever the product allows you to configure.

Examples: Microsoft 365, Google Workspace, Salesforce, HubSpot, Slack, Zoom, Workday, Notion, Jira / Confluence.

Quick table: what you manage in each model

To see it without going into the formal model: what the client manages in each case.

Going up the column reduces operational load and also control margin; going down expands both. Choosing between IaaS, PaaS and SaaS usually comes down to balancing that pair against the team's technical profile and the delivery pace the business demands.

The shared responsibility model

This is the heart of any serious cloud audit. AWS calls it the Shared Responsibility Model, Azure and GCP use practically identical models. The idea is direct: the provider protects the cloud (the infrastructure), you protect what you put on it. The exact line between "the cloud" and "what you put on it" shifts depending on the model.

What the provider always covers

Regardless of the model, the cloud provider covers physical security (datacenter, physical access control, power, cooling), hypervisor virtualisation, the provider's backbone network and the basic isolation mechanisms between clients. These elements aren't your operational problem.

What's always yours

Three responsibilities never get delegated to the provider:

1. Your data. Even if it lives on provider servers, it's yours. Classification, application-level encryption, keys and retention are your responsibility.
2. Your identities and permissions. How you configure IAM, which users you create, which roles you assign, which privileged accounts you keep and with what MFA. If you give Administrator to the whole team, no shared responsibility model covers you.
3. Configuration of the services you contract. Public S3 buckets, databases without a firewall, exposed containers. The provider gives you secure tools; using them badly remains a client error.

How the line shifts by model

• In IaaS the client takes on OS patches, OS hardening, runtimes and unmanaged databases, virtual networks, security groups, EDR agents, OS logs, VM backups.
• In PaaS the provider patches the OS and runtime. The client still takes on code, dependencies, secrets, service configuration, permissions and application logic.
• In SaaS the provider patches, secures and operates the application. The client takes on tenant configuration (policies, DLP controls, retention, MFA on accounts, integrations, third-party app permissions) and data.

Each shift upward (IaaS to PaaS to SaaS) reduces technical surface for the client, but doesn't remove responsibility for identities, data and configuration. This is what Verizon Data Breach or IBM Cost of a Breach reports repeat every year: the vast majority of cloud breaches are client configuration or identity failures, not provider infrastructure failures.

Security implications per model

Each model has its characteristic risk profile. Knowing where an attacker looks in each case helps prioritise defence.

IaaS: full technical surface

The organisation maintains a technical surface equivalent to running its own datacenter, only easier to provision and easier to misconfigure.

Typical risks:

• Unpatched virtual machines with exposed services. Classic ransomware and cryptojacking vector.
• Security Groups or NSGs too open (0.0.0.0/0 on critical ports). The most reported error by Cloud Security Posture Management tools.
• Misconfigured unmanaged databases: MongoDB, Redis or Elasticsearch without authentication exposed to the Internet.
• Public or accessible disk snapshots. They leak credentials and sensitive data without anyone touching the live system.
• Lack of inventory. Teams provisioning VMs in accounts the security area doesn't monitor.

Reasonable defence: automated patching, hardening baseline, EDR/XDR on every VM (covered in what is EDR), active CSPM, account segmentation, SIEM ingesting network flows and logs.

PaaS: code and secrets are the boundary

The client doesn't touch OS or runtimes, so the attacker doesn't look for system CVEs. They look for code, dependencies and secrets.

Typical risks:

• Vulnerable dependencies. Runtime vulnerabilities get patched by the provider; vulnerabilities in libraries you import are your problem.
• Configuration injection (environment variables with hardcoded secrets, secrets in public repositories).
• IAM permissions too broad assigned to the service. A service credential with write permissions over the whole account is a ticking bomb.
• Poorly isolated serverless functions or with execution times allowing exfiltration of large volumes before anyone notices.
• Public APIs without authentication or with weak authorisation (covered in API pentesting).

Defence: SAST/SCA in CI/CD, secret manager (not plain environment variables), minimal IAM policies, WAF in front of public endpoints, data flow threat modeling.

SaaS: identities and tenant configuration

In SaaS the client doesn't control the application, so the attacker goes after the only gap left: accounts and tenant configuration.

Typical risks:

• Phishing and credential theft giving access to the tenant. Vector number one in Microsoft 365 and Google Workspace.
• Malicious forwarding rules and consent phishing: third-party OAuth apps with dangerous permissions accepted by untrained users.
• Data shared publicly by mistake: SharePoint, Drive or Notion links ending up indexed.
• No MFA on privileged accounts or with weak MFA (SMS).
• No independent SaaS backup. Microsoft 365 and similar are not backup, they're limited retention.
• Integrations with third-party SaaS creating opaque chains of trust.

Defence: strong MFA on every account, periodic review of OAuth apps and mailbox rules, CASB or equivalent native SaaS controls, Conditional Access or equivalents, independent backup, anti-phishing training.

How to choose between IaaS, PaaS and SaaS

The choice depends on three axes: necessary technical control, available operational bandwidth and delivery speed.

When IaaS

• You need full control over the OS or stack (very specific software, detailed compliance requirements).
• You have a team experienced in operating infrastructure.
• Predictable workloads where IaaS cost beats managed PaaS at scale.
• Regulated workloads requiring specific residence and control not covered by standard PaaS.

When PaaS

• Application development where the OS adds no differential value.
• Teams without dedicated operations: the provider patches for you.
• Need to scale fast without managing capacity.
• Web services, APIs, mobile application backends, custom SaaS platforms.

When SaaS

• Standard functionality many companies need the same way (email, CRM, HR, document management, project management).
• No team to maintain the application.
• Business focus outside technology.

In practice, modern companies combine the three models: SaaS for back-office functions (Microsoft 365, Salesforce, HR), PaaS for their own product (Cloud Run, App Service, Lambda), IaaS for specific workloads that don't fit the above.

Common mistakes in each model

Short list extracted from repeated findings in cloud audits:

In IaaS

1. VMs with SSH/RDP access open to the Internet.
2. Snapshots and AMIs/images accidentally shared as public.
3. S3 / Blob / GCS buckets with AllUsers or AuthenticatedUsers permissions.
4. IAM roles with *:* or administrative permissions assigned to service accounts.
5. VPC logs or equivalents disabled.

In PaaS

1. Secrets in environment variables in public repositories.
2. Internal endpoints accidentally published when using default configuration.
3. Managed databases with too broad IP whitelist.
4. Serverless applications with permissions inherited from the entire account.
5. Build pipelines with persistent tokens outliving legitimate use.

In SaaS

1. No MFA or SMS MFA on privileged accounts.
2. Third-party OAuth apps with excessive permissions approved without review.
3. Email forwarding rules to external domains without alerts.
4. Public file sharing without expiration.
5. No independent tenant backup.

Each of these points appears in public incident reports from recent years.

Derived models worth knowing

Three acronyms the industry has added that appear in RFPs:

• FaaS (Function as a Service). PaaS variant where code runs only when there's an event. AWS Lambda, Azure Functions, Cloud Functions. Same risk profile as PaaS, with even more critical IAM surface.
• CaaS (Container as a Service). ECS, EKS, AKS, GKE, Cloud Run. Halfway between IaaS and PaaS: the client manages the containers, the provider manages the control plane.
• DBaaS (Database as a Service). RDS, Aurora, Cloud SQL, Cosmos DB, Atlas. PaaS specialised in databases. Reduces operational database work, not responsibility for what data you store and who accesses it.

Frequently asked questions

What's the difference between IaaS, PaaS and SaaS?

IaaS gives you infrastructure (virtual machines, storage, network) and you install everything on top. PaaS gives you a ready execution platform (managed OS and runtime) and you upload your code. SaaS gives you the complete software ready to use. Each upward jump reduces the client's operational work and increases what gets delegated to the provider.

What is the shared responsibility model in cloud?

It's the formal allocation of security responsibilities between provider and client. The provider covers security of the cloud (physical infrastructure, virtualisation, backbone network); the client covers security in the cloud (data, identities, configuration). The exact boundary shifts by model: in IaaS the client has more operational responsibility, in SaaS most of it is delegated to the provider except identities, data and tenant configuration.

Is PaaS or SaaS more secure than IaaS?

It isn't exactly a question of more secure, but of where the surface sits. In IaaS the client has more controls and more operational responsibility, so it also has more capacity to fail at patching or hardening. In PaaS and SaaS the technical surface is reduced but the attacker focuses on identities and configuration. The number of SaaS breaches via phishing and consent attacks in Microsoft 365 and Google Workspace shows that no model is secure by itself: it depends on how it gets configured.

Who is responsible if I lose data in SaaS?

You are. The SaaS provider guarantees availability and limited retention (according to Microsoft 365 official documentation, the recycle bin and default retention periods typically run between 30 and 93 days depending on licence), but it isn't independent backup. If a user deletes critical data, if a ransomware encrypts synced files, or if the retention window expires, recovering them requires a specific backup service contracted by you. GDPR and frameworks like NIS2 keep the data controller as responsible, regardless of who hosts the data.

Can I comply with NIS2 or DORA using only cloud services?

Yes, as long as the provider offers the necessary guarantees and the organisation correctly configures its part. Regulations don't prohibit cloud, they demand control. In practice, serious cloud providers (AWS, Azure, GCP, OVHcloud) publish attestations (SOC 2, ISO 27001, ENS, regional schemes) covering the provider's part. The client remains responsible for the controls that fall to them per the shared responsibility model. More detail in NIS2 Spain: a compliance guide for 2026 and DORA compliance 2026.

What about FaaS and serverless in this split?

FaaS is a PaaS variant: the client manages the code and the function's IAM configuration; the provider manages the OS, runtime and execution layer. The critical part from a security standpoint is the function's IAM: excessive roles on serverless functions are one of the most exploited cloud doors per recent OWASP Serverless Top 10 reports.

How do I audit the security of my IaaS, PaaS and SaaS services?

A professional cloud audit combines three layers. CSPM to detect configuration errors (public buckets, lax IAM, open security groups). Cloud pentesting to validate the depth of findings and find what automated tools don't see (covered in cloud pentesting AWS, Azure, GCP). Identity and permission review to detect forgotten accesses, dormant accounts and dangerous OAuth apps in critical SaaS. A good audit covers the three angles, not just one.

Related resources

• Cloud pentesting: AWS, Azure and GCP
• API pentesting REST and GraphQL
• NIS2 Spain: a compliance guide for 2026
• What is SIEM and how it works
• What is EDR

---

Does your company use IaaS, PaaS or SaaS and you're unsure which parts of security are yours and which are the provider's? At Secra we run cloud audits covering the three models: configuration review, actionable findings and prioritised roadmap to close the gaps that matter. Tell us what environment you have and we'll see where to start.