What Is SaaS (Software as a Service)
- 2 days ago
- 24 min read
Every time you check email in a browser, approve an expense report on your phone, or watch your CRM update itself overnight, you are using SaaS. You never installed it, never patched it, and never touched the server it runs on. That quiet convenience is exactly why software as a service has become the default way businesses buy technology, and why understanding it properly changes how you choose, budget for, and manage every tool your organisation depends on.
TL;DR
SaaS (Software as a Service) is cloud-delivered software that a provider hosts, secures, and updates, while customers access it over the internet, usually by subscription.
The provider runs the application and its infrastructure; the customer manages users, data, and settings inside it, a division called the shared responsibility model.
The biggest benefit is speed: no servers to buy, faster rollout, and automatic updates.
The biggest trade-off is dependency: you rely on the vendor's uptime, pricing, and roadmap, and switching later can be hard.
SaaS sits alongside PaaS and IaaS as one of three core cloud service models defined by the U.S. National Institute of Standards and Technology (NIST).
What is SaaS?
SaaS (Software as a Service) is a way of delivering software over the internet instead of installing it on your own computers. The provider hosts the application, the servers, and the security patches. You simply log in through a browser or app, usually paying a recurring subscription, while the provider handles maintenance and uptime behind the scenes.
Table of Contents
What Is SaaS?
What is SaaS? SaaS stands for Software as a Service, a cloud model where a provider builds, hosts, and maintains an application, and customers use it over the internet rather than installing it themselves. You pay to use the software, not to own a copy of it.
The formal foundation for this comes from the NIST Definition of Cloud Computing (NIST Special Publication 800-145, published 2011 by Peter Mell and Timothy Grance), which defines SaaS as one of three cloud service models, alongside Platform as a Service (PaaS) and Infrastructure as a Service (IaaS). NIST describes cloud computing itself as on-demand network access to a shared pool of computing resources that can be provisioned quickly with minimal effort.
It helps to separate three related ideas. The SaaS product is the actual application, such as an accounting tool or a CRM. The SaaS delivery model is how that product reaches you: over the internet, from infrastructure you never see. The SaaS business model is how the vendor charges for it, almost always a recurring subscription rather than a one-off licence fee.
Most SaaS runs in a web browser, but that is a convention, not a rule. Many SaaS products also ship mobile apps, lightweight desktop clients, or expose an API for other systems to call. What makes something SaaS is not the browser; it is that the provider owns and operates the servers, databases, and code, while you only manage your account, your users, and your data inside it.
A useful comparison is renting a serviced apartment instead of buying a house. The landlord (the SaaS provider) maintains the building, fixes the plumbing, and handles security. You (the customer) bring your furniture, decide who has keys, and pay rent each month. The analogy breaks down at one point: unlike an apartment, most SaaS platforms serve thousands of customers from the very same running application, a design called multi-tenancy, which we cover later.
SaaS is a subset of cloud computing, not a separate category. Cloud computing is the broader shift toward renting computing power and services over the internet; SaaS is the layer closest to the end user, where the provider handles everything below the application itself.
How Does SaaS Work?
SaaS follows a fairly consistent lifecycle, whether the product is a small marketing automation tool or a global CRM suite.
A provider builds the application and hosts it on cloud infrastructure it owns or rents.
New customers sign up, or an administrator provisions accounts for their team.
Users connect through a browser, a mobile app, a desktop client, or an API.
Authentication confirms who the user is, and authorisation controls what they can see and do.
Customer data is stored and processed inside the provider's environment, often across multiple regions.
The provider rolls out updates, patches, monitoring, and backups without asking the customer to install anything.
Customers configure their own settings: user roles, permissions, integrations, and workflow rules.
Charges are calculated automatically, based on whichever pricing model the customer signed up for.
Behind that simple flow sits a fair amount of engineering: cloud infrastructure and content delivery networks that keep the app fast worldwide, databases that store customer records safely, identity systems that manage logins, APIs that let other tools talk to the product, and observability systems that alert the provider before small problems become outages. None of this is visible to the end user, which is exactly the point of SaaS.
Administration does not disappear, though. Customers still manage their own user list, permissions, data exports, and integration settings. SaaS removes server maintenance from the customer's job, not account management.
The Core Characteristics of SaaS
Most SaaS products share a set of traits drawn from NIST's broader definition of cloud computing, adapted to the application layer.
On-demand access — users can sign up and start working without waiting for hardware or manual setup.
Network availability — the software is reachable from any device with an internet connection.
Shared or pooled infrastructure — many customers often run on the same underlying servers and code.
Elasticity — the provider can scale capacity up or down as demand changes.
Measured usage — usage of storage, seats, or API calls is tracked and often billed on that basis.
Centralised management — the provider, not the customer, manages servers, patches, and infrastructure.
Continuous delivery — new features and fixes roll out regularly, often with no customer action needed.
Configurability — customers adjust settings and workflows without touching the underlying code.
Standardisation — most customers use the same core application, with configuration rather than custom code.
Subscription or usage-based billing — recurring payment replaces the old one-time software licence.
Not every SaaS product implements every trait identically. Some smaller or regulated products run single-tenant instances with less pooling; some enterprise contracts still involve heavier customisation. Treat this list as a common pattern, not a checklist that every SaaS vendor must tick completely.
SaaS Architecture: Multi-Tenancy, Single-Tenancy, and Data Isolation
Multi-tenancy means many customers, called tenants, share the same running application and often the same database, with logic that keeps each tenant's data separate. Single-tenancy means each customer gets a dedicated instance of the application. Hybrid tenancy mixes the two, for example shared application code with isolated databases per customer.
Isolation between tenants can be logical or physical. Logical isolation separates data using tenant IDs and access rules inside a shared database. Physical isolation gives each tenant its own database or storage volume. Neither approach is automatically safer than the other. A well-built multi-tenant system with strong tenant-aware access controls can be very secure; a poorly configured single-tenant system can still leak data through misconfiguration. Isolation quality depends on engineering discipline, not on the tenancy model alone.
Providers separate what customers can change (configuration, such as fields, roles, and workflow rules) from what only the provider changes (the underlying application code). Release management lets a vendor ship one update that reaches every tenant at once, which is how SaaS delivers continuous improvements without asking customers to install anything.
Larger SaaS providers often run regional deployments across separate availability zones or geographic regions, partly for performance and partly to meet data residency requirements, which we return to in the security section. A basic split worth knowing: the control plane manages configuration, provisioning, and orchestration, while the data plane actually processes and stores customer data. Understanding this split helps when you read a vendor's security documentation, since responsibilities are often described in exactly these terms.
SaaS vs. Traditional On-Premises Software
On-premises software runs on servers a business owns or leases itself, usually in its own building or a data centre it controls directly. The business installs it, patches it, backs it up, and scales the hardware when it needs more capacity.
Factor | SaaS | On-Premises |
Upfront cost | Low; mostly subscription fees | High; hardware, licences, install |
Who maintains it | The provider | Your own IT team |
Update speed | Continuous, provider-driven | Scheduled by your team, often slower |
Customisation depth | Configuration-based, often limited | Can be extensive, code-level |
Scaling | Usually fast, provider-managed | Requires buying more hardware |
Data location | Provider's data centres/regions | Your own premises or private data centre |
Offline access | Limited, connection-dependent | Often fully available |
On-premises software is not obsolete. Highly regulated environments, extremely latency-sensitive workloads, or organisations with very specific customisation needs sometimes still choose it. But for most day-to-day business software, SaaS now wins on speed of deployment and lower upfront cost.
SaaS vs. PaaS vs. IaaS
NIST's cloud definition sets out three service models, distinguished by how much of the technology stack the provider manages versus the customer.
Layer | IaaS | PaaS | SaaS |
What you get | Raw compute, storage, networking | A platform to build and deploy apps | A finished application |
Provider manages | Hardware, virtualization, networking | Above, plus OS, runtime, middleware | Everything below the app, plus the app itself |
Customer manages | OS, runtime, apps, data | Application code and data | Users, data, and configuration only |
Typical user | IT/infrastructure teams, developers | Software developers | End users and business teams |
Example use | Renting virtual servers | A managed environment to deploy custom code | Logging into a finished CRM or accounting tool |
As you move from IaaS toward SaaS, the provider takes on more responsibility and the customer keeps less control over the technology stack, in exchange for far less operational work. The Cloud Security Alliance frames this as a sliding scale: in IaaS, customers still patch operating systems and manage access controls themselves; in SaaS, the provider controls virtually the entire technology stack, and the customer's main job shifts to protecting login credentials and managing their own data.
SaaS vs. Cloud Computing, Hosted Software, and Managed Services
SaaS is a type of cloud computing, not a synonym for it. Cloud computing also includes PaaS, IaaS, and other service categories; SaaS is simply the model closest to the end user.
Hosted software is an older, looser term. It can describe a vendor running one dedicated copy of traditional software on a server for a single customer, which is closer to old-style outsourcing than to a true multi-tenant SaaS product.
Managed services typically means a provider operates infrastructure or IT functions on a company's behalf, which can include managing servers that run software the company still owns, rather than delivering a shared, subscription-based application.
Outsourcing is broader still. It can involve people, processes, or entire business functions, not just software. SaaS is a technology delivery choice; outsourcing is often a staffing or operating decision. The lines blur in practice, but the core distinction holds: SaaS specifically means a shared, internet-delivered, subscription-priced application that the vendor operates end to end.
Common Types and Examples of SaaS
SaaS spans almost every business function today. The examples below illustrate each category; they are not endorsements, and many real products blur categories or combine several delivery models.
Customer relationship management — tools that track leads, deals, and customer records, often built around a CRM integration layer and a sales pipeline.
Email and productivity — cloud email, documents, and spreadsheets used across a whole company.
Project and work management — task boards, timelines, and team collaboration tools.
Accounting and finance — tools covering accounts payable, accounts receivable, general ledger, financial close, revenue recognition, budget planning, and cash flow forecasting.
Human resources — systems for payroll, employee onboarding, time tracking, performance review, and applicant tracking.
Customer support — help desk, knowledge base, live chat, and chatbot support platforms.
Marketing automation — tools for email marketing, campaign tracking, and landing page creation.
E-commerce and point of sale — storefronts and point of sale software that run entirely in the cloud.
Analytics and business intelligence — dashboards that turn raw business data into charts and reports.
Cybersecurity — cloud-delivered protection such as data loss prevention and broader AI-driven security tooling.
Developer tools — cloud-based platforms for writing, testing, and shipping software.
Vertical or industry-specific SaaS — products built for one industry only, such as clinic scheduling or construction estimating.
Consumer SaaS — subscription apps aimed at individuals rather than businesses, such as streaming or fitness apps.
Some vendors mix delivery models under one brand, for example offering a SaaS dashboard alongside an on-premises component for regulated customers. Read a vendor's actual architecture documentation rather than assuming every module they sell is delivered the same way.
Key Benefits of SaaS
Lower upfront cost — no servers to buy, so budget shifts from capital spending to predictable operating expense.
Faster deployment — teams can be working inside a new tool within days, not months.
Automatic updates — security patches and new features arrive without an internal upgrade project.
Accessibility — staff can work from anywhere with an internet connection, on almost any device.
Scalability — adding users or storage is usually a settings change, not a hardware purchase.
Predictable recurring costs — subscription pricing makes budgeting more consistent than large one-off purchases.
Collaboration — many people can work in the same live system at once.
Reduced maintenance burden — internal IT teams spend less time patching and more time on strategic work.
Easier experimentation — free trials and monthly plans make it cheap to test a tool before committing.
Integration options — most SaaS products ship APIs that connect them to the rest of your stack.
SaaS is not always cheaper in total. A £15-per-user monthly fee looks small until it is multiplied across two hundred employees for five years, plus add-ons, storage overages, and premium support. Total cost of ownership, not the sticker price, is what matters when comparing SaaS against buying software outright.
Disadvantages, Risks, and Trade-Offs
Vendor dependency — your business relies on someone else's uptime, roadmap, and business decisions.
Subscription creep — small monthly fees across many tools add up to a large, easy-to-overlook total spend.
Vendor lock-in — proprietary data formats or deep workflow integration can make switching costly later.
Data portability limits — exporting years of data cleanly is not always as easy as vendors imply.
Internet dependency — no connection generally means no access to the software.
Outages — even reliable vendors have downtime, and you cannot fix it yourself.
Customisation ceilings — deep, code-level changes are usually impossible in a standardised, multi-tenant product.
Forced changes — vendors can redesign or retire features on their own timeline, not yours.
Price increases — renewal pricing can rise, sometimes sharply, especially after your team is dependent on the tool.
Shadow IT — easy sign-up means employees can adopt unapproved tools outside IT's visibility.
Vendor acquisition or shutdown — mergers or business failure can disrupt or end a service with little notice.
Reduced infrastructure control — you cannot inspect or harden servers the way you could on your own premises.
None of this means avoid SaaS. It means treat each of these as a planning question, covered later in provider evaluation and migration, rather than as a reason to fear cloud software altogether.
SaaS Security, Privacy, and Compliance
SaaS security runs on a shared responsibility model: the provider secures the application, its infrastructure, and the physical data centres; the customer secures how their own people use it. Moving to SaaS does not transfer all of your security obligations to the vendor. The Cloud Security Alliance notes that Gartner estimated through 2025 that 99% of cloud security failures would be the customer's fault, most often through weak identity controls or misconfiguration, not a break-in at the provider's data centre.
In the SaaS model specifically, the provider controls virtually the entire application stack, while customers are largely responsible for protecting login credentials and data from phishing and social engineering, which the Cloud Security Alliance links to the vast majority of cyberattacks. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) similarly stresses that SaaS customers must understand exactly where their responsibility ends and the provider's begins.
Customer-side responsibilities typically include:
Identity and access management, including multi-factor authentication and single sign-on.
Role-based access control and the principle of least privilege for every user.
Prompt user provisioning and, just as important, prompt deprovisioning when staff leave.
Reviewing audit logs and unusual account activity.
Understanding data retention, deletion, and residency settings inside each tool.
Reviewing sub-processors and signed data-processing agreements where required.
Checking a vendor's security certifications and independent assurance reports, without assuming a certificate alone guarantees complete security.
Regulatory exposure does not disappear either. A healthcare organisation that moves patient data into a SaaS platform still needs a signed Business Associate Agreement and still carries HIPAA obligations itself; the vendor does not simply inherit them. This example illustrates a broader rule: applicability of any specific law depends on your jurisdiction, industry, and data, so treat vendor compliance marketing as a starting point for your own review, not a substitute for it.
Data portability is protected in some jurisdictions by law. Under GDPR Article 20, EU residents have a right to receive personal data they provided to a company in a structured, commonly used, machine-readable format, and to have it transferred to another provider where technically feasible. This is a strong argument for testing data exports from any SaaS tool before you depend on it heavily, not just when you plan to leave.
Practically, this means treating SaaS security as an ongoing discipline: strong identity controls, careful OAuth application approval, regular access reviews, and clear escalation paths if a vendor reports an incident, alongside confirming the vendor's own encryption, monitoring, and business continuity practices. None of this is legal advice; consult qualified legal and security counsel for your specific regulatory situation.
SaaS Pricing Models and Cost Considerations
Per-user or per-seat pricing — a fixed fee for every named or active user.
Tiered plans — Basic, Pro, and Enterprise tiers that unlock more features or limits.
Usage-based pricing — charges tied to consumption, such as API calls or records processed.
Flat-rate subscriptions — one fee regardless of how many people use the product.
Freemium — a free tier designed to convert some users to paid plans.
Hybrid pricing — a base subscription plus usage-based add-ons.
Enterprise contracts — custom-negotiated terms for large organisations, often multi-year.
Beyond the headline price, budget for implementation, data migration, training, premium support, storage overages, API limits, add-on modules, contract minimums, and renewal increases. Many of the real costs of SaaS show up after the first invoice, not on the pricing page.
Pricing itself is shifting. Historically, Gartner forecast worldwide SaaS end-user spending at roughly US£247.2 billion in 2024, growing about 20% year over year, out of total public cloud spending of US£675.4 billion. In April 2026, Gartner forecast worldwide IT spending to reach roughly US£6.31 trillion for the year, with software spending growing about 14.7%, and flagged accelerating investment in AI-related infrastructure and services as a major driver (Gartner, 22 April 2026). As AI features and AI agents become common inside SaaS products, more vendors are testing usage-based and outcome-based pricing alongside, or instead of, traditional per-seat fees, since a single AI agent can sometimes replace work previously done by several licensed users.
How Businesses Implement and Manage SaaS
Define the business problem you are actually trying to solve.
Document functional and technical requirements with the people who will use the tool daily.
Classify the data involved and note any compliance requirements it triggers.
Identify every stakeholder: end users, IT, security, finance, and legal.
Compare providers against your requirements, not just their marketing pages.
Run security, privacy, legal, and financial reviews before signing anything.
Test the shortlisted product with a small pilot group first.
Plan integrations and data migration in detail before the main rollout.
Configure identity and access controls properly from day one.
Train users, ideally with role-specific guidance rather than one generic session.
Launch in stages where the organisation is large enough to benefit from a phased rollout.
Monitor adoption, cost, risk, and performance after go-live.
Review the vendor relationship and contract terms on a regular schedule.
Maintain a written exit plan even while the relationship is going well.
Ongoing SaaS management is its own discipline once a company runs dozens of subscriptions. That means tracking a live application inventory, optimising licences so you are not paying for unused seats, managing the full user lifecycle from onboarding to offboarding, watching renewal dates closely, and actively hunting for shadow IT tools that finance never approved.
How to Evaluate and Choose a SaaS Provider
A structured evaluation framework should cover product fit, ease of use, and accessibility; reliability, performance, and uptime history; SLA terms and support quality; security controls, privacy terms, and compliance evidence; data location, ownership, and export formats; APIs and integration ecosystem; scalability and administration; reporting depth; pricing transparency; contract length, renewal terms, and price-protection clauses; vendor viability and product roadmap; incident history and references; and implementation and exit support.
A concise buyer checklist:
Can we export all our data, in a usable format, on demand?
What does the SLA actually guarantee, and what happens if it is missed?
What security certifications or audit reports can the vendor share?
How much does the price rise at renewal, historically?
Who owns the data we put into this system?
What support is included, and what costs extra?
Does the vendor have a clear, funded roadmap, or does it look financially fragile?
Migrating from On-Premises Software to SaaS
Discover and inventory the systems, data, and integrations you currently rely on.
Cleanse the data before you move it, since migrating errors just moves the problem.
Map old fields and structures to the new system's format.
Run a small pilot migration before moving everything.
Test integrations and security controls in the new environment.
Run user acceptance testing with real staff, not just IT.
Plan the cutover date and communicate it clearly.
Consider running both systems in parallel briefly to catch gaps.
Manage change actively: training, documentation, and a clear support channel.
Keep a rollback plan in case the migration needs to pause.
Validate that migrated data matches the source before retiring the old system.
Archive old data appropriately instead of deleting it immediately.
Review performance and fix rough edges after go-live.
Migration difficulty depends heavily on data quality, how customised your old system was, how many integrations you run, and any regulatory constraints on your data. A simple team moving from spreadsheets to a SaaS tool faces a very different project than an enterprise retiring a twenty-year-old, heavily customised on-premises system.
Integrations, APIs, Data Portability, and Vendor Lock-In
Most SaaS products expose a REST API, letting other systems read and write data programmatically. Webhooks push real-time notifications when something changes, instead of forcing other systems to keep checking for updates. Native integrations connect popular tools directly, while integration platforms link many products together without custom code. Identity integrations, such as single sign-on, keep login centralised across your whole SaaS stack.
Watch for rate limits that cap how many API calls you can make, and API versioning that can break older integrations if you do not keep them updated. When you export data, check the actual schema and format you receive; a technically valid export that is missing key relationships or metadata is not much better than no export at all.
You can meaningfully reduce vendor lock-in by negotiating clear data-export rights into your contract, documenting every integration as you build it, testing a full data export periodically rather than only when you plan to leave, keeping data in portable, standard formats where possible, and maintaining a written migration plan even for tools you have no current intention of leaving.
SaaS Metrics and Business-Model Basics
Understanding a few metrics helps explain why SaaS vendors behave the way they do, and what actually drives their pricing, renewal, and support decisions.
Monthly recurring revenue (MRR) and annual recurring revenue (ARR) — predictable subscription income, the core of most SaaS financial reporting.
Customer acquisition cost (CAC) — what it costs a vendor to win a new customer.
Lifetime value (LTV) — the total revenue a vendor expects from one customer over time.
Gross margin — how much revenue is left after the direct cost of running the service.
Churn — the rate at which customers cancel; the single biggest threat to a SaaS business.
Net revenue retention (NRR) — whether existing customers are spending more or less over time, after churn and upgrades.
Customer success and product-led growth — two common strategies vendors use to keep churn low and expand usage inside existing accounts.
This matters to you as a buyer, not just as trivia. A vendor obsessed with reducing churn has an incentive to keep your renewal smooth and your support responsive; a vendor prioritising rapid customer acquisition over retention may invest less in the long-term relationship. Reading a vendor's investor materials or public statements about growth strategy can be a useful, if unconventional, part of due diligence.
The Future of SaaS
The most significant shift in SaaS right now is the move from AI-enabled software, where AI sits on top as an added feature, toward AI-native software, where AI agents are built into the core architecture from the start. BetterCloud's 2026 SaaS industry analysis describes this as SaaS moving from software that enables human work to agents that can autonomously perform parts of that work, reshaping product design, pricing, and how organisations govern their software portfolios.
This shift is already visible in market data. Industry reporting citing Gartner and Salesforce research points to enterprise AI adoption rising sharply through 2026, with agentic AI, systems that act rather than just answer questions, named a core priority by IT leaders. At the same time, reporting on a sharp software-sector market correction in early 2026 has linked investor concern to exactly this transition: if a single AI agent can do work that previously required several licensed seats, traditional per-seat SaaS pricing comes under real pressure (The Next Web, 5 March 2026).
Other themes worth watching include continued growth of vertical, industry-specific SaaS and "industry clouds", including specialised delivery models such as Quantum-as-a-Service; composable, API-first products that snap into an existing stack rather than replacing it; growing adoption of usage-based and hybrid pricing tied to outcomes rather than seats; more disciplined SaaS spend governance inside IT departments; rising data-sovereignty requirements pushing some workloads toward regional or sovereign cloud infrastructure; and continued tension between large integrated suites and focused, best-of-breed tools such as those built by solo and small micro-SaaS founders. These are informed projections based on current reporting, not guarantees, and the pace of AI-driven change in SaaS makes this an area worth checking again within the next twelve months.
FAQ
What does SaaS stand for?
SaaS stands for Software as a Service. It describes software that a provider hosts and runs, which customers access over the internet, usually for a recurring subscription fee, instead of installing and maintaining a copy themselves.
What is SaaS in simple terms?
In simple terms, SaaS means renting software instead of buying it. You log in through a browser or app, the provider looks after the servers and updates, and you just use the tool and manage your own account, data, and users inside it.
Is SaaS the same as cloud computing?
No. SaaS is one part of cloud computing. Cloud computing also includes PaaS and IaaS, which sit at different layers of the technology stack. SaaS specifically refers to finished applications delivered over the internet.
Is a web application always SaaS?
Not necessarily. A web application only counts as SaaS if a provider hosts and operates it for customers on a subscription or usage basis. A web app you build and host entirely yourself is not SaaS, even though it runs in a browser.
What are common examples of SaaS?
Common examples include cloud CRM tools, email and productivity suites, project management platforms, accounting software, help desk and live chat tools, marketing automation platforms, and HR systems such as payroll or applicant tracking software.
How does SaaS make money?
Most SaaS providers earn recurring revenue through subscriptions, tracked as monthly recurring revenue (MRR) and annual recurring revenue (ARR). Many also add usage-based fees, premium support charges, or paid add-on modules on top of the base subscription.
Is SaaS always subscription-based?
Almost always, though not universally. Most SaaS uses per-user, tiered, or usage-based subscriptions. Some products offer free, freemium, or one-off usage-based pricing without a recurring commitment, but ongoing subscription billing remains the dominant model.
What is the difference between SaaS, PaaS, and IaaS?
IaaS gives you raw infrastructure such as servers and storage. PaaS gives you a platform for building and running your own applications. SaaS gives you a finished application. Each layer shifts more operational responsibility from the customer to the provider.
Is SaaS secure?
SaaS security depends on both the provider and the customer under a shared responsibility model. Providers secure the application and infrastructure, while customers must manage strong identity controls, access permissions, and user behaviour. Neither side can fully secure a SaaS deployment alone.
Who owns data in a SaaS application?
Contracts vary, but customers typically retain ownership of the data they put into a SaaS platform. The vendor processes and stores it under the terms of the contract. Always confirm data ownership, export rights, and deletion terms in the specific agreement you sign.
Can SaaS work offline?
Most SaaS requires an internet connection, since the application and data live on the provider's servers. Some products offer limited offline modes that sync once a connection returns, but full offline functionality is the exception rather than the rule.
What happens if a SaaS provider shuts down?
If a provider shuts down or is acquired, customers typically lose access after a notice period, so having tested data-export processes and a documented migration plan in advance is essential to avoid losing access to critical business data.
Is SaaS cheaper than on-premises software?
SaaS usually has a lower upfront cost, but it is not automatically cheaper over the long run. Recurring subscription fees, per-user charges, and add-ons can exceed the cost of owned software over several years, so total cost of ownership matters more than the sticker price.
What is multi-tenancy?
Multi-tenancy is an architecture where many customers, called tenants, share the same running application and often the same database, with logic that keeps each tenant's data separate. It lets a SaaS provider serve many customers efficiently from one codebase.
How should a business choose a SaaS provider?
Evaluate product fit, security and compliance evidence, data export rights, SLA terms, pricing transparency, contract length, and vendor viability. Test the product with a pilot group, confirm you can export your data, and negotiate renewal and exit terms before signing.
Key Takeaways
SaaS is cloud-delivered software that a provider hosts and runs, while customers access it over the internet under a subscription or usage-based contract.
SaaS sits alongside PaaS and IaaS as one of three cloud service models defined by NIST, with the provider taking on more responsibility as you move closer to SaaS.
The clearest benefit is speed and lower upfront cost; the clearest trade-off is dependency on the vendor's uptime, roadmap, and pricing.
Security follows a shared responsibility model: the provider secures the application, but the customer must manage its own identity controls and user behaviour.
Before signing with any provider, confirm data-export rights, SLA terms, and renewal pricing in writing, not just in marketing materials.
Total cost of ownership, not the advertised per-user price, determines whether SaaS is actually cheaper than the alternative for your organisation.
Test full data exports periodically and keep a written exit plan, even for tools you have no plans to leave, to protect against vendor lock-in.
AI-native SaaS, where agents are built into the core product rather than added on top, is reshaping pricing and architecture across the industry in 2026.
Actionable Next Steps
Write down the specific business problem you want a SaaS tool to solve.
List the users, data types, and compliance requirements involved.
Shortlist two or three providers and compare them against the buyer checklist above.
Request each vendor's security certifications, SLA terms, and data-export documentation.
Calculate total cost of ownership over three to five years, not just the monthly fee.
Test a full data export from any tool before you commit to it long term.
Run a small pilot with real users before a company-wide rollout.
Set clear ownership for who manages user access, permissions, and offboarding.
Put a renewal and exit review on the calendar well before your contract auto-renews.
Revisit this evaluation roughly once a year, since SaaS pricing and AI features are both changing quickly.
Glossary
API — A set of rules that lets different software programs communicate and exchange data with each other automatically.
Annual Recurring Revenue (ARR) — The predictable subscription revenue a SaaS company expects to receive over a full year.
Authentication — The process of confirming that a user is who they claim to be, usually with a password or additional verification step.
Authorisation — The process of deciding what an authenticated user is allowed to see or do inside an application.
Churn — The rate at which customers cancel or stop using a subscription over a given period.
Cloud Computing — Delivering computing resources, such as storage, processing power, and software, over the internet instead of from local hardware.
Configuration — Adjusting settings, fields, or workflows inside an application without changing its underlying code.
Customer Tenant — One customer's isolated space inside a multi-tenant SaaS application, containing its own users and data.
Data Portability — The ability to export your data from one system in a usable format and move it to another.
Data Residency — Rules or requirements about which geographic location a customer's data must be physically stored in.
Encryption — Converting data into a coded format so it cannot be read without the correct decryption key.
IaaS — Infrastructure as a Service: a cloud model providing raw computing resources such as servers, storage, and networking.
Integration — A connection that lets two or more software systems share data or trigger actions in each other.
Monthly Recurring Revenue (MRR) — The predictable subscription revenue a SaaS company expects to receive each month.
Multi-Factor Authentication (MFA) — A login process requiring more than one form of verification, such as a password plus a code sent to a phone.
Multi-Tenancy — An architecture where many customers share the same application instance while their data stays logically separated.
Net Revenue Retention (NRR) — A measure of whether existing customers are spending more or less over time, after accounting for churn and upgrades.
On-Premises — Software installed and run on a company's own servers or hardware, rather than hosted by an outside provider.
PaaS — Platform as a Service: a cloud model providing a managed platform for building, running, and deploying custom applications.
Role-Based Access Control (RBAC) — A permissions system that grants access based on a user's assigned role rather than configuring each person individually.
SaaS — Software as a Service: software hosted and operated by a provider, delivered to customers over the internet, usually by subscription.
SCIM — System for Cross-domain Identity Management: a standard for automatically creating, updating, and removing user accounts across systems.
Service-Level Agreement (SLA) — A contract clause defining the level of service, such as uptime, a provider commits to deliver.
Shared Responsibility Model — A framework dividing security duties between a cloud provider and its customers, with the split changing by service model.
Single Sign-On (SSO) — A login system that lets a user access multiple applications with one set of credentials.
Single-Tenancy — An architecture where each customer gets a dedicated, separate instance of an application, rather than sharing one with others.
Subscription — A recurring payment, usually monthly or annually, in exchange for ongoing access to a product or service.
Vendor Lock-In — A situation where switching away from a provider becomes difficult or costly due to data formats, integrations, or contracts.
Webhook — An automated message one system sends to another the moment a specific event happens, instead of the receiving system asking repeatedly.
Sources & References
Mell, P. and Grance, T. "The NIST Definition of Cloud Computing." NIST Special Publication 800-145, National Institute of Standards and Technology, September 2011.
Simmon, E. "Evaluation of Cloud Computing Services Based on NIST SP 800-145." NIST Special Publication 500-322, National Institute of Standards and Technology, updated 3 February 2025.
Cloud Security Alliance. "The Shared Responsibility Model for Data Security." Cloud Security Alliance, 17 October 2023.
Orca Security. "Understanding the Importance and Relevance of CISA's Cloud Security Reference Architecture Announcement." Orca Security, 6 November 2024.
European Union. "Article 20 GDPR – Right to Data Portability." Regulation (EU) 2016/679 (General Data Protection Regulation).
Gartner, Inc. "Gartner Forecasts Worldwide Public Cloud End-User Spending to Surpass $675 Billion in 2024." Gartner press release, 20 May 2024.
Gartner, Inc. "Gartner Forecasts Worldwide IT Spending to Grow 13.5% in 2026, Totaling $6.31 Trillion." Gartner press release, 22 April 2026.
Gartner, Inc. "Gartner Says Worldwide Sovereign Cloud IaaS Spending Will Total $80 Billion in 2026." Gartner press release, 9 February 2026.
BetterCloud. "AI and the SaaS Industry in 2026." BetterCloud, updated 23 June 2026.
Tridens Technology. "Top 6 SaaS Industry Trends for 2026." Tridens Technology, 18 December 2025.
The Next Web. "AI-native enterprise spending surges 94% as SaaS stagnates at 8% and the SaaSpocalypse reprices per-seat software." The Next Web, 5 March 2026.
SC Media. "The Cloud Shared Responsibility Model — Operationalized." SC Media, 24 July 2026.