All articles

Security & Compliance

SaaS security posture management (SSPM): what it is and how it works

What SSPM checks inside apps such as Microsoft 365 and Google Workspace, how it differs from CASB and CSPM, a free CISA baseline tool and a rollout checklist.

By Published

Isometric 3D illustration of a deep rose red shield with a single toggle switch on its front, standing on a grey disc, on a pale grey background.

Your company runs Microsoft 365, Google Workspace, a CRM and a dozen other SaaS apps, and each one has security settings that nobody has reviewed since the day it was set up. You want to know whether a tool can check them for you, and what it would find. SaaS security posture management (SSPM) is the category of tools that connects to your SaaS apps through their admin interfaces, reads their settings and compares them with a security baseline. It then lists the risky settings and how to fix them.

The vendor runs and secures the application. The settings, users and data in your tenant stay with you. Microsoft’s shared responsibility matrix marks customer data, “configurations and settings” and “identities and users” as the customer’s job in SaaS, and SSPM tools check that part. For the basics, see What is SaaS?. For that split in one product, see Microsoft 365 as SaaS.

SSPM in plain terms

Think of a fire inspector in an office building with many tenants. The landlord maintains the walls, lifts and wiring. Each tenant decides who gets a key, which doors stay propped open and which contractors get a pass. The inspector walks through each office, compares those choices with the fire code and leaves a list of what to fix.

An SSPM tool is that inspector for your SaaS tenants. It reads settings through each app’s interfaces, such as:

  • Sign-in rules: whether multifactor authentication is required and how many people hold admin rights.
  • Sharing: whether files can be shared with anyone who has the link, or only with named people.
  • Connected apps: third-party apps that users have allowed to read mail, files or contacts through OAuth, the standard that lets one app act on your data in another.
  • Logging: whether audit logs are on and kept long enough to investigate an incident.

What SSPM tools actually check

Microsoft describes SSPM in Defender for Cloud Apps as “surfacing misconfigurations and recommending specific actions” for each connected app. Its recommendations follow standards such as those of the Center for Internet Security (CIS) and the app provider’s own best practices (Microsoft Learn). Its SSPM page shows recommendations for a connected Salesforce app, and lists two prerequisites: a Defender for Cloud Apps license and an app connector for each app.

The same documentation adds OAuth apps to its attack-path views, because a connected app with broad permissions is a route into your data. Independent SSPM vendors sell the same category. AppOmni, for example, describes itself in the FAQ on its homepage as an SSPM platform.

SSPM vs CASB vs CSPM

Three acronyms sound alike and answer different questions. The table puts them side by side, with examples from Microsoft’s documentation, which covers all three in its products.

Tool What it looks at Main question Example from Microsoft’s documentation
CASB (cloud access security broker) Which cloud apps people use, and what they do with data in them Which apps are in use, and is data leaving safely? Shadow IT discovery; discovered apps rated on “more than 90 risk indicators”
SSPM Settings inside the SaaS apps you have approved Are the approved apps configured safely? Security recommendations for connected apps, such as Salesforce
CSPM (cloud security posture management) Your own resources in infrastructure and platform clouds Are your servers, storage and databases configured safely? Defender for Cloud assessing Azure, AWS and Google Cloud resources

A CSPM tool reads virtual machines, storage buckets and databases. It does not read the sharing settings of your Microsoft 365 tenant or your CRM. If you run both your own cloud infrastructure and many SaaS apps, the two tools cover different ground.

A free baseline: CISA SCuBA

You do not need to buy a tool to see what a baseline looks like. The US Cybersecurity and Infrastructure Security Agency (CISA) set up its Secure Cloud Business Applications (SCuBA) project in 2022. It publishes secure configuration baselines for Microsoft 365 and Google Workspace, and two free assessment tools introduced in 2023:

  • ScubaGear checks a Microsoft 365 tenant. It is a PowerShell module that covers seven products: Microsoft Entra ID, Security Suite, Exchange Online, Power BI, Power Platform, SharePoint and Teams. It writes HTML, JSON and CSV reports.
  • ScubaGoggles checks a Google Workspace tenant against the matching baseline.

Running one of these once shows you the kind of findings an SSPM tool produces. What a paid tool adds is more apps, continuous checks and a place to track fixes.

Sizing the review

Example (hypothetical): a company with 400 employees connected to Microsoft 365. Assume each employee has granted an average of 3 third-party apps access to their account, and that the grants point to 150 distinct apps.

  • OAuth grants: 400 employees x 3 = 1,200 grants.
  • Manual review of every distinct app at 10 minutes each: 150 x 10 = 1,500 minutes, or 1,500 / 60 = 25 hours.
  • If a posture tool flags 30 apps with high-risk permissions first: 30 x 10 = 300 minutes, or 5 hours.
  • Settings baseline: if 48 of 60 checks pass, the pass rate is 48 / 60 = 80%, and 12 settings need a fix or a written exception.

The numbers are assumptions; replace them with your own. The point is the ratio: sorting by risk turns a 25-hour review into a 5-hour first pass.

Checklist: rolling out SSPM

  • List your SaaS apps and name an owner for each one.
  • Start with the two or three apps that hold your most sensitive data.
  • Pick a baseline: CIS, CISA SCuBA or the vendor’s own guidance.
  • Grant the tool the narrowest admin permission its connector accepts, and record who approved it.
  • Fix high-risk findings first; write down every exception and its reason.
  • Review connected OAuth apps and remove the unused ones.
  • Re-check on a schedule, because admins change settings after the first scan.

Common mistakes

  1. Assuming the SaaS vendor configures security for you. The vendor secures the service; your settings, users and data stay yours, per Microsoft’s matrix. Why it happens: “the vendor handles security” is how SaaS is often sold. Instead: give each app’s settings a named owner.
  2. Buying CSPM and expecting SaaS coverage. CSPM reads your infrastructure accounts, not the settings inside Microsoft 365 or a CRM. Why it happens: the acronyms differ by one letter. Instead: check which apps a tool connects to before you buy it.
  3. Scanning once. A clean report in March says nothing about September. Why it happens: the first scan feels like the project. Instead: schedule checks and track drift.
  4. Ignoring connected apps. A third-party app with read access to every mailbox works like an extra account that nobody watches. Why it happens: users grant access in one click and forget it. Instead: review OAuth grants, as in the example, and remove what nobody uses.

For how certification fits next to configuration checks, see ISO/IEC 27017 explained. For the Google side, see Google Workspace as SaaS.

Sources

In three sentences

SSPM tools connect to your SaaS apps, read their security settings and connected OAuth apps, and compare them with a baseline such as CIS or CISA SCuBA. They cover the part the vendor leaves to you, which CASB tools (app usage) and CSPM tools (your own cloud infrastructure) do not. Start with the apps that hold your most sensitive data, sort findings by risk, and re-check on a schedule, because settings drift after the first scan.