When a company adopts software as a service (SaaS), the vendor runs the servers and the code, but the customer still decides how the product is set up and what data goes into it. This article explains where that line sits, why it matters, and how a small team can review its own side of it.
What does “shared responsibility” actually mean?
Cloud security is a partnership between provider and customer. The United Kingdom’s National Cyber Security Centre (NCSC) describes it this way: the more of a service you hand to the provider, the more of the security work the provider carries. Its guidance therefore recommends delegating as much responsibility as you reasonably can.
The model is usually explained through three service types:
| Model | What the provider supplies | What the customer carries |
|---|---|---|
| Infrastructure as a service (IaaS) | Basic computing, storage and networking | The most work, since responsibility varies machine by machine |
| Platform as a service (PaaS) | A managed platform for building or hosting applications | Less than IaaS, more than SaaS |
| Software as a service (SaaS) | The whole application | The least, but never zero |
The NCSC notes that SaaS is the most delegated of the three, and that it recommends SaaS when a service meets your needs, because the provider can deliver security at scale. Consistent, highly managed behavior also makes it easier for the provider to monitor and patch the service.
Which jobs always stay with the customer?
According to the NCSC, some duties never transfer, whatever the service model:
- Confirming that the service meets your security needs before you rely on it.
- Configuring the service you choose.
- Deciding what data you put into it.
The NCSC adds that penetration tests and configuration checks usually target the parts you control, which is a hint about where problems tend to appear. A vendor can patch its software overnight, but it cannot know that your sales team shared a folder with the whole internet or that a former contractor still has an account.
Plain-language examples of customer-side work include:
- Deciding who gets an account and what role they hold.
- Turning on sign-in protections such as multi-factor authentication, which asks for a second proof of identity beyond a password.
- Choosing sharing and export settings.
- Switching on audit logging, where the product offers it, and deciding who reads the logs.
- Removing access promptly when people leave.
Why do configuration gaps matter so much for SaaS?
The US Cybersecurity and Infrastructure Security Agency (CISA) offers a useful signal. It says it established its Secure Cloud Business Applications (SCuBA) project in 2022 to address cybersecurity and visibility gaps exposed by intrusions involving SaaS products. The project’s guidance is aimed first at US federal civilian agencies, but CISA states that the baselines and tools are available to all agencies and to private sector organizations.
In other words, a national cyber agency judged that misconfigured or poorly monitored SaaS was common enough to justify a dedicated program. That does not mean vendors are careless. It means that the default settings of a general-purpose product are written for the average customer, and no customer is average.
What do CISA’s SCuBA baselines offer?
According to CISA, SCuBA provides secure configuration baselines, which are written lists of recommended settings, for two widely used suites: Microsoft 365 and Google Workspace. Organizations can adopt the recommendations and tailor them to their own requirements and risk tolerance.
CISA also describes two assessment tools, both described as no-cost and both introduced in 2023:
- ScubaGear checks a Microsoft 365 tenant, meaning an organization’s own instance of the service, against the baselines.
- ScubaGoggles checks whether a Google Workspace organization’s configuration conforms to the baselines and points out what to change.
Two caveats are worth stating. First, the baselines cover only those two product suites, so they do not directly help with the many other tools a company uses. Second, the baselines are a government agency’s recommendations, not a guarantee. Treat them as a well-reasoned starting point and adapt them.
The broader lesson transfers even if you use neither suite: a vendor-neutral list of “settings we expect to be on” is more reliable than memory.
Is it enough to pick a trustworthy vendor?
Choosing well is the part of the job the customer cannot skip, and the NCSC suggests using its 14 Cloud Security Principles as the yardstick. The list includes:
- Data in transit protection
- Separation between customers
- Governance framework
- Operational security
- Supply chain security
- Secure user management
- Identity and authentication
- Audit information and alerting for customers
- Secure use of the service
The final principle, secure use of the service, is the one that points back at you. A strong vendor answers the first thirteen, but only the customer can make sure the product is used safely day to day. For a structured way to compare products before signing, see how to evaluate a SaaS tool before your team commits.
The NCSC also gives advice for businesses that use a managed service provider: assess it as rigorously as you would the cloud provider, apply least privilege, and avoid handing it “root” or “global administrator” rights. Least privilege means giving each person or system only the access its job needs.
What are the trade-offs of delegating more?
Delegation is not free. The NCSC acknowledges that managed, cloud-native services increase vendor lock-in, meaning the cost and effort of moving elsewhere grows as you rely on more of a provider’s features. That is a security trade as much as a commercial one: if you cannot leave, you have less leverage when a vendor’s practices fall short. Readers weighing that risk may find the EU Data Act’s SaaS switching rules a useful companion.
Teams should therefore weigh three things together: how much security work the vendor takes off their hands, how much control they keep over their own data, and how easy it would be to switch.
A worked example: reviewing twelve SaaS accounts
Consider a hypothetical 40-person company that uses twelve SaaS products. Illustrative arithmetic: if the company reviews each product’s settings for 30 minutes every quarter, that is 12 × 0.5 = 6 hours per quarter, or 24 hours across a year. Spread over a team, that is a modest cost compared with discovering a public sharing link after the fact.
A 30-minute review of one product might cover:
- Accounts: Is every user current? Are there shared logins that should be individual?
- Roles: Who holds administrator rights, and do they all need them?
- Sign-in: Is multi-factor authentication required rather than optional?
- Sharing: Are external sharing and public links limited to what the business needs?
- Logging: Are audit logs on, and does someone know where to find them?
- Integrations: Which connected apps hold access, and are they all still used?
The numbers are placeholders, and a real team should adjust the frequency to the sensitivity of the data. The point is that the work is small and repeatable.
How does this fit a wider security routine?
SaaS configuration is one layer of a broader practice. The basics in cybersecurity basics every small team should cover apply directly, and the thinking behind zero trust security for small teams, which assumes that no sign-in should be trusted automatically, helps explain why account and role reviews matter.
If you build SaaS rather than buy it, the same model works in reverse: your customers will assume you handle the platform, while they handle their own settings. Clear defaults, plain documentation and visible audit logs make the customer’s half of the job easier.
A short routine worth keeping
The shared responsibility model comes down to a division of labor that is easy to forget. The vendor secures the platform; you secure how it is configured, who can reach it and what lives inside it. Pick vendors against a recognized yardstick, use public baselines where they exist, and schedule a small, regular settings review. That keeps the part of SaaS security that only the customer can do from being nobody’s job.
This article provides general information only and is not security, legal or professional advice. Consider your own circumstances and consult a qualified adviser where needed.
Sources: National Cyber Security Centre; Cybersecurity and Infrastructure Security Agency
