Software as a service, usually shortened to SaaS, is a way to use applications without operating the servers that run them. This guide explains the delivery model, common subscription arrangements, and the practical responsibilities that remain with a business using online software.
How Does SaaS Work?
SaaS gives customers access to an application operated by a provider, commonly through a browser or connected app. The provider manages the underlying service, while customers use its features and configure the controls available to them. Subscriptions are common, but paying monthly is not what makes a product SaaS: the important distinction is who operates the application and infrastructure.
What makes software a service?
The NIST definition of cloud computing describes SaaS as using a provider's applications running on cloud infrastructure. Customers generally do not manage the underlying network, servers, operating systems, or storage, although they may control limited application settings.
Think of a shared online calendar. You sign in, create events, invite colleagues, and set permissions. You are using the application, not deciding when the server operating system should be patched or replacing failed hardware. The provider handles the service platform; your team handles how its calendar is used.
SaaS includes many categories, such as customer management, collaboration, accounting, and service desks. The category tells you what the application does. The delivery model tells you who operates it. Neither label alone establishes that the product suits a particular business.
A browser is common but not mandatory. Some services have desktop clients or mobile apps that connect to the same hosted system. Installing such a client does not necessarily mean the main application and its records are operated locally.
Likewise, not every remotely accessible program is automatically a well-defined cloud service. Look at the actual operating arrangement rather than relying on a marketing label. Ask who maintains the application, where its main records live, and which infrastructure decisions the customer controls.
Where SaaS sits among software delivery models
Cloud discussions often mix SaaS with infrastructure as a service and platform as a service. NIST distinguishes these models by the capabilities supplied and the responsibilities left with the customer. The distinction helps explain why buying a hosted business application differs from renting a server.
| Model | What you mainly receive | Typical customer work |
|---|---|---|
| SaaS | Access to an operated application | Manage users, settings, records, and permitted integrations |
| Platform as a service | A managed environment for deploying applications | Build and maintain application code and its configuration |
| Infrastructure as a service | Computing, storage, and networking resources | Manage operating systems and applications, alongside configuration |
| Locally operated software | Software running on infrastructure you operate or arrange | Maintain the application environment and relevant infrastructure |
These are broad categories, not a substitute for reading the service agreement. A managed offering may bundle extra operational work, and a SaaS product may still require customer-maintained connectors or client devices.
For a beginner, the key question is simple: are you trying to use a finished application or build and operate one? SaaS normally addresses the first need. More infrastructure control may provide flexibility, but it also creates work that a business must be equipped to handle.
How shared applications, accounts, and updates work
Many SaaS systems use multi-tenancy: a shared service supports multiple customer organizations while separating their access and records through technical controls. That separation is important, but the architecture is not identical across providers. Some offerings use more isolated environments, and the label alone does not establish the strength of the controls.
Within a business account, users receive identities and permissions. An administrator may invite colleagues, assign roles, connect other services, and choose organization-wide settings. Individual users then work within the access they have been given.
The provider typically deploys server-side fixes and feature changes. This removes much of the customer's server maintenance work, but it does not guarantee that every user sees the same features simultaneously. Changes may be staged, limited by edition, controlled by administrators, or dependent on a client-app update.
Updates also do not guarantee uninterrupted operation or freedom from defects. Your team should know where service notices and release notes appear, especially when changes affect integrations or important workflows. Provider-operated does not mean operationally invisible.
An integration connects the SaaS application to another system, often through an application programming interface, or API. The connection may copy selected records or trigger actions. It is not necessarily a complete backup, and it needs an owner who understands permissions, failures, and what happens when either product changes.
Understand subscriptions, capacity, and access
SaaS is commonly sold through recurring subscriptions, but billing models vary. A service might charge by assigned user, active user, transaction volume, storage, or a combination. Free and usage-based services also exist, so recurring payment is not a universal requirement of the delivery model.
A seat is usually permission for a user to access the service, but its precise billing definition belongs in the contract. An occasional reviewer, external guest, or automated account may be treated differently. Do not assume every account has the same entitlement or cost.
Plans bundle capabilities and limits. Two businesses can use the same named product while having different export controls, administration features, support channels, or storage allowances. When discussing a capability, identify the actual edition rather than assuming it is available to every customer.
Scaling may be straightforward, but it is not always instant or unlimited. Adding seats may be easy while upgrading a capacity limit requires approval, a different commitment, or additional configuration. Reducing a subscription may also follow different rules from expanding it.
Access depends on more than payment. The service, your internet connection, identity provider, and local device all contribute to whether someone can work. Offline features may preserve a limited subset of tasks, but synchronization rules and conflicts need to be understood before relying on them.
Know which responsibilities remain yours
Microsoft's explanation of shared responsibility in the cloud shows that customer responsibilities do not disappear in SaaS. Your organization still has to govern its data, identities, account access, and relevant configurations.
Start with account protection. Use the authentication options appropriate to your risk and enable multifactor authentication where available. CISA's MFA guidance explains how an additional authentication factor helps protect accounts when a password is compromised.
Decide who can invite users, publish information, connect applications, and change billing or security settings. Remove access when people leave or change roles. A provider cannot infer every employment change or business policy on your behalf.
Understand recovery arrangements too. A provider's disaster-recovery backup may not give you the ability to restore one mistakenly deleted record. Ask what can be restored, by whom, within what retention period, and whether recovery is included in your plan.
Data location, retention, and legal obligations require attention when the service handles sensitive information. A provider's certification can be relevant evidence, but it is not a blanket assurance that every customer use is appropriate. Obtain qualified advice where your industry or records require it.
Finally, plan for departure. Subscription access is not the same thing as possessing a complete, usable copy of your records. Learn how exports handle attachments, metadata, relationships, and inactive records before you rely on the application as the only working repository.
A worked example: a shared customer service desk
Imagine a hypothetical repair company replacing an email inbox with a SaaS service desk. The provider operates the application and database. Staff sign in from browsers, record requests, and assign work to colleagues.
The company's administrator creates roles: agents handle requests, supervisors review activity, and a limited number of administrators manage settings. Those choices belong to the customer even though the provider maintains the servers. If an agent leaves, the company must arrange to revoke that access.
During an internet outage, staff may be unable to see new requests. Any offline mode must be checked for its actual capabilities; the company should not assume that a mobile app contains all recent records. A documented temporary process can help preserve essential work until access returns.
Later, the company adds an accounting integration. The integration moves selected billing details but does not replace an export of customer conversations and attachments. If the company changes providers, it needs a separate migration plan.
This example illustrates the core trade-off: less infrastructure maintenance, alongside ongoing responsibility for access, workflows, connectivity, and data. SaaS can simplify operations without making the business a passive passenger.
Questions About SaaS Basics
Is SaaS the same as a website?
No. A website is an interface or collection of pages; SaaS is a service delivery model. A SaaS application often has a web interface, but many websites mainly publish information rather than provide an operated business application.
Can downloaded software still be SaaS?
Yes. A desktop or mobile app may be a client for a provider-operated service. Check whether the core application and main records depend on that service. The presence of a download does not determine the delivery model.
Does the provider own our business data?
Do not infer ownership or permitted use from the SaaS label. Read the agreement, privacy terms, and data-processing arrangements. Ownership, licensing, retention, and access after cancellation are separate questions that can require legal review.
Will SaaS replace our IT support?
It may reduce server maintenance, but someone still needs to manage accounts, devices, integrations, configuration, and incidents. The amount of support depends on the product and your operations. Simpler infrastructure does not mean there is no administration to perform.
Know Your SaaS Responsibilities
SaaS is a practical way to use an application while leaving its underlying operation to a provider. Understanding the boundary between provider work and customer work makes the convenience easier to use responsibly.
Next steps: Learn how to choose business SaaS, prepare with the software evaluation checklist, and browse the SaaS Reviews hub.
Sources
- NIST — The NIST Definition of Cloud Computing
- Microsoft Learn — Shared responsibility in the cloud
- CISA — Turn on MFA
This guide is general education, not professional purchasing, legal, or security advice.