To secure the SaaS applications your company uses, take ownership of what the provider leaves to you: identity and access, configuration, data sharing and the list of apps in use. You cannot patch their servers, but you can control who signs in and what they can share.
What can you actually control in SaaS?
NIST's definition of SaaS says the consumer uses the provider's applications running on cloud infrastructure and does not manage or control the underlying network, servers, operating systems or storage, or even individual application capabilities, with the possible exception of limited user-specific configuration settings.
That last clause is where your work sits. The settings are limited, but they decide a lot: who can sign in, whether multi-factor is required, whether files can be shared with anyone who has a link, which third-party apps can connect, and how long audit logs are kept.
Where do the failures happen?
Mostly in configuration and access, not in the provider's infrastructure. CISA started its Secure Cloud Business Applications (SCuBA) project in 2022 to address cybersecurity and visibility gaps exposed by SaaS intrusions and compromises. SCuBA provides secure configuration baselines for Microsoft 365 and Google Workspace and guidance meant to protect information that organizations create, access, share or store in cloud environments. CISA says all organizations, not only federal agencies, can use it.
CISA also offers ScubaGear for Microsoft 365 tenants and ScubaGoggles for Google Workspace tenants, assessment tools that compare tenant controls with the baselines and produce reports showing where to improve. CISA describes ScubaGear as no-cost.
NIST SP 800-210 adds a design point: different service models need different types of access to be managed, and its general access control guidance covers IaaS, PaaS and SaaS.
A constructed example
A marketing team adopts a file collaboration tool with a personal email sign up. A year later it holds campaign plans, a customer list and a spreadsheet of partner contracts. The account owner leaves. Nobody else is an administrator, sharing is set to anyone with the link, and the tool is not behind company single sign on, so offboarding never removed access. Every item here is a configuration and ownership gap, not a vendor flaw.
How to check or apply this
- Inventory. List every SaaS app, who owns it, what data it holds and how people sign in. Ask finance for the subscription list and IT for the sign-in logs, since the two lists will not match.
- Centralize identity. Put apps behind single sign on, enforce multi-factor authentication, and remove local passwords where you can.
- Apply a baseline. For Microsoft 365 or Google Workspace, compare your tenant with CISA's SCuBA baselines and fix the gaps by risk.
- Limit sharing. Disable public link sharing by default, and review external collaborators on a schedule.
- Control integrations. Review which third-party apps hold OAuth access to your data and remove unused ones.
- Keep logs. Confirm audit logging is on and retained long enough to investigate, and send critical events to a place you monitor.
- Plan exit. For each critical app, know how to export your data and how to revoke access when someone leaves.
- Assign owners. Every app needs a named business owner and a technical administrator, with a backup for each.
How do you keep it going?
A one-time review decays quickly. Teams add apps, vendors change defaults, and staff leave. Put the review on a calendar: a quarterly check of new apps and administrators, a monthly look at external sharing, and a trigger whenever a vendor announces a major change. Track two numbers over time: the share of apps behind single sign on and the share with multi-factor enforced. Both should only go up.
Quick check
Is SaaS security the vendor's job?
Partly. The vendor secures the infrastructure and the application. You are responsible for identity, configuration, data sharing and who has access, which is where most SaaS incidents begin.
What is a good first step?
Build an inventory of the apps in use and who owns each. You cannot secure what nobody has listed.
Sources
- NIST SP 800-145, The NIST Definition of Cloud Computing, fetched 18 October 2026.
- CISA: Secure Cloud Business Applications (SCuBA) Project, fetched 18 October 2026.
- NIST SP 800-210, General Access Control Guidance for Cloud Systems, fetched 18 October 2026.
Last reviewed: 18 October 2026.
