Home / Glossary / SaaS (Software as a Service)
Tech & ITSaaS (Software as a Service)
By Sitraka Forler · Lecturer, Durham Business SchoolUpdated 3 October 2026 About this site
Finished software you use over the internet; the provider runs everything beneath it.
The provider runs the application and all the infrastructure under it; you just sign in through a browser or an application programming interface (API). Microsoft 365, Salesforce and Gmail are SaaS. You manage nothing technical, but under the shared-responsibility model your data, who has access and your settings are still yours to secure.
The intuition
Software as a service means you use a finished application that somebody else runs. There is nothing to install beyond a browser or a small client, nothing to upgrade and no server to keep alive: the provider owns the code, the machines it runs on, the database behind it and the people on call at three in the morning. You pay a subscription, usually per user per month, and sign in. Microsoft 365, Salesforce, Gmail, Slack and Bloomberg Anywhere are all SaaS, and so is the risk dashboard many funds now rent instead of build.
The useful way to place SaaS is as the top layer of a stack. Infrastructure as a service rents you raw machines; platform as a service runs your code on machines it manages; software as a service runs the whole application and hands you only the screens and an API. Each step up trades control for convenience. You cannot change how Microsoft 365 stores a spreadsheet, but you also never patch the server it lives on.
What does not move is responsibility for your own data and your own users. Under the shared-responsibility model the provider secures the service; the customer still decides who may log in, whether multi-factor authentication is enforced, which files are shared externally and how long records are retained. Most SaaS incidents at firms are not provider breaches but a former employee's account left active or a client file shared with the wrong link. Buying SaaS removes the server work; it does not remove governance.
Onboarding a new analyst to a SaaS risk dashboard, and offboarding her properly
- A fund subscribes to a risk-analytics SaaS at 90 euros per user per month. Nothing is installed: the vendor runs the application at a URL such as risk.example.com and exposes a REST API for exports. The fund's IT team connects the service to its identity provider so staff log in with their work account.
- Day one: IT adds the analyst to the group risk-dashboard-users in the identity provider. The SaaS receives her identity through single sign-on and creates her profile automatically. She opens the URL, authenticates once with her password and authenticator app, and sees the portfolios her group may view.
- Week two: she needs daily VaR figures in a pandas workflow. She generates an API key from the dashboard's settings page, stores it in an environment variable and calls GET https://risk.example.com/api/v1/var?date=2026-09-30 with the key in an Authorization header. The provider rate limits her to 600 requests an hour; that is their decision, not hers to change.
- Month three: the vendor deploys a new version overnight. The fund changed nothing and ran no upgrade; one chart has moved. That is the SaaS bargain: no maintenance, and no control over the release calendar.
- What goes wrong: a quarterly access review finds that an analyst who left in June still has an active profile because she was never removed from the group. The vendor was never at fault; the fund's access process was. Her account is disabled in the identity provider and SSO revokes her dashboard access within minutes.
- The invoice shows 42 seats while only 35 people logged in last month. Trimming unused seats is also the customer's job: the provider bills what you configured, not what you used.
With SaaS you stop running software and start running access: the provider owns uptime and upgrades, you own who gets in, what they export and how many seats you pay for.
Common pitfalls
- Assuming the provider's security covers your account: a weak password without MFA on a SaaS login is still the customer's hole, and the shared-responsibility model says so explicitly.
- Forgetting offboarding: SaaS accounts not tied to the identity provider survive the leaver's last day, and audits find them months later.
- Ignoring data residency and export terms: where the provider stores client data and how you get it back if you leave are contract questions to settle before migrating.
- Building a critical workflow on a vendor API without reading its limits and versioning policy, then being surprised when an endpoint is retired with ninety days' notice.
- Letting seat counts drift: subscriptions are billed per configured user, and unused seats quietly cost as much as used ones.
Frequently asked questions
What is SaaS in simple terms?
Software you rent and use over the internet instead of installing and running yourself. The provider hosts the application, stores the data and ships updates; you sign in through a browser or an API and pay a subscription. Microsoft 365, Salesforce and Gmail are everyday examples.
What is the difference between SaaS, PaaS and IaaS?
They are three layers of cloud service. IaaS rents virtual machines, storage and networks you configure yourself, as on AWS EC2. PaaS runs your own code on a platform the provider manages, as on Heroku or Vercel. SaaS is the finished application, run entirely by the provider, as with Microsoft 365. Moving up the stack means less control and less maintenance.
Who is responsible for security in SaaS?
Both sides, split by the shared-responsibility model. The provider secures the application, its servers, networks and data centres. The customer secures what it configures: user accounts, multi-factor authentication, sharing settings, API keys and data classification. A leaked password or an over-shared document is the customer's responsibility even though the provider hosts everything.
Is SaaS cheaper than running software yourself?
Usually for small and medium teams, because the subscription includes hardware, operations, upgrades and support that would otherwise need staff. At very large scale, or for workloads with heavy data volumes, running your own can cost less. The honest comparison includes the people hours spent patching, backing up and being on call, not only licence fees.