Introduction
At some point in the last few years, most UK businesses stopped asking whether to move to the cloud and started asking which part of it they were actually using. The answer, more often than not, is all three – without a particularly clear view of what each layer is doing, what it’s costing, or whether the mix makes sense.
That ambiguity has consequences. Procurement decisions get made on the wrong basis. Governance gaps appear between what IT manages and what business units have adopted independently. Security responsibilities get assumed rather than assigned. And when something goes wrong, working out who owns the problem takes longer than fixing it.
Understanding the difference between SaaS, PaaS, and IaaS isn’t an exercise in cloud theory. It’s the foundation for making sensible decisions about cost, control, risk, and supplier relationships across a technology estate that has grown considerably more complex than most organisations planned for.
Why the Confusion Persists
The three cloud service models have been defined and explained many times. The confusion persists because the boundaries between them have blurred in practice, and because vendor marketing doesn’t always help clarify which category a product sits in.
Most major cloud platforms now offer services that span multiple layers. Microsoft Azure sells infrastructure, platform services, and SaaS products under the same commercial relationship. A company using Microsoft 365, Azure Virtual Machines, and Azure App Service is simultaneously a SaaS customer, an IaaS customer, and a PaaS customer – with different responsibilities, different cost structures, and different contractual terms applying to each.
Within organisations, the picture is further complicated by the speed of SaaS adoption. Business units have procured tools outside of central IT processes. Finance uses one platform, marketing another, operations a third. Each of these is a SaaS relationship the organisation has entered into, often without the data processing agreements, access controls, or integration governance that a properly managed software relationship requires.
The starting point for clarity is understanding what each model actually means in terms of what the vendor provides and what the organisation remains responsible for.
SaaS, PaaS, and IaaS: What Each Model Actually Means
Infrastructure as a Service (IaaS)
IaaS is the closest cloud equivalent to owning physical servers – except you’re renting compute, storage, and networking capacity from a provider rather than managing hardware yourself. The infrastructure is virtualised and available on demand. You control the operating systems, applications, and data that run on it. The provider manages the physical hardware, the data centre, and the hypervisor layer beneath.
In practice, IaaS is the model that gives the most control and carries the most responsibility. You decide what software runs, how it’s configured, and how it’s secured. You’re also responsible for patching, availability architecture, and backup.
Common examples in the UK market include AWS EC2, Azure Virtual Machines, and Google Compute Engine. Organisations use IaaS when they need flexibility for custom workloads, when they’re migrating legacy applications that can’t be easily refactored, or when regulatory or compliance requirements mean they need precise control over the environment.
Platform as a Service (PaaS)
PaaS sits one layer up. The provider manages the underlying infrastructure – the servers, operating systems, and runtime environments – and you manage the applications you build and deploy on top of it. The value proposition is that development teams can focus on writing and deploying code without managing the infrastructure that runs it.
For organisations running software development internally or building customer-facing applications, PaaS reduces operational overhead significantly. Scaling, patching the underlying platform, and managing database infrastructure are handled by the provider. The trade-off is less flexibility about the environment itself – you work within the platform’s constraints rather than configuring your own stack.
Examples include Azure App Service, Google App Engine, AWS Elastic Beanstalk, and Heroku. Managed database services like Azure SQL Database and Amazon RDS also sit in this category – you manage the data and schema, the provider manages the database engine.
Software as a Service (SaaS)
SaaS is the model most people interact with daily without thinking of it in those terms. The provider delivers a complete, functioning application over the internet. You configure it and use it; the provider manages everything beneath – the infrastructure, the platform, the application itself, and the updates.
The appeal is obvious: no deployment, no patching, no infrastructure management, and typically a subscription model that makes costs predictable. The trade-off is limited customisation and full dependency on the provider for availability, security, and feature development.
The SaaS market in the UK covers virtually every business function: Microsoft 365 and Google Workspace for productivity, Salesforce for CRM, Workday for HR, Xero and Sage for finance, Slack and Teams for communication. Most organisations have far more SaaS tools in active use than they have formally catalogued.
The Shared Responsibility Model: Where This Gets Practical
The most important practical consequence of understanding these three models is grasping what the shared responsibility model means for each one.
In every cloud arrangement, security and compliance responsibility is split between the provider and the customer. Where the split falls depends entirely on which model you’re using.
With IaaS, the provider secures the physical infrastructure and hypervisor. You’re responsible for everything above that: operating system configuration and patching, network security groups, application security, identity and access management, data encryption, and backup. The blast radius of a misconfiguration is large because the degree of control is large.
With PaaS, the provider takes on the operating system and runtime layer as well. You’re responsible for your application code, its configuration, the data it processes, and access controls. The surface area of your responsibility is smaller, but it still includes the areas where most application-layer breaches originate.
With SaaS, the provider is responsible for virtually everything except your data, your user access configuration, and how you’ve set up the application for your use case. But those remaining responsibilities matter considerably – misconfigured sharing settings, overly permissive user roles, and unreviewed third-party integrations are among the most common causes of data exposure in SaaS environments.
Organisations that don’t understand this split make assumptions about who’s responsible for what. Those assumptions tend to surface as gaps during incidents or audits.
The Business Impact of Getting the Model Wrong
Choosing the wrong cloud service model for a given workload carries real cost – in money, management overhead, and risk exposure.
Using IaaS where PaaS would suffice means your team is spending time managing infrastructure that a platform service would handle automatically. That time has a cost, either in internal resource or contractor spend. It also introduces risk: self-managed infrastructure requires consistent patching, monitoring, and configuration discipline that is easy to let slip under operational pressure.
Conversely, forcing a workload onto a SaaS platform when it genuinely requires custom development creates a different problem. You end up with a product that doesn’t quite fit the process, and the workarounds accumulate over time in the form of manual steps, shadow systems, and integrations built outside the main platform.
On the cost side, IaaS consumption is highly variable and can escalate quickly without proper governance. Reserved instances, right-sizing, and auto-scaling policies require active management. PaaS and SaaS tend to have more predictable cost profiles but carry their own risk: SaaS sprawl – the accumulation of tools that aren’t actively used but are still being paid for – is one of the most consistent sources of wasted technology spend in UK businesses.
From a compliance perspective, the model determines what you need to evidence. Under UK GDPR, you remain a data controller regardless of which cloud model you use. But what you need to demonstrate – in terms of data processing agreements, technical controls, and transfer mechanisms – varies depending on what the provider is managing on your behalf.
Common Mistakes Organisations Make
Treating all cloud spend as equivalent. IaaS, PaaS, and SaaS carry different cost structures, different governance requirements, and different risk profiles. Organisations that aggregate them all under a single “cloud budget” line lose the visibility needed to manage any of them well.
Assuming SaaS means no security responsibility. The provider manages the platform. You manage access, data configuration, and integrations. A publicly accessible SharePoint site, an overpermissioned Salesforce profile, or a third-party SaaS integration with excessive data access are your responsibility to control – not the provider’s.
Using IaaS as a default for everything. Lifting on-premises servers into cloud virtual machines is the fastest migration path but often not the most efficient operating model. Many workloads that were migrated to IaaS could be running on PaaS or SaaS at lower cost and with less management overhead. The migration is the beginning of the journey, not the destination.
Not cataloguing SaaS adoption across the business. In most organisations, the IT team has visibility of centrally procured SaaS. They often don’t have visibility of tools adopted by individual departments on expense accounts or free tiers. That shadow SaaS estate carries data protection risk, integration risk, and cost risk that can’t be managed until it’s known about.
Conflating vendor certifications with your compliance. A SaaS vendor with ISO 27001 certification has demonstrated their security management is mature. It says nothing about whether you’ve configured the product securely or whether your users are accessing it appropriately. Compliance is still your responsibility.
How to Approach Cloud Model Decisions Practically
For organisations reviewing their cloud estate or planning new technology investments, a few questions help clarify which model is appropriate for a given workload.
How much control do you actually need? If the workload requires custom configuration, specific software versions, or precise network architecture, IaaS may be necessary. If you’re running a standard business application or deploying code that doesn’t require infrastructure-level control, PaaS or SaaS is likely more efficient.
What is your internal capacity to manage the environment? IaaS requires ongoing operational attention. If your team is stretched, taking on more infrastructure management than necessary is a risk. PaaS reduces that burden; SaaS eliminates most of it.
What does the data sensitivity and compliance profile require? Some regulatory environments impose specific requirements about data residency, encryption, and audit logging that affect which cloud models are viable and from which providers. This needs to be assessed before the model decision, not after.
Have you mapped what you currently have? Before making new model decisions, a clear inventory of current cloud consumption – by model, by provider, by cost, and by business function – is necessary. Most organisations are surprised by what this surfaces, both in terms of unmanaged SaaS tools and in terms of IaaS running workloads that haven’t been reviewed since initial deployment.
Are your supplier contracts appropriate to the model? IaaS, PaaS, and SaaS relationships carry different contractual requirements under UK data protection law. Article 28 processor agreements need to reflect what the provider is actually doing with your data, and that differs across the three models.
Where Carmatec Fits
Carmatec Digital UK helps organisations navigate cloud architecture decisions with their cloud solutions by providing a clear view of what each model means commercially, operationally, and from a compliance perspective. Whether that’s reviewing an existing cloud estate to understand where costs and risks are concentrated, supporting a new deployment decision with an objective assessment of the right model for a given workload, or helping rationalise a SaaS environment that has grown without sufficient governance – the work starts with understanding the current state accurately.
For technology leaders dealing with a cloud estate that’s grown faster than the governance around it, that clarity is usually the most valuable starting point.
Closing Thoughts
SaaS, PaaS, and IaaS are not interchangeable options in a catalogue. They represent fundamentally different arrangements about what you manage, what your supplier manages, what you’re responsible for when something goes wrong, and what it costs to operate over time.
Most UK businesses are using all three simultaneously, which is entirely reasonable. What matters is that the decisions are made deliberately – with a clear understanding of the trade-offs – rather than by default or based on what the nearest vendor was promoting at the time.
The organisations that manage their cloud estates most effectively are those with visibility across all three models: what’s running where, what it costs, who’s responsible for what, and whether the current mix still reflects what the business actually needs.
To review your current cloud service mix or get clearer on where responsibilities and costs sit across your estate, speak with the Carmatec team.
