Safeguard
Security Guides•

SaaS shared responsibility: what the vendor secures and what you do

In SaaS, the vendor runs the infrastructure and application. You still own identities, settings, data choices and connected apps. A plain breakdown.

Safeguard Security Team
3 min read

With SaaS, the vendor secures the infrastructure and application code. You still own who has accounts, how they sign in, how data is shared, which other apps connect, and what you put in the tool. Exact lines differ by vendor, so read each vendor's documentation and contract.

The general split

Think of three layers.

The vendor usually handles: the data centre, servers, network, platform software and application code, including patching of those.

You usually handle: user accounts and roles, authentication settings, sharing and permission settings, which data goes into the tool, connected apps and integrations, logging choices, and offboarding.

Shared in practice: incident response, since the vendor tells you what happened and you decide what to do, and backup, which varies a lot between vendors.

This is a general model, not a statement about any one vendor.

Where customers get caught

Most customer-side problems come from the second group. Examples include accounts without strong sign-in, files shared with anyone who has a link, ex-employees who still have access, and apps connected with broad permissions. CISA's SCuBA project exists because configuration choices in cloud apps can leave gaps, and it publishes baselines for Microsoft 365 and Google Workspace that organisations can adapt.

What to ask a vendor

  • What security reports or assessments do you provide, and what do they cover?
  • Which settings can we control, and where are they documented?
  • How do we get logs of admin and user activity?
  • How do you notify customers of an incident, and how fast?
  • What happens to our data when we leave?

Ask for answers in writing, and check any claimed certification with the issuer or the vendor's own report rather than a logo on a web page.

What to do on your side

  1. Put the tool behind single sign-on and require multi-factor authentication.
  2. Review sharing and admin roles against a baseline.
  3. Limit connected apps and review them regularly.
  4. Turn on logging and decide who reads it.
  5. Document the data you allow into the tool.
  6. Write the exit steps before you need them.

Where responsibility is unclear

AI features inside SaaS tools, third-party plug-ins and marketplace add-ons blur the lines. Treat each as another vendor with its own terms, and ask where data goes.

A one page record

For each critical tool, keep a page that lists what the vendor covers, what you cover, who on your team owns each item, and the date of the last review. This is also useful evidence for customers and auditors who ask how you manage vendors.

Where Safeguard fits

Safeguard offers compliance and evidence automation, which can help keep records of vendor reviews, and policies for the software you build. It does not manage SaaS settings.

Quick check

If the vendor is breached, is that my fault?

Not necessarily, but you may still have duties, such as notifying others. Settings and connected apps on your side can also change how far a vendor problem reaches.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.